A question about green tick when using control.

[tulamide]

... 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.

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.

[trogluddite]

I'm totally aware of all of it

Hiya tula, good to see you around! I'd have been very shocked if you weren't aware of it all! More of an exercise to see if my rusty old FS neurons and synapses are still working - explaining being the best test that I still understand it myself after so long!
Sounds like a lot of very interesting developments going on, and I've got a bit of time on my hands lately, so hopefully I'll be having a little tinker very soon!

[tulamide]

Sounds like a lot of very interesting developments going on, and I've got a bit of time on my hands lately, so hopefully I'll be having a little tinker very soon!

Can't wait to hear from your impressions!

The reason for me to say things like in this thread is to get people away from the term "unreliable". We have programmed and therefore have a totally different sense of time than people who don't program. When we say "unreliable", we may be referring to a dropped buffer of 128 samples. But other people will think of that term in the realm of seconds rather or even if it gets executed at all. And I really want to fight this, because we have to deal with green, wether we like it or not. That people nowadays go around the globe just to find that 1 ms for a functionality that is triggered manually is just over the top. Humans have a natural latency of 6 ms to 20 ms at young ages - at minimum. So there will never be sample accurate triggering.

Of course, in situations where you benefit from sample precision, it totally makes sense. But it shouldn't lead to people generally avoiding green at all cost. And I can see that development on the discord server.

[martinvicanek]

Hey Trog, so good to see you back!
And thanks for your insight.

[billv]

Yes Trog..good to see you back ...love your timing- I turned 14 today

[Tepeix]

Thanks for all those explanation !! I'm gonna read it again for sure.)
Good also to see you Trog. We where not on the forum at the same time, but i might have read all of your post, and get a lot of your schematics !

So midi is the way, or i might do an external dll. I planed to try to do it someday.
Yes also the user have is own latency, i think even more to make a tempo detector while i know that it's really not an easy task.. The looper think is an idea but i don't know when i will really work on it, many project already to finish

But i find this one i have made some time ago.. It's very crude and simple, but already some fun

[Spogg]

One thing I’ve been tempted to say, and have now conceded to the impulse, is that DAWs have a “humanise” possibility, which of course adds a degree of randomness to timing!

[martinvicanek]

True, but I never got convincing results with random jitter. It seems that human timing deviations are not random at all. In some genres the leading instrument would often play behind time for a laid-back feel, some would play straight 16th licks over a swing groove, etc. Frankly I prefer perfect timing to even small random jitter.

[trogluddite]

I saw an great example of "perfect timing" just before Xmas... A live band* consisting of fourteen people blowing, banging, and twanging pretty much everything but the proverbial kitchen sink. By the old FOH engineer's rule of thumb (1 imperial foot => 1 ms time delay), those musicians were dealing with latencies spanning about 5 to 25ms, different for every pair of performers, and likely different every night depending on the space restrictions of each venue.

The timing measurements made by my cranial "wet" computer made every bone and muscle in my body boogie like a dervish (*calibrated for age and state of enebriation! )

A big part of the "human factor" is that musicians' and listeners' brains are expert at making predictions about the very near future - like an extremely advanced form of latency compensation that's highly adaptable to both musical and environmental context. Although I do often lose myself down technical rabbit holes, I think there is a point beyond which obsessing about CPU/latency measurement can be rather like relying too much on the graphical displays of a DAW. As objective ways to measure things, they can be very useful, but they don't measure time the same way that a brain measures time, and we don't make music for machines to listen/dance to (yet?! )

To contextualise this for Teipex's original question (hi there! )...
My own experience of playing with FlowStone loopers leads on from Martin's comment (nice to see you! ): Jitter is usually more problematic than outright latency. A sense of musical "latency compensation" will develop quickly with a bit of practice at performing with the technology so long as the latency is relatively consistent (and you can hear what you're doing clearly enough!) FWIW, I always controlled my "Soopa Doopa Loopa" with MIDI foot pedals, and set ASIO buffers of up to a few tens of milliseconds for reliability - and the weakest link for creating smoothly flowing loop points was always the operator (i.e. me!).

(*OT: I may be a little biased about the band, as one of the guitarists is an old friend and bandmate; but if you fancy something very uplifting and beautifully arranged to wiggle to, it was these guys... Orchestre Tout Puissant Marcel Duchamp)

[RJHollins]

Thanks for the Links !

quite infectious, hypnotic