Re: A question about green tick when using control.
Posted: Wed Feb 28, 2024 11:24 am
trogluddite wrote:Very nearly, but not quite...tulamide wrote:... MIDI ... uses the same event system.
There has always been a separation between sample-accurate (high-priority/"time-stamped") events and asynchronous (low-priority/"queued") events. The two kinds run essentially the same code AFAIK, but they have their own dedicated CPU threads, and their priority status usually propagates through the schematic along with their cascade of triggers. [IIRC, some nasty bugs in early SynthMaker versions were caused by getting the threading wrong.]
Why complicate things like this? Because of CPU saving and the nature of the VST protocol...
Incoming MIDI events come via the VST host (or FS), not directly from a MIDI driver. Specifically, for each ASIO audio buffer, there will be a corresponding MIDI buffer spanning the same time range. Each MIDI event in this buffer has a time-stamp - i.e. the index of the sample in the audio output buffer "when" the event should happen.
When generating the audio output from the plugin, audio stream ("blue") calculations are interrupted at each of the time-stamped samples so that the consequences of the corresponding MIDI events can be computed at the right "times" within the current buffer. This is how sample-accurate MIDI is done generically, not just a FlowStone thing. Note that the plugin latency is no different than for processing an audio input, nor is any jitter introduced.
However, there is a price to pay for sample-accuracy: interrupting stream calculations to process events can dramatically slow down the filling of an output audio buffer (the soundcard wants it in a hurry!) If you do a lot of Green/Ruby processing on MIDI events, it can sometimes show up as significant CPU spikes at each event.
In principle, this "time-stamped" system could also be used for keyboard/mouse/timer events, etc.; but these events have such inherently sketchy timing that it isn't worth paying the price. Such "low priority" events are added to a queue. While an audio buffer is being filled, these events just step aside and wait in the queue. During the "spare-time" between filling audio buffers, FlowStone processes as many items as possible from the queue, according to how much spare CPU power is available.
The main down-sides to this CPU saving are...
(1) How long a low-priority event will wait in the queue cannot be predicted.
(2) Low-priority events cannot change "blue" (streamin) values mid-way through an audio buffer.
(3) So many queued events might get processed during one spell of "spare-time" that "blue" stream components do not "see" all of the rapidly changing "green" values (this is one of the reasons why turbo-charged tickers never work the way people expect!)
[NB: I have demonstrated all of this several times before on the forum.]
I won't complicate things further by bringing Ruby into it; but in essence, prioritising events according to their source allows FS to balance performance against its intuitive graphical programming style. Occasionally it can trip us up, but I think it's a very good compromise on the whole.
Hi trog, nice to see you again, even if just for one post
I recently explained this on the FS4 discord, of course in my own and not so well-worded way. I'm totally aware of all of it, Especially Ruby has gotten quite some important updates, and its synchronisation works just the same ("time-stamped"). We recently had DaveyBoy making use of a newly added class that wraps VST info. I adviced him to use the sync prim, so the calculations are done within the current buffer. He posted an image of his results, that speaks volumes. His DAW position counter converted to measure format matched exactly the Cakewalk measure display he used to test his plugin.
There are still at least three threads. Audio, green and Ruby. However, as I explained, we now have the option to write our own prims (they are dll). Those prims will take away the interpreted code load and will of course be faster in execution. Also, non-drawing events always have precedence. Additionally, Maik has fixed loads of bugs and issues regarding green, that improved speed overall. Flowstone 4 is lighter on CPU at the cost of more RAM usage (a lot is buffered).
But this scenario was about FS3, and there I agree (and did so already), that MIDI is the fastest way.