Trigger Thread

[gvalletto]

Hi all,
Can anyone tell me where get explanations / examples of the "Trigger Thread" prim/component? I have not found anything about it in the FS manuals.

[Spogg]

It’s an R&D component and I’ve never used it or seen it used. The popup info doesn’t really help and it also says it’s unstable.
Maybe you could test it somehow and report back…?

[Tepeix]

Maybe it's a little like an old module from Synthmaker, the De-Threader ??

Where the help text is : "De-threader\nTakes an input trigger that may originate from another thread and outputs a trigger that runs inside the main application thread\nThis is useful if you want to trigger timers from MIDI events for example"

I never truly understand this description.. But i remember that it make a tick happen in the next tick time. Or delay from one tick..

Doing the experiment with a counter we could verify this.. But now there's a little difference if we use the synthmaker module or the beta module to feed the counter...

[Spogg]

Well, I tried several things to see if it made any difference and came up with nothing.

If only trogg was still around…

[Tepeix]

The difference is very subtle for me, if i use the synthmaker one to feed the counter,
they will read the same value, but if i use the flowstone trigger thread the synthmaker one will read one tick latter the result of the counter..
That's mysterious

[Spogg]

Yeah, I set up a very elaborate system with 10,000 floats in series in 2 “channels” with mono readouts and ASIO on (to try and load the stream handling) followed by various trigger counters. I used the MIDI mono prim with counters to time the gap between playing 2 different notes (any notes).
I could sometimes get a difference of 1 trigger count with the Thread prim in various places and configurations. I found it inconsistent at all points so I didn’t think it worth sharing. Basically I couldn’t get it to repeat reliably under any operations.

At some point I’ll mess around with it in a real synth when it gets big, because that might reveal what it can actually do.

The developer wouldn’t have gone to the trouble of making a prim which was useless, so I remain intrigued!

[tulamide]

Do yourselves a favour and don't fool around with program threads, especially when the tool provided is in R&D, and you don't know about the topic behind the tool.

I could explain what a thread is, but others have done so much better than I could. For example here:
https://www.geeksforgeeks.org/thread-in-operating-system/

In the alpha, MyCo already makes use of threads in abundance. That's nothing very important to have as a tool. And if you followed the explanation above, you should know by now, that a delay of any length is actually a bad sign.

[R&R]

Do yourselves a favour and don't fool around with program threads, especially when the tool provided is in R&D, and you don't know about the topic behind the tool.

Threads

Can't contribute to the topic of actual "threads" but I have some newbie contemplations about timers...

It's enough frustrating to work with just regular delayed triggers using timers (within what I guess could be said to be the "main green thread" )

Not having any control of underlying code... and creating actual new threads, and any asynchronous behaviour that follows feels like an awesome way to crash FS
Threads would seem to make more sense when not using somewhat of a "blackbox" environment like FS is?
I still don't understand if Ruby runs in same thread as green (by FS itself, that is).

I'm working very little with FS4... so I don't know If there is any way to accomplish it... but I do "sort of" miss a listener system in FS3.08... like a system with some predetermined flags that FS can raise when finished with updating poly or other hardcoded things, that then can be used to create consecutive triggers in green.

In general... regarding regular timers... The more timers I have the more issues I get in my synth so I'm always trying to get rid of any. But I do have some left.

Mostly for two purposes...
To make sure an inital trigger propagates throughout the schematic and force FS to do that update.
And... also for creating what in the analog world would be the "knob" equivalent of a "button bounce protection" (I don't know the english translation) to reduce update frequency. For example when a condition is only met intermittently and any update only should occur when condition is met within a given timeframe.

I'm dealing with well over 600 poly selectors, probably much much more... switching on preset changes and when resetting these in my synth. The amount of green selectors/multiplexer and other spaghetti I've lost track of completely

Btw Tulamide...
Indirectly related to triggers. I'm in the progress of moving to using string presets parameters in my synth and getting my switching/resetting system to work was a nightmare I almost threw my laptop out the window several times.

The trick became to retain values correctly. Simple S&H prim logic alone didn't do the job. But I think I got it to work now, using unnecessarily elaborate trigger switch logic LOL
Unfortunately changing presets takes even longer than before string presets. But that's fine...

[tulamide]

Threads would seem to make more sense when not using somewhat of a "blackbox" environment like FS is?
I still don't understand if Ruby runs in same thread as green (by FS itself, that is).

Correct, that's why I said, to leave it up to MyCo. In the early days of Synthmaker, there might have been applications for this, but in the alpha, MyCo has optimized everything to its optimum already.

There are 3 main threads. The main Flowstone loop, all the schem editors, the GUI and green are in one thread (that's why a plugin runs smoother than in Flowstone), all streams are in one thread and Ruby runs in its own thread. The latter is only true for version 3.0.6 and the alpha. In other versions, Ruby accidentally was moved as a sub-thread to the main thread, making it extremely slow.
Apart from those main thread there a many sub threads, which are children of their respective "mother"-thread. However, all of this is not necessary for us to know. That's all behind-the-scenes stuff, that won't help us using Flowstone.

Just do, what you want to do. Flowstone will make sure it runs, albeit with varying results.

[R&R]

Good and useful info as usual... thanks tulamide!