How "draw" method is executed from Stack in FlowStone/Ruby?

[Nowhk]

because in fact it is handled by C ++ side,
and in any case it is taken in mind that all RubyEdit modules are operated in turn by a class not exposed to us
and are executed in a Fiber method execution.

So when "draw" method will be executed is unpredictable: can happens before event method (that invoke it) ends or after it. It seems I cannot scheduling it exactly when I want...

[Tronic]

The redraw method in Ruby Edit is only a mere control to request a redaw for the required area,
and it will run from side C ++, doing it whenever he wants and not the time that you request,
at least not when you use it with Flowstone editor,
because other real redaw are required to ensure that the editor has the window or portions of it to date,
and the system is connected and not be unbundled,
therefore, not predictable or better I would say scheduled and executed as soon as possible.

example:
When I make a request to redraw,
it is placed in a queue list and executed when the system (side C ++) performs the routine to update the graphics,
so not in our real control, with respect to the actual execution order with other items.
But I always prefer to think that it is performed, always after RubyEdit has finished its function.

Triggered an RubyEdit
-> Execution Thread (I think it is an ruby ​​Fiber event)
-> The Process
-> send commands in a queue execution list to the side C ++
-> Thread End (or Fiber event terminated or suspended)
-> Now the side C ++ run its requested functions from the queue.

at least this is my guess of how it really could be.

[Nowhk]

The redraw method in Ruby Edit is only a mere control to request a redaw for the required area,
and it will run from side C ++, doing it whenever he wants and not the time that you request,
at least not when you use it with Flowstone editor,
because other real redaw are required to ensure that the editor has the window or portions of it to date,
and the system is connected and not be unbundled,
therefore, not predictable or better I would say scheduled and executed as soon as possible.

example:
When I make a request to redraw,
it is placed in a queue list and executed when the system (side C ++) performs the routine to update the graphics,
so not in our real control, with respect to the actual execution order with other items.
But I always prefer to think that it is performed, always after RubyEdit has finished its function.

Triggered an RubyEdit
-> Execution Thread (I think it is an ruby ​​Fiber event)
-> The Process
-> send commands in a queue execution list to the side C ++
-> Thread End (or Fiber event terminated or suspended)
-> Now the side C ++ run its requested functions from the queue.

at least this is my guess of how it really could be.

I see. I'll consider it as "out of my control" so. Thank you for clarify this

[Nowhk]

For a better understanding...

The redraw method in Ruby Edit is only a mere control to request a redaw for the required area,
and it will run from side C ++, doing it whenever he wants and not the time that you request,
at least not when you use it with Flowstone editor,
because other real redaw are required to ensure that the editor has the window or portions of it to date,
and the system is connected and not be unbundled,
therefore, not predictable or better I would say scheduled and executed as soon as possible.

Is this true only for draw method? Or also when, for example, I invoke the RubyEdit "output" method?

I mean, output will immediatly run when called (switch to FlowStone/C++ context when called and exit from Ruby Component as Trigger data) or it is processed in a unpredictable way by C++ as soon as possibile?

Ruby is a part where FlowStone need to switch the context between its own language (C++ I guess) and Ruby itself, would be nice to get this point for me.

[Nowhk]

I've just see you had posted this message time ago, Tronic: "and then writes and reads continuously from memory"

It seems that outputs (the bridge between Ruby back to FlowStone) could run at different times from which they are called. If this is true, how can (for example) MIDI be sync internally of FlowStone when I create/manage/trigger them with Ruby (that is 100Hz accurate)?

I mean: if I generate a MIDI message and I stop it after 1 second:

Immagine.png (15.47 KiB) Viewed 16510 times

Ruby MIDI Note On-Off.fsm

(8.01 KiB) Downloaded 857 times

who can guaranteed to me that it play exactly at time t and ends at time t+1? Ruby events are sync/scheduled to run at those fixed times, yes, but later MIDI will takes time to process/output to the following step (i.e. from my code to the input of Osc).

I know that every sample of type stream happen at correct timing, because FlowStone take care of this (following my not-proof idea about how FlowStone audio works); I think in the usual way of doing DSP using buffers: process data, create frames of samples and send them to ASIO (or trasmitted to the DAW that will treat them), but is this really true also with MIDI?

[Tronic]

However, as the manual says when a primitive external Audio is on,
it is synchronized and processed with the same sample rate,
but from my test I have determined that it is processed with an identical frequency,
but equal to the size of the audio buffer.
If the trigger is generated by a green, is not as much as it is ensured that the "t + 1", actually ends at "t + 1",
but we must think, when exactly the green will run?
And that is where the synchronization fails,
And in any case the "t + 1" is guaranteed.

Then also consider this:
In my opinion, from c++ side,
the Midi Queue Buffer does not run in the same thread-function of the audio,
so does not guarantee synchronized performance of it.

[Nowhk]

If the trigger is generated by a green, is not as much as it is ensured that the "t + 1", actually ends at "t + 1"

Ok sorry, I've wrong init point. Let says that the trigger is generated by a Frame (from mono to frame prim), at a fixed speed by DSP code (audio): Ruby events runs exactly sync with it (I trust this).

But what about MIDI (i.e. the part I'm interessed)? That's the point. I don't care if Ruby event execute in time, I care that what I create inside this task is executed in time

Once Ruby event run, to generate, manipulate and than send my new MIDI to the output (and than processed back to FlowStone/C++ again) it will requires overhead. Is it included in the Ruby/event time syncing this?

Then also consider this:
In my opinion, from c++ side,
the Midi Queue Buffer does not run in the same thread-function of the audio,
so does not guarantee synchronized performance of it.

Is it normal that inside an audio development environment, MIDI (which is fondamental in audio) could be not sync? I don't believe in this... I think I'm missing somethings...

[Tronic]

Welcome to FS limits

[tulamide]

I think there's a general misunderstanding. In germany we say: "Zäum das Pferd nicht von hinten auf." A look at dict.cc tells me that the english equivalent is "Don't put the cart before the horse".

Flowstone's task is to sit as a slave in a DAW and react to everything the DAW requires it to do. And that's exactly what it does.

A midi signal comes in from the DAW, Flowstone sends audio out.
A midi signal comes from the DAW, Flowstones sends the changed midi signal out.
An audio signal comes from the DAW, Flowstone sends the changed audio signal out.

With delay compensation, everything is exactly on point. Does MIDI need to be sample-precise in sync? Not at all! Under circumstances it even can't be! MIDI precision is defined by ppq. While modern DAWs work with 960 and more, older ones and FL Studio only work with 96 ppq. But that doesn't matter much. The output of Flowstone is buffered, which means, everything will be on point at that moment, even with low ppq. Only if your task exceeds the time the buffer is played, you will get in timing trouble. The result is stutter, clicks, noise and such. As long as the output sounds great, everything is right on time.

But reading what you are complaining about let's me assume you don't want to create a plugin, but a host. Because only a host needs to be perfect in midi timing to be able to control the flow of things. And Flowstone was never build to create a host with it. Nor will it ever.

[Nowhk]

Flowstone's task is to sit as a slave in a DAW and react to everything the DAW requires it to do.

And what about if you use FlowStone as standalone application? (not my case, but just curious).

A midi signal comes in from the DAW, Flowstone sends audio out.

With delay compensation, everything is exactly on point.

With audio/stream, this is true, all is sync! Its also written and documented in the manual.
But... also with MIDI? They are "trigger" data types (i.e. green), and its written everywhere that green are not sync with audio (its the first/important rule I've learned in FlowStone). Since they acts as green, who can assure to me that they are treat in sync with audio? If DAW send event data (i.e. MIDI) and FlowStone has not a control rate sync with audio (because of the green nature), how can process audio sync with them? Or the story about unsync green is partial true for this kind of process?

I'm really confused here, and I'd like to understand this missing part of FlowStone (very important to me, but I can't got it since lack in documentation). Please, can you shine me?

But reading what you are complaining about let's me assume you don't want to create a plugin, but a host. Because only a host needs to be perfect in midi timing to be able to control the flow of things.

And if I'm just making an arpeggiator? FlowStone can't do it?