Anyway the next nightly will have (1) single click for value menus on unison, octave, lfo steps; (2) all vco have a fixed attenuation which is set in the module menu below the drift and (3) twist will toggle the LPG on and off automatically when you connect or disconnect trig. (But you can still use the button if you want as well).
I’ll write an update at the end of the weekend of all the changes since Omri’s video, but there’s been a lot. Worth updating with some regularity is my bet for the next week at least.
Heya @LarsBjerregaard I have a DC blocker implementation together but would love to test it on a few of the cases you found rather objectionable. Can you share a patch with a couple of setup oscillators which you think are showing an inappropriate net dc level so I can test it?
OK @LarsBjerregaard I just merged a DC Blocker implementation on the VCO. I remembered alias ramp at low warp as a DC offset and so used that. Here it is at a rather low frequency with and without the blocker. (Green is no blocker, yellow is blocker - you can see yellow stays centered around 0)
Possible bug (I haven’t read all, so not sure this is unique)
Polyphony modulation is working fine as long as all channel counts match. But when one of the channels has fewer, then modulation ceases to respond to CV changes.
In my case I had 16 MPE voices, and wanted to cut back to 8. I had only changed the V/Oct to 8, and all others were still 16. I expected at least the first 8 channels to continue to function properly. Modulation resumed working once I set all channel counts to 8.
I’m on Win 64, Surge version 2.xt-1.1.1-nightly-82b14a5
Haven’t used them much, but these modules are excellent, and Omri Cohen did an amazing job showing them off in his video. Looking forward t the day when they hit the library and are available to everyone.
On the other hand, when I dont have Lars bug report and loads of people are downloading the beta, turning on a dc blocker i coded at 9pm on a saturday night on beta weekend as a default when i only found one heavy dc case and didn’t test every oscillator type with it on makes me think maybe no
flipping the default is trivial if it turns out to be right.
So this isn’t a bug but it may be a wrong design choice
The way the modulation works is: The module has a natural polyphony (v/oct, trigger, input signal, etc…)
If the modulation polyphony CV matches the input signal then everything lines up
Otherwise we broadcast input channel 0 everywhere (or should; there may be a bug and i’ll test today).
I am honestly not sure what the right behavior is with 6 channel v/oct and 3 channel modulation for channel 4. Should we set modulators to 0? Should we use channel 1? should we use channel 3?
So right now the matched and the mono modulator case works and the mismatched should revert to mono ignoring higher channels (but may not)
community input on the right semantic here would be useful.
Tested on SurgeXTRack-2.xt-1.1.1-nightly-b10afec-mac.vcvplugin and I have written on the github issue. Yup, the DC-offset is fixed, or in the case of String VCO quite reduced.
In testing this on my aging CPU I find that the DC blocker consumes no CPU what so ever, and like Squinky I would argue that it should just be turned on by default, and that in fact that menu item is likely not needed at all.
Just thinking about Omri using one of the VCOs as an LFO in his video - could the DC blocker potentially affect that use case? If so the menu item should likely be kept so it can be turned off.
This is exzctky to a tee what I said on GitHub 5 minutes ago
Yes I think default on with an option
But I’m not sure running the oscillators in ultra low frequency mode is a great idea for some of them. I have an open issue to sort of figure that out. There’s a few places where the code assumes roughly audio range even with the dc blocker excluded
Many (majority?) of modules have a specific input that dictates the number of channels. For oscillators it is typically the V/Oct. Thought needs to be put into which input drives the channel count for each module.
Some oscillators take the highest channel count found across all inputs, and use 0V for all missing channels.
Another possibility is to use the minimum count >1 as the channel count (mono still gets applied to all channels). Of course mono for all is simply mono.
I think any of the above could work well for Surge XT. (or maybe user choice in menu?)
So this is basically how surge works also. V oct or trigger both set poly on the vcos. Same on the lfo (though the lfo has a menu item also)
The question is what to do when a modulation input mismatches that polyphony.
The cases we handle well are
Poly 1 mod 1 - obvious
Poly n mod n - obvious
Poly n mod 1 - broadcast modulation monophonic to each polyphonic voice
But poly n mod m n!=m is the case you described. In that case what I intend to do is just use mod 1 in Broadcasr and ignore mode 2…m. But there’s other choices and that’s the thing we need to figure out.
For the more interesting case (M<N), wacky idea here (probably as an option): a “modulation fold” mode that folds the incoming modulators out over the voices when there aren’t enough modulator channels available to cover the input channels.
Poly: N | Mod: M<N : assign mod voices 1…M to poly voices 1…M, M+1…M+M, etc. until N
More concretely, here are the modulation-to-channel mappings for a few examples:
Poly: 5 | Mod: 2 => 12121xxxxxxxxxxx
Poly: 6 | Mod: 2 => 121212xxxxxxxxxx
Poly: 6 | Mod: 3 => 123123xxxxxxxxxx
Poly: 7 | Mod: 3 => 1231231xxxxxxxxx
etc. (I think @DaveVenom is proposing either Poly: 7 | Mod: 3 => 1230000xxxxxxxxx, which is a reasonable option and should probably be offered, or Poly: 7 | Mod: 3 => 1233333xxxxxxxxx, which is similar to the “fold” proposal but results in increasingly less variation between voices when the difference between M and N is large).
The intuition is that, as soon as there is polyphonic modulation inbound, the user intends different polyphonic inputs to be modulated by different modulation inputs. I’d suggest that reverting to “broadcast-1” (essentially making the modulation monophonic again) might violate the principle of least surprise here. Reusing modulators when M<N might not be exactly what’s intended/desired but I think it’s the least surprising outcome. All voices get modulated with the maximum variation possible given the inputs.
(this whole thread makes me extremely happy by the way)
