A question about green tick when using control.

[Tepeix]

Maybe strange that i ask this question after so much time using Flowstone.)

Tick and green are considered unreliable for precise timing when not using only ruby.

But how is it for interaction of the user ? if i make a button that command some function,
how much latency could happen when the user click on it, or click on a key ?

If there's latency is there faster way ? A ruby module directly connected to blue could be faster ?
Or maybe using midi keyboard, then translating from white to blue ? Or something else ?
Or maybe this is not necessary because even in green the interaction of the user is at minimal latency ?

This is to make a looper, in this case, it's crucial that the user could activate it precisely at time x.

[martinvicanek]

Yes, green timing is a bit unpredictable and depends on how busy your computer is at a given time, althought it is usually not a concern for GUI adjustments for an audio plugin, say. I haven't measured the response time of a green switch, butI would expect it in the range of a few ms to possibly a few tens of ms. The problem is its unpredictability.

If you have the option to start your looper via a MIDI controller, I would recommend that route rather than using green. Take that with a grain of salt, though, as I have not made any measurements for that method either.

[Tepeix]

Thanks !
I think i will try to use both for different user profile.
Maybe also a complex tempo evaluation that try to correct even if the thing might be not easy..
I think also at a busying tick evaluator..

[tulamide]

Maybe strange that i ask this question after so much time using Flowstone.)

Tick and green are considered unreliable for precise timing when not using only ruby.

But how is it for interaction of the user ? if i make a button that command some function,
how much latency could happen when the user click on it, or click on a key ?

If there's latency is there faster way ? A ruby module directly connected to blue could be faster ?
Or maybe using midi keyboard, then translating from white to blue ? Or something else ?
Or maybe this is not necessary because even in green the interaction of the user is at minimal latency ?

This is to make a looper, in this case, it's crucial that the user could activate it precisely at time x.

I'm a bit confused, so let's hope to clear things up.

It is everything that relies on a windows timer, that is unreliable, especially in very short periods (like 20 ms). The user pressing a button is not unreliable, it is Flowstone's event system, which activates immidiately. User clicks button -> action performed.

Any user pressing a button for a looper is probably more imprecise than the event execution.

So, are we talking about ticker or event?

[martinvicanek]

So I measured the latencies for GUI and MIDI generated events, respectively. My reference was the mouse click or MIDI keystroke as captured by a microphone. Might not be ideal, but good enough to show the differences.
For GUI generated events I got latencies between 14 ms and 65 ms, while MIDI events showed much tighter readings between 1 ms and 5 ms. So MIDI would be my preferred choice.

Here is my measurement setup if anyone is interested or wants to repeat the measurement in her or his environment.

[Tepeix]

Very thanks ! Thanks Tulamide too !
I was just thinking that it might be impossible to measure. Very good idea !
Sure that this lead to confusion, event might be faster than tick but midi even more i suppose.
I will try to repeat, but have to find and make work a microphone with my computer.
(Last time i try was strangely a fail)

[tulamide]

Very thanks ! Thanks Tulamide too !
I was just thinking that it might be impossible to measure. Very good idea !
Sure that this lead to confusion, event might be faster than tick but midi even more i suppose.
I will try to repeat, but have to find and make work a microphone with my computer.
(Last time i try was strangely a fail)

No, MIDI isn't faster, it uses the same event system. But in the test scenario (a good and practical one, I might add) the midi signal is taken directly to pre-compiled prims, whereas the mouseclick is routed through several modules where interpreted calculations are done. That's how the difference comes together.

It doesn't change the result of this scenario. I just want to explain that it would be false to assume, the event system would be "slower" than MIDI.

[martinvicanek]

the mouseclick is routed through several modules where interpreted calculations are done.

I see. In an earlier version I had a monoflop using green prims instead of Ruby but it made no difference. Is there a faster way to bring a GUI event into the code box? (I am assuming that the looper is supposed to run in stream code, and we are looking for ways to start the looper with minimum latency.)

[tulamide]

the mouseclick is routed through several modules where interpreted calculations are done.

I see. In an earlier version I had a monoflop using green prims instead of Ruby but it made no difference. Is there a faster way to bring a GUI event into the code box? (I am assuming that the looper is supposed to run in stream code, and we are looking for ways to start the looper with minimum latency.)

Yes, I see the same scenario. And in this one, I think your approach over MIDI is the fastest one. I couldn't think of any faster transmission of the incoming event. The drawing is not of concern (that's why I didn't even mention it, because of its low priority in Flowstone. It will not hinder events from being executed. It really comes down to pre-compiled (fastest possible way without hardware acceleration) versus interpreted. Every connection is by design to be interpreted, as it isn't clear what the content or the user's intention with the data might be. So even something simple as a float prim connected to something else is interpreted, or maybe JIT (but I don't think Flowstone uses byte compilation).

There would only be one way, and that is for Flowstone 4. A good samaritan might take on the task of creating a prim for that exact purpose - mouseclick to stream trigger asap - and it should make a difference, because while the stream has highest execution priority, a pre-compiled prim is the fastest you can get besides streams.

A long while ago (talking of many years) a user, who is now running his own company and develops with C++/JUCE, discovered that execution gets slower the more nested modules one uses, and I think it has the same origin. For every connector in green you have to interpret code. Since green has lower priority than blue and white, it naturally can't keep up.

And Ruby only can keep up when it is used as a closed system. As soon as green connectors are used, it defeats the purpose of its synchronisation to ASIO. That's also why it is such a big deal, that playbackInfo was finally introduced to Ruby in FS4.

Ok, to summarize my babbling: A prim specifically designed for this job would be the only alternative I currently see to your MIDI approach in the assumed scenario.

[trogluddite]

MIDI would be my preferred choice

Likewise; and there are a variety of reasons to expect your results...

- Very low hardware/driver latency and jitter are key selling points for music gear. Not so much for generic keyboards/mice.

- The VST Host (or FS) will be talking directly to MIDI/audio hardware drivers. Keyboard/mouse events are always subject to the many whims of the operating system.

- Once received by a VST host, MIDI events are (usually) time-stamped to define their timing relative to audio (it's part of the VST plugin protocol).

- FlowStone/SynthMaker tries very hard to honour the VST host's MIDI time-stamps (i.e. to keep sample-accurate MIDI sync'). Other events may not have such strict latency guarantees, if any.

TL/DR Version of the explanation ("geekery") that comes later:

- To meet the VST specification, MIDI events are usually processed when a specific sample is reached during the filling of the current ASIO audio output buffer, as specified by a timestamp provided by the VST host.

- "Green" GUI/timer events are simply added to a queue, and get processed whenever there is CPU power available during the "spare time" in between filling audio buffers.

- Ruby is... erm... more complicated, and very likely to have changed since I last checked!

- It seems unlikely that a GUI event would ever be faster, but even if there are rare circumstances where it could be, MIDI is almost certainly more precise, reliable, and repeatable.

NB) The geekery below applies to early SynthMaker through to FlowStone v3.0.x. I can't see any reason for newer versions to work much differently in principle, but I've yet to play with them and I wouldn't want to underestimate what Maik is capable of!

... MIDI ... uses the same event system.

Very nearly, but not quite...

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.