Trigger Timing

[Perfect Human Interface]

I have an issue currently with handling triggers. I'm converting green into mono stream and then back again using M2F. Problem is trigger values don't go through blue and M2F only sends a trigger if the value is changed from the previous value. In this case I need to carry through a trigger even if the value was the same.

I've attempted to circumvent this by just bypassing the blue segment using a "trigger pass" (a module with the input/output set to only pass triggers) back into the green signal flow, but when I do this the trigger arrives early, before an updated value makes it through. (I hope that makes enough sense.)

Can anyone offer any insight as to how trigger timing is handled? I can grasp the concept of connection order just fine but this is way beyond that in a complicated schematic.

Also, does Ruby pass triggers? I'm using a bit of DSP code, hence the green>blue>green conversion, but I guess if I could convince someone to convert my formula into Ruby that might count as staying in green??

Thanks in advance.

[Nubeat7]

if you want to send a "trigger" in stream can use a pulse..

some schematic of what you exactly want to do would be helpful

[Perfect Human Interface]

Sorry if this is confusing. Here's a diagram I put together. Edit: Imagine there's a ticker there.

Trigger Timing.PNG (19.64 KiB) Viewed 17126 times

A green signal is being processed by a DSP code block, then converted back to green by M2F. The problem is that triggers don't pass through blue, and M2F itself sends triggers only when a value has changed. I need triggers to pass through whether the value has changed or not.

In the diagram I tried bypassing the blue segment by using a trigger pass. The problem with this is that in my schematic the trigger was arriving before the updated value from the M2F, causing incorrect operation.

So the question was just about how trigger timing works in general and how I might be able to manage it. I hope that's a little more clear.

[Nubeat7]

if you trigger the m2f befor you trigger the output it it should update correctly, so trigger order should be 1. code, 2. m2f, 3. output of m2f to get a trigger also when value not changed (so far the source generates one) which means that this is the order to connect the different parts you can see this order with the little black stripes at the beginning of the cable 0 stripe means first, 1 stripe is second, 2 stripes is 3rd ..... , but why are you doing blue to green to blue to green? in general i would try to avoid this

[KG_is_back]

Use analyzer instead of mono2green. Analyzer basically turns Stream to be computed as a Green.

[trogluddite]

if you trigger the m2f befor you trigger the output it it should update correctly,

Even that will be very unreliable.

It has to do with the way that blue streams and green communicate with each other...
As they are on different CPU threads they are not continuously synchronised or constantly talking with each other. As far as anyone has been able to tell, values only pass between the two at the boundaries between soundcard buffers. In this case, this means that triggers to the M2F and output are very likely to be processed before the DSP code has a chance to receive the updated values - the output results are very often those for the previous input value instead of the current one.

Using the analyser, as in KG's schematic, is a very useful workaround if the code simply must be done in stream for reasons of speed - e.g. filling a huge 'mem' buffer with data - or if the data is going to be used by other 'blue' code.

But for more 'trivial' maths (e.g. a single equation) where the final output will be green, the best way usually is to use green primitives to construct the equation. Ruby can also be a good solution, as Ruby will maintain the correct sequence of events, and it has many functions that can't be done in green. But green<->Ruby conversions also incur a small CPU/time penalty - it works most efficiently when you can keep the code in large 'chunks' to keep the number of conversions as low as possible.

convert my formula into Ruby

If you have already managed to put your equation into DSP code form, then it can certainly be done in both green and Ruby. Usually, it's not too bad in Ruby, as the equation will look fairly "mathematical" still, though there are a few odd bits of syntax that may catch you out until you are familiar with it.
Converting to green is often a bit less intuitive. The most important thing to remember is that all maths operation have a priority - e.g. inner brackets happen first, multiplies/divides always happen before adds/subtracts. It's best to work from the high priority "inner" parts first - making them into little sub-assemblies that you then join together using the "low priority" operations.

If you can post up the equation that you want to use, I'd be happy to do a little "worked example" to show how the translation works into green and/or Ruby.

[Perfect Human Interface]

Use analyzer instead of mono2green. Analyzer basically turns Stream to be computed as a Green.

Thanks, I tossed this in and it's functional but for whatever reason it spits out two triggers instead of one, one before and one after, which is similar behavior to one of my previous methods. Basically this just looks bad because in the GUI you can visually see it update incorrectly for a split second before the correct value is assumed. Both outputs of the GetAt put out two triggers, and testing shows that the Analyser is the one putting out two, for whatever reason I don't even know. There's only one trigger going into the recalc input.

If you can post up the equation that you want to use, I'd be happy to do a little "worked example" to show how the translation works into green and/or Ruby.

Unfortunately it's not so "trivial."

Code: Select all

streamin y;
streamin a;
streamin b;
streamin c;

streamout x;

x = (a-y)*(b-c)/(a*(-2*b+c+y)+b*(c+y)-2*c*y)*-1;

[Perfect Human Interface]

I used one of trog's "trigger delays" to delay the trigger output by 1ms. Pretty much does the trick; the delay is noticeable but it's acceptable. A brief delay is better than a briefly incorrect value.

[trogluddite]

And, as promised, here are the other two ways of doing it...

Equation Conversion.fsm

(1.63 KiB) Downloaded 953 times

The Ruby one is a little more complex than strictly necessary, but the method used gives excellent control over the trigger behavior that you want. The green one is cool for spaghetti fans - but using a few modules to wrap the sub-expressions can help with that (there's no CPU penalty for nesting modules).

It was made much easier to do swiftly by the original equation being nicely factored (I only changed one thing, just to remove the * -1). Especially when converting to green, you can often seriously reduce the amount of FS work by taking an equation and refactoring it to draw out all the common terms.

PS) In the green version, there's plenty of values splitting and going off in different directions - but getting the trigger order right took me no time at all - because in this case it doesn't matter. For maths networks like this, the green system works very intelligently, keeping track of the triggers so that you don't get any duplicates.

[RJHollins]

For anyone struggling [like me] to get an understanding of the RUBY basics ... get this example posted by TROG.

Yes ... it deals with equations ... but the 'Commented CODE' is fantastic ... even it just helps confirm what you thought you knew

Thanks TROG !!