I know I’ve suggested this over on github, but to repeat myself, SM Pro would benefit from an extra expander that exposes randomisation settings, not just a trigger to randomise to current settings.
1 Like
WOW! Awesome video. I had no idea that Surge is such a comprehensive and awesome synth. Very impressive stuff.
3 Likes
re multi function vs separate modules. I think making a monster VCO with a bunch of modes and dynamic labels is a terrible idea. I much prefer separate modules that you can look at and see what they do. As far is the filter, it sounds like it’s similar to perhaps a subset of my “Stairway” filter? That module is pretty popular, and it puts all the parameters on the front panel without any context menu. Enclosing a picture in case it helps.
I disagree with @steve about the reason most VCV modules don’t have “VST like” UI. I don’t like UI like that, and I suspect I’m not alone in that.
It’s not totally obvious from the picture, but the drop down that says “transistor” gives the selection of non-linearity types (transistor is actually tanh on every stage, and is the default). The slope control gives one stage up to four, but is continuously variable, so the basic filter it probably quite different from the Surge, but the controls are pretty similar.
Bruce - Are your two popup menus there for filter types mappable by any chance?
Hmmm - I didn’t give any reason why "most VCV modules don’t have “VST like” UI. Nor did I suggest more should have a VST like UI.
What I said was “most Rack modules are based around fairly simple hardware module designs” [and that’s the reason they look as they do].
Surge is an unashamedly modern digital synth - however the design ends up, I think that should probably be respected to some extent.
3 Likes
In this particular case, the range only really matters for the in-plugin oscillator. When I exposed it as rack I have a knob which sets the base frequency and an input which modulates it at 1v/oct.
For other controls things like tempo sync and absolute matter quite a lot though. In the current UI those show up as the little orange toggle sliders.
1 Like
Is there a built in rack widget for a dropdown menu with <> arrows like you use there?
Three of those, (filter group, filter model, filter sub-model), a cutoff knob + cv, and a resonance knob + cv are exactly what we need for the surge filter module semantically (along with an in and out).
Yes, my dropdown control is a fully “by the book” parameter widget, so it’s fully mappable, had good tooltips, etc… Not everyone like these, a matter of taste that I have no problem with. But it think they are quite usalble.
I like the mind-meld stuff, and I would say that just looking at the panel you can pretty much tell what they are and what they do.
2 Likes
Inasmuch as we designed the current modules, this idea that it is ‘very digital’ was top of mind. That’s why I sort of did it like kinda-vfd-displays
I was definitely thinking more ‘alesis quadraverb’ than ‘moog ladder vco’
Not sure that was right. And like I said we didn’t do anything which amounts to an extensive design, just styled knobs and fonts and put them places which weren’t insane.
1 Like
As a solution for selecting from multiple options, I think they work very well - particularly if they are mappable as you say.
1 Like
I don’t think there is on in the SDK. But you can just take mine. My own repo is 1.0 stuff. The 2.0 port wasn’t done by me, and it’s in @robert.kock 's squinky labs 2.0 repo: GitHub - kockie69/SquinkyVCV-main
I think there may be a small bug in there - don’t quite remember. It’s in PopupMenuParamWidget.h
yeah, I like them. Some ppl say they are computer-like rather than hardware-like, which is true. Like I say, a matter of taste.
Yeah - there’s nothing wrong with taking advantage of the platform you are on. And plenty wrong with forcing a hardware interface onto software, when it can be done much better with a software ‘computer-like’ interface.
Your ‘hardware-like’ alternatives would either be a stepped knob with awkward labelling, or a button clicking through options shown in a display, which could work fine, if requiring more clicks etc - but that still requires a display which might annoy some purists haha.
I think you made the right choice.
OK
Well I’m not going to write any code now. You can try all the oscillators and filters in the VST3 to see the gap between what’s exposed at head - basically all the filters, the wave shapers beyond the basic 5, and modern string and alias oscillators.
And lets think bit about three things, like I said
1: Do we want a panel-per-oscillator class or a multi-panel 2: How would we expose the filters and 3: What should the UI be for a couple of the non-mapped FX (Treemonster, Spring Reverb) and one mapped one (Rotary)
1 Like
Paul - how do you feel about having a waveform display for the oscillator, as there is in the VST? is that something you could do?
1 Like
Sure it just runs the a copy of the oscillator on the ui thread. Presume I get some sort of reasonable path api with nanovg so can just borrow that code.
Oh can you all self build or should I stamp an alpha xt version so there’s a github download?
1 Like
I can self-build no problem.
1 Like
OK I just played around with it a bit tonight (and also got Modern exposed - and man modern sounds great in rack) and I am now convinced we do, indeed, want one module per oscillator type. They can be similar but indeed the value displays are redundant now we have tooltips and we have room for a plot.
2 Likes
Ok folks I just merged a change which adds modern aslias and twist as standalone modules
Right now they look an awful lot like the multi osc without the button bar to select osc type - so need some focus obviously - and string adds an extra unlabeled inout st the top for a retrigger (string has a natural decay which means you need to strike it with a gate)
I’ll clean up the ui a bit to be a bit better over next few days
But wow, I really like modern. It’s a beast and sounds good in rack
All 16 channel polyphonic also etc of course
I also asked on the community issue if anything in the somewhat complicated build we do precludes us being in the library. Important to know that before we invest
But fun! Would be nice to revive these this fall.
4 Likes
I tried building with the toolchain and it fails because of missing tool dependencies, e.g pkg-config.
@baconpaul has that dependency always been there?
For testing, I installed pkg-config in the toolchain Docker image:
Now:
/home/build/plugin-src/surge/libs/JUCE/modules/juce_core/native/juce_BasicNativeHeaders.h:254:11:
fatal error: 'sys/prctl.h' file not found
#include <sys/prctl.h>
^~~~~~~~~~~~~
So, I would say that it will take some work to get this to build.
On Ubuntu 20.04, which is the base image for building:
./x86_64-linux-gnu/sys/prctl.h
./linux/prctl.h
Probably, the include path needs the platform-specific prefix (x86_64-linux-gnu) defined somewhere.