DSP Robotics Support

tulamide wrote:If you want to first evaluate "stereo" before "samples", program it that way. Wait until both triggers happened, then execute your branch of code that deals with mono or stereo, depending on the stereo tigger.

Code: Select all

def event i, v
    if i == "samples"
        @triggers = @triggers | 1
    elsif i == "stereo"
        @triggers = @triggers | 2
    end
    if @triggers & 3 == 3
        #now both triggers happened, both data are available
        #...do whatever code
        @triggers = 0
    end

That's "so" dangerous. Let say you have 3 triggers that happens at the same time (1 from data on connectors stored in the schematic, 1 from Preset Manager and 1 from AfterLoad) that sends respectively "samples" and "stereo":

loading 1: 2000 samples, stereo 2
loading 2: 3000 samples, stereo 1
loading 3: 5000 samples, stereo 2

If two "samples" trigger are invoked before any "stereo trigger", there's a problem (since there is no order/stack, that could happens).
Or also if combination of triggers happens, such as it got "sample 2000" from loading 1 and "stereo 1" from loading 2.

Of course I need to rely on how code is executed. Or at least, know how it is executed, so I need to prevent/block previous triggers before send them to Ruby (in this case).

I don't think FlowStone works with thread (else, lots of stuff will crash). I guess it works in a fixed/sequence way (as for many audio application environment). In few words, I think that once a trigger start, it go to the end, whitout any other threads during its ride. But I'm not sure of course, that's why I also ask this kind of stuff

Nowhk wrote:I don't think FlowStone works with thread (else, lots of stuff will crash). I guess it works in a fixed/sequence way (as for many audio application environment). In few words, I think that once a trigger start, it go to the end, whitout any other threads during its ride. But I'm not sure of course, that's why I also ask this kind of stuff

That's why you will have a hard time with Flowstone. You're always guessing. You want it to behave in way that you are comfortable with, instead of accepting how things actually work.

You asked, and I gave you the solution. The description you gave, as to why you think that would be dangerous (but not your own way of hoping that events come in an assumed order, doesn't make sense. You will notice it after you've actually tried it. Also, this was just one example. Again: you are responsible for a code that deals with all possible situations!

I'm already bugged again, and that's just because you ask the same things over and over again, but refuse any answers (obviously until you get an answer you want to hear). I can't ignore you, that's against my helper syndrome, but I also can't help people that don't want help, but confirmation. And I simply can't confirm what's wrong.

Please, no man! Don't see me as this kind of person! I guess it's due to my lacks in english, and I'm not able to express myself I'm absolutly not that kind of man, which is happy manipulating things! I'm so rational, and I feel bad when I don't understand stuff. That's why I'm often here these days: I'm totally addicted to FlowStone, and I've a great project in my mind.

Say so, I've read more deeply the manual, Chapter 8, as you suggested, and got few things I've missed.

First of all: Events Data (the ones in Ruby for example) are scheduled. And when I call "time", that value is not the actual time when I call it, but the scheduling time. That's why, with two different trigger, I can see a "time" value which is the same. And that's also why the execution of two different triggers can occurs in two different times: they are just scheduled in two different time (my t1/t2 different times issue above).

Triggering Data instead is somethings like "proceed and do things as soon as possible", so no scheduling. And how you have noticed, this is unpredictable (since they can run with multi/core/thread, even if it is not documented); just, don't rely on them.

Well, this back to the question above (which makes no sense for you).
If this is my situation:


I can have some problem with that "double check" variable you suggested. When I load the VST, first things that happens is the Mem2F trigger Ruby and send the array (using Event Data) previously saved in the schematic (let say Sample A, stereo).

Than, FlowStone will trigger After Load OR Preset String (which contains the path of Sample B, mono) due to how it "feel" in that moment (unpredictable, can't rely on it). It can happens that samples from Preset String, its Number of channels and the trigger of AfterLoad is scheduled to Ruby at the same time.

And if the trigger of After Load is executed after have stored to @stereo the value 1 of Sample B and before change the actual samples of it, I can have a inconsistency (it will draw Sample A mono).

Does it makes more sense?

Not really. First of all, there is no scheduling of events other than the normal serial behaviour of the processor. The scheduling you read about is an option for you as a programmer to use as you see fit. Events happen whenever a trigger is sent. A trigger is sent (in green), whenever a prim is executed.

I won't talk about the basics (what triggers in Flowstone are and how they actually work is said a billion times and can be looked for in search engines/this forum/the user manuals. But realize that the wave prim sends out 2 (!!) triggers. One is sent on the mem link and one is sent on the int link!

So no matter how many times you activate the wave prim, there will always be one "samples" and one "stereo" trigger at once. You just don't know which one comes first. The code is taking care of that bitwise or'ing a number, and checking bitwise and to have exactly the two bits active, before processing whatever code there is. And you would have noticed that, as I said, if you at least had tried the code.

1) Triggers notify other prims/modules
2) Triggers are sent immediatly when action that causes them is done
3) Ruby listens to inputs via event method
4) There is no scheduling going on, a trigger arriving at an input forces the execution of the event method.
5) You as a programmer have the opportunity to schedule a method or input, for example to delay an execution. But that's totally up to you. No use of time means immediate execution.
6) Ruby runs in its own thread; that's why it has a higher cycle rate (it runs at stable 100 Hz, while green runs unstable somewhere between 1 and lower than 100, depending on processor load) (simplified explanation!)
7) audio runs at samplerate; behind the scenes it runs much slower, but it uses double buffers and such to provide editing at samplerate.
8) Any attempt of synchronizing events will fail, unless you use techniques like the one I showed you in my last example code. There are others, but they're also more complicated.
9) If things don't work as you expect, your expectation is wrong and you have to re-think! (unless there is a bug)
10) Don't start with big projects! If you are addicted, you should work on small projects first and get used to Flowstone and how it works. If not, you wouldn't finish a big project anyway.

I can't say anything more about this topic without constantly repeating myself

tulamide wrote:So no matter how many times you activate the wave prim, there will always be one "samples" and one "stereo" trigger at once. You just don't know which one comes first.

2) Triggers are sent immediatly when action that causes them is done

That's the pain I don't get
Let suppose I've Trigger T1 that execute prim P1, and it generated (as you stated) two new triggers (TA and TB).
TA trigger directly R1 (path 1), while TB trigger P2 that trigger (TC) P3, which ends to R2 (path 2):



If there is no scheduling, and another T2 trigger P1 while (for example) P2 is triggering P3, who can guarantee to me/you that the second execution of R1 (reached by second trigger T2) will be executed after the first execution of R2 (reached by the first trigger T1) if there aren't any kind of scheduling?

NOTE: my misunderstanding it's not if R1 is executed before R2 (for every "parent" trigger), but if R1 (generated by T2) could be executed before R2 (generated by T1). i.e. if at least "chain" of triggers are sequenced. Or is it all "first arrive, first execute"?

If it so, I need to change my whole approach to FlowStone...

Nowhk wrote:If there is no scheduling, and another T2 trigger P1 while (for example) P2 is triggering P3, who can guarantee to me/you that the second execution of R1 (reached by second trigger T2) will be executed after the first execution of R2 (reached by the first trigger T1) if there aren't any kind of scheduling?

any way it doesn't matter as long you avoid situations like this, as i was already writing above take control over your triggers if a operation only can be done after another one is done then YOU need to take care about!

it makes no sense to brainwank about some theoretical situations all the time, just do your things and if they don't work search for the problem and fix it, or if you don't know any behaviours test it and find it out!

shouldn't be too hard with 18 years experience in programming..

Nubeat7 wrote: any way it doesn't matter as long you avoid situations like this, as i was already writing above take control over your triggers if a operation only can be done after another one is done then YOU need to take care about!

But I don't think this is "brainwank". To know how things works matters a lots in my opinion! Because if you say that this thing of stuff can happens, I need to take care about every link in FlowStone.

Also your awesome job could suffer this problem so:


There, it's sure that "update" get a trigger after "lmin" (connector "order" is set when connecting the prims), but for the same reason stated above, you can't be sure that "lmax", "min" and "max" [F]s connectors get the values from each trigger before "update" will be invoked (if triggers go without scheduling/order/as fast as they can).
For example, FlowStone could execute "lmin", "max", "update", "lmax" and "min" (and these last two will occurs when update event has already be processed by Ruby).

This will be a problem, no? I ask That's my uncertainty... and I just ask you to understand this right now; I'm not proving or insulting your knowledge (again, I think the "rude" tone you get by me is about lacks in languages, and I ask sorry again).

as i stated above i didn't work out the schematic that it works perfectly, things like error handling and error prevention isn't handled, it is just an example how it can work and maybe there will be some bugs to fix, as far as i tested the schematic it was always fast enough to load all 4 array connections before the update trigger invoked the coordinate methode, but sure if you will get in trouble becasue of that, or you just want to get sure, you need to check if the 4 array inputs are valid before you process the coordinates,
anyways before iterating through arrays they always should have been checked (to be honest, i'm really lazy with things like this)

or you are just using one array input, split the arrays inside ruby and process the coordinates so everything can just happen one after the other,

(But you can't check the arrays if you don't know the origin of them (i.e. which "chain" of triggers generate them). Inside Ruby you can get array from different triggers, and you can't filter at the beginning, because you don't have control of source. See below for what I mean...)

Well, so this seems to be true: there isn't any sequence on how triggers are invoked. This is a huge pain in some situations.

Since there isn't any kind of tracing about triggers (i.e. you cannot know the parent in a trigger chain) and say that some prim acts without any kind of control by yourself, I think some task will work if you are lucky enough.

Take the example of Preset String prim It will output/trigger two, when FlowStone want and if there is data on preset itself (else only one time, the value loaded in the schematica; but you can't know this). And you can't know for example if the first trigger of the module is by preset or by data in the schematic (since all is unsequenced).

Or maybe (the fact it trigger twice) it's just a bug, and once fixed it (and I know it trigger once), I can "Trigger Switch" it once the first part of data (from schematic) is loaded. If it is not a bug, I really don't know how I can fix it. If not cross the fingers I'll open a ticket with this "bug-related".

And for the moment I'll ignore this till I get issues, be "lazy" as you. But I don't like do this at all...