Experimental Tick to "Bool" and Wireless multi send.

[Tepeix]

Hi, here's a very experimental way to do with ticks and boolean.

Seams to works for now, i want to use it, but do you think that some bug could happens ?

I also have a module called Trigger Pulse based on the Timer prim. But i don't know from which time it come and who made it.
I was always a little reticent to use it as i think what happen if i introduce a very short time ?
Is it possible that he will not do a second tick ? But if i introduce a longer time it could make other's problems.

I wanted a tick to boolean that could be true only for one frame of windows time.


So finally i end up with this little "hack". The boolean will be true then false for the same frame.
But using some technique it's possible to recall what it be or to sample hold a value only when it's true.

I wanted a way to transmit value wirelessly with multiple send.
This is to avoid to connect a lot of cable and last value prim.
The problem is that wireless send will add their value when having the same name.

So the tricks is that each of them will send 0 normally and only send a value when the boolean is true for less than a frame.

Using an array, each module could send an ID to said who he is and some information.
This way it's more easy to copy paste those module whit no need to cable them.

Of course, the system need that only one module could send at one time but i think that most of time the control of flowstone make it impossible unless we really want it.


What do you think of this technique ? Could this introduce some problems or unreliability ?

[R&R]

If you are not careful you will end up with green logic like the one inside my plugin ...and I'm not sure that's
optimal
My plugin is full of delayed switches of different variations. They seem to solve issues sometimes, usually when poly and mono is causing problems, but not rarely they introduce other unwanted behaviour

Here two other crude variants of regular swicthes...

Delayed_trigger_switches.fsm

(684 Bytes) Downloaded 364 times

The boolean will be true then false for the same frame.

Frame as in an update interval ("one" update propagation) of green logic you mean?

A good litmus test in my mind seems to be to always test it with ruby in different ways to see if any triggers are lost or code is failing to run properly due to value non updates. For example when running even more in parallel... since usually there will be atleast some Ruby running in alot of flows.

Do you have an example scenario for how you intend to use your trigger to bool?

[Tepeix]

Hum yep, if you use a lot of timer it could maybe add problem, depending of what you do with them.

The problem is you don't know how many time it will take for the trigger to flash, even if you give a value in ms it could change a lot.
Normally ruby could have a better if not perfect timing, but it take some cpu.
Also if you have other green calculation or prim involved after the ruby code,they make again the timing unreliable.

So the ruby code might probably send value and not tick in this case.
(i'm not sure because i avoid timer prim but never tested timer in ruby..)

Maybe in your case it's possible to make a blue code that delay a boolean or some parameter ?

But what did you need to input inside stream or poly code in a delayed way ?

[tulamide]

I wanted a tick to boolean that could be true only for one frame of windows time.

There is a conceptual error in this.

Green does not have "frames". It is event based. This means, if you trigger something, everything connected to it will be triggered as well, even back triggers (for example to get a value from a prim).

It's still so fast, that you don't see a change, but it's not a frame, a slice, a cycle, or whatever you want to call it, of time. Even if it would take seconds to execute, it would still do it.

Ruby is a mixture of event based and frame based, in that it is event based like green, but since it is "external" to Flowstone, it has its own refreshing engine running at most 100 times per second. In other words, the amount of triggers coming into Ruby will be worked on 1 trigger per 0.01 seconds (that fast only, if the amount of code allows it).

Trog and more recently also Spogg made tutorials about triggers in green.

Back to your schematic, you just trigger twice, then filter out one and continue.

[R&R]

Maybe in your case it's possible to make a blue code that delay a boolean or some parameter ?

But what did you need to input inside stream or poly code in a delayed way ?

My plugin is simple. In my case I only use them to switch selectors in order... or to force schematic reloads, with enough time for updates. The exact timing is irrelevant for my purposes so I set timers roughly to 50-250ms.

There is of course a fallacy in using timers and selectors as I do. Something i'm aware of... The reason I use them Is because pure switching without order breaks my synth. I think it's is because of the sheer amount of schematic that is switched using selectors. This was never a problem in the beginning of my project but as it grew, simple parts of the schematics started to cease to function, unless I cleared audiostreams or forced a schematic reload by a single selector or a selector in sequence to the shematic that stopped working.

I'm going to try and remove some of this stuff later on but some things I don't think can be removed that easily, especially stuff related to preset-parameter loading and also "wait-dialogs". I would have to have something that tells me the "state" of the flowstone schematic or individual prim components in that case.

Ruby is a mixture of event based and frame based, in that it is event based like green, but since it is "external" to Flowstone, it has its own refreshing engine running at most 100 times per second. In other words, the amount of triggers coming into Ruby will be worked on 1 trigger per 0.01 seconds (that fast only, if the amount of code allows it).

In reference to what tulamide wrote I could have replaced the timer and just run a 25 tick to the ruby instead of a timer, and even divided that... and let a ruby check the state of the last component in the chain to complete it's update. But I very much wan't to avoid running any costly Ruby and introduce interconnection if possible Best is of course to keep everything event-driven as much as possible as with regular code.

I have no clue what i'm doing alot of the time

[Spogg]

One thing for sure is you can’t rely on anything in the green world to be time-accurate. Green calculations have the lowest priority for the CPU so if a lot of green triggers and stuff are happening, any timing will go off. It will depend on what else is happening at the time so is unpredictable. Schematic size will influence the predictability too, depending on how much green activity is called for at any one time.

Also the green world’s timing isn’t related to Windows frame rate (video frames per second).

If timing is critical it’s best to use blue or white stream, because the timing is based on the sample rate and streams have the highest CPU priority.

I’ve attached a schematic in green which I think does what you want with no timing related issues.

[tulamide]

But I very much wan't to avoid running any costly Ruby and introduce interconnection if possible

Why do you think Ruby is costly? It is at the same level as green and in some instances, due to clever programming, even faster.
Ruby is only costly when compared to streams. If you want to work on audio buffers, Ruby allows that, but is loads of factors more CPU intensive than blue.

Whenever it is about a green circuitry, chances are that a Ruby alternative is faster in execition. It's definitely not slower.

EDIT: Also, Ruby is synced to audio rate. That means, when trigger something from Ruby, it will be sample precise on time. A huge advantage over green.

[Tepeix]

Thanks Tulamide, Thanks Spogg very cool system !
Héhé why i did not think about this very most simpler system !!)
So if i understand well, each time a tick is done every module send a last value of zero,
except for the one from where the tick is originated.
I adopt this clever system thanks !)

Hum yes i understand more how to tick process, not a frame, but every green thinks react to some change or tick.

For the Ruby delayed ticker, not sure but maybe if the ruby code send boolean, who know if the selector is really in green timing or if it will be in ruby timing in this case ??

[R&R]

But I very much wan't to avoid running any costly Ruby and introduce interconnection if possible

Why do you think Ruby is costly? It is at the same level as green and in some instances, due to clever programming, even faster.
Ruby is only costly when compared to streams. If you want to work on audio buffers, Ruby allows that, but is loads of factors more CPU intensive than blue.

Whenever it is about a green circuitry, chances are that a Ruby alternative is faster in execition. It's definitely not slower.

EDIT: Also, Ruby is synced to audio rate. That means, when trigger something from Ruby, it will be sample precise on time. A huge advantage over green.

True true

I meant that if I can't retrieve the state of something I'm forced to have to "tick" the ruby to check, or maybe have it interconnected to trigger an event so it can process some awaited value that indicates the overall schematic state change. For example in regards to the flowstone engine itself...
Can I have like... an "execution stack handler made for newbies" Maik? I know your hiding it lol...

Well I as wrote, I don't know or understand that much of FS... and are not much of a programmer so. I'm the worst kind of simple person

[Spogg]

So if i understand well, each time a tick is done every module send a last value of zero,
except for the one from where the tick is originated.

Sort of!
When you give a trigger to a module that actual module gives the output via the Last prim and all the other modules get the trigger to set zero on their Last prims. It’s the basic principle behind “Radio push buttons” where the last one pressed is retained and only one can be pressed at any time.