SynthMakerTzarls ·
Ok, so this is not going to be a "We need a way to delay MIDI or green events" post, but rather a "Malc, I think I know how you can get this to work quite easily, could you give it a try?".
I`ve been reading the VST SDK to better understand how this all VST stuff works and found some interesting info that had me thinking on the way SM works internally. This is how I think SM works internally.
Even though in SM we work and a per sample basis, the host doesn`t pass samples one by one to the plugin - it actually sends blocks of samples. It`s vst.dll - SM`s wrapper - that takes the block and passes the samples one by one to the schematic, making all things work the way we know.
When it comes to MIDI events, the host passes MIDI Events to the plugins along with the sample block, but these events are timestamped. So there could be a particular MIDI event that happens at sample number 16. VST.dll receives this event but holds it for 15 samples. Then, at sample number 16, the event is passed to the schematic. The schematic receives and processes it at that moment. But since SM`s schematics always work in a "now" time frame. the timestamping is not passed to the schematic. Which is understandable, the schematic only has to know that the MIDI event has to be processed as soon as received. The problem is that, as there is no timestamping, there is no way to tell the schematic to put a mark on a certain MIDI event so it gets processed a couple of samples later (the obvious and not so satisfying workaround is to use windows timers to delay it). And when firing a MIDI event, the schematic does it "now", so the VST.dll file receives it "now" and sends it "now" to the host.(Actually vst.dll puts a timestamp on that MIDI event, a timestamp corresponding to the sample when the schematic sent the event). So, unless support for timestamping is added to the schematics` inner circuitry, MIDI delay can`t be achieved.
Or can it?
Right now we have a primitive called MIDI Buffer. Altough it`s still RD, I can say it works reliably (I`ve used it to build the functionality of a sustain pedal, cc64, by having it trap all note off messages when the pedal is depressed and sending all of them at once when the pedal is released).
My guess is that such primitive is just a buffer of a very large size (or dinamically resized), a big array that stores MIDI events and then, when triggered, sends them all at once, at time "now".
What if that buffer was transformed into a circular buffer? The writing and reading pointers for that buffer could be easily made to work with sample accuracy, because behind the curtains SM works on a per sample kind of basis. That way, we could have a primitive that could give us sample accurate MIDI delay. The buffer should be 2 dimensional (let`s say y and x dimensions).
Y would handle the sample position (the "timestamp"). X would handle the different events for that particular "y" sample. Y would the be the length of the delay, in samples. X would then be a safe value, say 128 (how many MIDI events can be fired in a sample`s worth of time?).
As you can see, such a primitive wouldn`t have to rely on a timestamping feature. It would be just a plain circular buffer - a plain non fractional delay. And I suspect that most of the code needed for it is already in there in the MIDI Buffer prim.
AND.... if such a circular buffer can be made to work with a MIDI event, could it be made to work with any kind of green event, even without timestamping support?
Malc, you`re the only one who can tell if I`m right or wrong on this one. And of course, the one who can make this a reality.