Semimodular Envelope Trigger/Gate

[selenologist]

Basically writing another issue for myself to fulfil. Here to collect thoughts and feedback.

There remain numerous quirks and inflexibilities related to envelopes.

Voice-level step sequencers can retrigger the volume and filter envelopes but:

• MSEGs can't (#4201)
• Scene-level step sequencers can't
• Both are always retriggered, not just one
• LFO envelopes can't be retriggered

Additionally, single trigger and mono modes could do with more finesse:

• What if we want to preserve oscillator and filter state across notes (instead of reaping and creating a clean one from scratch) but still retrigger the envelope?
• What if we want the envelope to start from its current position instead of first resetting to zero?
• What if we only want to retrigger the filter envelope but not the volume envelope? How about just an LFO envelope?

Some other issues which involve more flexible trigger behaviour include:

• 1971 (map a MIDI CC to a macro and boom you have a gate modulator)

• 2621 (good time to add a button to disable the envelope entirely, or decouple the LFOs from 'their' envelopes)

• 1027 (invert the gate with a formula modulator / phase scrub shaper / etc)

these could be closed as part of a solution to this issue.

Describe the solution you'd like: Make Surge even more like a modular :sunglasses:

A terminal for accepting modulation is used to control the gate of each envelope (cheat solution: a tiny slider?). Possibly trigger should be a separate signal, The summed modulation crosses a threshold with hysteresis (like a Schmitt trigger), this enables or disables the gate. A trigger signal should probably be highpassed so that a gate may be used as a trigger.

As the gate signal is floating-point, you can do the usual modular tricks of inhibiting positive gate signals by overpowering them with negative signals, or summing a steppy waveform with a slow LFO to get envelopes that trigger 'sometimes'. Mod mappers etc could be used to do rudimentary logic gate operations on gate signals.

Existing behaviour is preserved with a pre-routed connection to a main gate generator. This is applied in the init patches and all old patches. Breaking this connection disables the main gate. The main gate generator gets some additional options in the Play Mode section of the UI. There is also a main gate input, which can be used as a quick way to retrigger everything connected to the main gate.

With this added flexibility, we can fold latch and mono st into a unified mono mode, or use this space to control gate generator features. Fingered portamento can also probably be handled using gate/trigger signals instead of being its own mode. This would also give poly patches control over fingered portamento.

Mono modes preserve the oscillator and filter state forever. This will cause a slight difference to old patches, but one we ought to be able to get away with being "XT".

Each envelope gets an option between return to zero (default) or continuing from current level.

Step sequencers and MSEGs have output gate terminals. In the init patches, all of them are wired to the Main Gate Input, which preserves part of the current Surge behaviour... except now LFO envelopes get retriggered too. Existing patches however directly route all step sequencer gates to the volume and filter envelopes to preserve the existing behaviour.

Step sequencers also advance a step on a rising edge.

Known Design Flaws

• Visualising all of these pre-routed connections is difficult and potentially confusing. Visualising connections made after a few hours of crazy patching, even worse. This might need to be paired with a better system for viewing modulation routing.

• Deciding when to reap voices gets tricky, as voices may be reaped right before an LFO was supposed to retrigger the volume envelope. This may be just a thing patch designers have to accept - after some amount of silence, patches get reaped, or maybe we hack in some kind of 'voice hold' mechanism. In mono mode this is easily solved - never reap.

• The low control signal Nyquist frequency means fast gates may not behave as intended.

• Routing gate signals everywhere is somewhat heavyweight. Perhaps we should only fake the default behaviour rather than actually using the modulator system.

• Are we stuck with a one-block latency? Nope, it's chill. Main gate signal can have zero sample latency.

Describe alternatives you've considered:

• using vcvrack
• going outside

[mkruselj]

Some of my thoughts here after I've actually had breakfast. In no particular order.

• Definitely sounds like something that should be done in a new Surge Modular sort of plugin, or all the VCV modules should be updated for processing per sample rather than block. Also as soon as we're talking about terminals, that's directly heading into VCV land in my mind.
• Mono modes are already complicated enough as is, tbh I can't wait to see the play mode parameter only have Poly. Mono, Legato, Latch, and fingered portamento next to glide time as a button.
• Fingered portamento makes no sense polyphonically. We don't have a voicecard system in Surge that would make polyphonic glide a possibility anyways. Voices don't know about one another, besides how would you detect which exact voice was legatoed with which other voice? Haven't ever seen this in any synth ever (but I'm all ears!). In old Oberheims polyphonic glide was a thing, but it always happened when a voicecard got called to trigger a voice, no exceptions. Just no way to know if it was legatoed or not.
• I went back and forth on this a lot, but return to zero mode vs continue from current level should kinda be global at patch level for all envs IMO, for ease of use and general familiarity. Or at least I'd like to know about viable scenarios where one would want different behavior per envelope that would make a huge difference and validate added complexity.
• LFO EGs need a proper deform mode that adjusts the curvatures but doesn't mess with the levels like the current deform does.
• Note off triggering should be 4th LFO trigger mode, but also a whole scene should be triggerable at note off (via just a simple button in Play Mode section). This is just simpler UX and to me seems a better payoff.
• One block latency is a big thing here. Probably the biggest obstacle, and biggest thing to change code-wise. Not insurmountable for sure, but would the added CPU usage increase (which would likely be not insignificant) be really beneficial, or would it also blow up some of the filter algorithms in not very nice ways? This is a pretty big question. If it makes things sound uglier in the end, we shouldn't do it. Or we should only adapt a subset of this FR that makes things more manageable from code and user perspective, and also doesn't blatantly show that a good chunk of the DSP in Surge is close to 2 decades old.
• Another triggering FR that was perhaps missed is #1383. That one is super simple yet it yields quite interesting and useful results.

Sorry for the wall of text. Also. chuckle at the "go outside" remark 😁

[selenologist]

Re poly portamento, we already appear to have 'bend from latest note' behaviour. Poly FP would be 'bend unless there are no notes held, at all'. That is not the most ideal magic behaviour, but it is a useful behaviour I've hacked in before by using aftertouch -> modmapper trick -> portamento so that it only bends when another note is held. That... is a silly hack and I don't know a simpler way with the current model.

Re different envelope behaviour: wanting things to be different comes up all the time especially when you do things like make drum machine patches, which are an effective pattern we ought to reward as much as possible. Like you don't want your bass drum's volume envelope to reset from zero but you DO want the pitch modulation to reset from zero. Particularly if you wish to increase the scene count. No good if all the scenes are inconveniently locked on certain settings.

Re LFO deform: Agreed, this is particularly an issue for sample and hold which lacks a slew limiter ... but isn't the fix for that the formula modulator? An additional deform mode could be useful anyway from a convenience perspective. This is a little unrelated though.

Re latency: thought about it some more, I was confused, it's chill. We don't have to have a 1-block latency on the main gate signal, it can have the correct value at the start of a block no problem. Like it's actually zero samples additional latency, because there's nothing wrong with discontinuities in the gate signal. I just have to make sure that modulation runs before synthesis (have not looked). However modulation-generated signals have a 1-block delay but that's no problem.

Re "a whole scene should be triggerable at note off", in this model this is "invert gate, send inverted gate to main gate in" but this requires that the trigger be derived from the gate... But in this case the 1-block delay of modulators comes in handy.

Re #1383: agreed, missed that one. LFOs should emit and receive trigger, separate from LFO envelope trigger. Actually, I really do think it would be useful if LFOs and envelopes could be decoupled. Often one of them is just a vestigial organ that could have been repurposed if it weren't attached.

[mkruselj]

Re poly portamento, we already appear to have 'bend from latest note' behaviour. Poly FP would be 'bend unless there are no notes held, at all'. That is not the most ideal magic behaviour, but it is a useful behaviour I've hacked in before by using aftertouch -> modmapper trick -> portamento so that it only bends when another note is held. That... is a silly hack and I don't know a simpler way with the current model.

Ha, I guess that might work. I mean we are getting FP button next to Glide parameter anyways after XT 1.0, so it might as well do something extra in poly mode - but this will require a lot of thought (gotta take MPE and non-MPE into account) and unit testing (of course). However I still see no need to decouple gate/trigger stuff and make a separate UI/UX for it just to offer this feature, when FP button could easily sort that scenario out.

No good if all the scenes are inconveniently locked on certain settings.

Doh did I say RtZ should be global at patch level? What I really meant was global at scene level. Would be just as simple, and a bit more flexible. What a fluke - I really was thinking "scene level" but fingers were typing "patch level", lol.

Re LFO deform: Agreed, this is particularly an issue for sample and hold which lacks a slew limiter ... but isn't the fix for that the formula modulator? An additional deform mode could be useful anyway from a convenience perspective. This is a little unrelated though.

Formula modulator could certainly do all that stuff, but I definitely agree a secondary deform mode for S&H that slews it the same way step seq is slewed would be more than welcome! Ditto secondary deform mode for LFO envelope mode which is not applied to the LFO output, but rather to LFO envelope stage switch-case.

Re #1383: agreed, missed that one. LFOs should emit and receive trigger, separate from LFO envelope trigger. Actually, I really do think it would be useful if LFOs and envelopes could be decoupled. Often one of them is just a vestigial organ that could have been repurposed if it weren't attached.

Yeah but they act as a single unit, so this then creates some problems UX-wise. We already have people not figuring out the "down arrow thing", decoupling LFO EG from LFO would potentially make things even worse.

[baconpaul]

Minor point

Both are always retriggered, not just one

The step sequencer has the ability to trigger both, filter, or amp only. right click or control click or something on the retrigger box and you get half boxes which toggle.

[selenologist]

As this is way overcomplicated I'm going to close this one for now so it doesn't clog up the tracker. Can still revisit in a hypothetical future where this seems more reasonable.