Proper "Midi killer\reviver" on preset change

[kortezzzz]

Something that disturbs me for a while: Is there any solution for "killing" midi signal properly before preset changes and reviving it back successfully without ending with stack notes during the switch? I've tried some solutions, but non of them is 100% safe. The situation in mind is when the user plays notes while he's switching presets with midi control change at the same time. For instance, the famous live hardware work station behenoths do it very smoothly. What kinda workaround they use? Can it translated correctly in FS?

[Spogg]

I think you might need some sort of Ruby-based MIDI buffer solution. The trigger “Before preset change” could tell the Ruby code what to do and preserve the data for when the code gets an “After preset change” trigger. Then the code could re-send the MIDI data.
Far beyond my capabilities I’m afraid, but the approach may work.

Just in case you haven’t looked yet, the Preset Manager prim has an “Opts” options input which lets you tell it how to behave on preset changes.

Cheers

Spogg

[kortezzzz]

Thanks spogg,

Yes, setting the options to 4 is making things much better (not a smooth switch, since it kills the voices with a hard axe blow) but there would be still some intruding stack notes here in there.

Taking into account that Trog has made a quite smooth and solid notes change in your Midimus, I aim thinking that this kind of method would work in this case as well, but as you said, It's far beyond the capabilities of most of us. However, if this kind of workaround is possible, it will be then a"must have" feature in every synth that will be ever developed with FS.

[Spogg]

I see there’s a MIDI buffer prim (R&D) in FS 3.06 but no information other than it collects MIDI data which can be flushed or cleared by triggers.
Might be worth checking out?

Cheers

Spogg

[kortezzzz]

I don't think the midi buffer has something to do with this. My logic tells me that what is needed here is a simple as possible midi mechanism that will freeze the midi signal for about 100-200 milliseconds (until the preset changes) and then will give the already pressed note a new life automatically with a fresh "note on" message. Maybe I'm wrong. I have no idea if it even close to solve this problem, but it seems quite logical to me...

[kortezzzz]

Any way, here is my best setup so far. Hope it helps until something better will come up

[Spogg]

This certainly kills the notes!

But it doesn’t seem to re-send them after the preset change, which is what I thought you wanted.

Or maybe I misunderstood something…

Cheers

Spogg

[kortezzzz]

Yes, you are right. My set-up only gets rid of one problem: The stack notes
The other mission most likely needs Ruby rescue. In the meanwhile I've checked up how the famous brands deal with it.
Arturia's "Pigments" kills the sound and the voices. So do AAS synths and even Dune3. BUT... there is sylenth that makes a perfect preset switch, lightening fast and continues the sustained note amazingly, so there is a hope

[Spogg]

Fascinating!

I think it may be down to the architecture of the synth itself. When a preset changes, a whole bunch of parameters can change instantly which could be levels, routings, selections etc. This would lead to clicks at least, and possibly unexpected sounds when the preset changes. For example, a selector that switches between sine and square, on preset change, would definitely click often. You would need soft-switching using de-zipped multipliers, but then you’d get a CPU hit because all the oscillators would be in the stream, even if muted.

This potential stream interruption is the reason I normally include a Clear Audio prim for preset changes (before change or load), so everything is initialised ready for the new preset parameters. If the routing is fixed it may be possible to de-zip the changes of parameter values for a softer shift. But that’s decided at the design stage.

Cheers

Spogg

[trogluddite]

Yes, setting the options to 4 is making things much better (not a smooth switch, since it kills the voices with a hard axe blow)

Note that the options are bit-wise flags, so you can add them together to combine modes - e.g. No-recompile (4) + No-voice-kill (2) = 6. As I've never really been a synth builder, I'm not sure whether that would get you any closer to a smooth change-over. The 'no-recompile' option may need to be used with care. If a preset change alters routing of streams through selectors etc., then a recompile would be necessary. I'm not sure if 'no-recompile' handles this intelligently - it may be that it's just an optimisation for cases where you know that presets never alter the routing.

If full MIDI shut-down/restore is required, then Ruby can certainly handle it, and you're on the right track with your note buffer schematic. However, I'd investigate all of the combined preset-manager options in detail first, as the actions of the buffer might need to be matched to the preset manager options for a truly "universal" solution (the "don't kill voices' option in particular).