Proper "Midi killer\reviver" on preset change

[kortezzzz]

Spogg, Trog,

Your point is clear as the alpine breeze. So, how do you think Sylenth guys did it? Their achievement is nothing but brilliant. Let's say we don't wanna kill the voices. The solution then would be depended on proper midi blocking\releasing at close to perfect time (since if there is no midi, there is audio, right?...). So we know that buffer would save us afterchange. What remains then it's the timing of the proper block\release message. I believe 100-200 milliseconds blocking period would be enough to let the new preset come up before Ruby will give the sustained note a permission to continue playing with "note on" message , so the price then will be 100-200 milliseconds of silence?... Seems like a fair price to me. What do you think?

[trogluddite]

As far as other VST instruments are concerned, many of them have a distinct advantage - they're written in C++ using the VST libraries directly, so they can handle their voice assignment in whatever way fits their synth architecture the best. Currently, the only way to generate poly voices in FS is from MIDI via the hard-coded primitives that we're given, so I don't think that it's possible to completely avoid some kind of "glitch" at the change point using poly. I agree that it's a case of which option is least disruptive.

Strictly, it is possible to code our own voice management from scratch - I've done it both in green and in Ruby - but it means having to fix the polyphony and use as many duplicate blue streams (preferably grouped into mono4) as you need voices. There can be pro's to this if you're doing a strict emulation of an analogue synth and don't mind the limited polyphony, and it does completely isolate voice generation from preset changes. However, it seriously complicates the rest of the design, and all voices will consume CPU even when not playing.

[kortezzzz]

I see. Thank you for the detailed answer, Trog. Maybe future FS development will take it into account. So right now we are just killing the notes as most of the industry does. No better solution. What if we would keep killing the voices but just set up a little ruby patch that will revive a pressed note whenever a not is pressed after preset change? Right now, we just remain with a silence until the key re-pressed.

[trogluddite]

I'll dig out the Ruby "mono stream" voice manager that I made if I can find it. If that can be tweaked to mimic how FS assigns voices, we'd be able to "emulate" the voice manager for the period when its handling a preset change, and model how it will react to having voices restarted (e.g. allowing for note-stealing at max polyphony etc.) I'm not certain that it would be possible, but if it is, it would be good start, I think.

[kortezzzz]

I'm so curious to see how it works hope you find it. Every little progress we make with functionality and stability is blessed.