DSP Robotics Support

Possible evidence for entangled triggers

I noticed, that oscillators (at least sine), when they get value = 1/0 (time instead frequency is provided, so f=1/t and if t=0, then you know, veeeery huge value) - they get stuck until stream connection is broken. But...

In scenario in which input is sent to "select" primitive first and then to "equal" primitive ("if value = 0, then switch to second input" condition) - oscillator is running. Which means - despite the trigger order (first send through selector, then to condition), oscillator is not receiving buggy value as it would if the triggers were not collaborating secretly.

Have not tested yet with timer separation which provides slight delay, but maybe tomorrow.

Yes, that would be right.
When the "value" input of the selector sees a trigger, it causes a "call back" trigger from the "select" input, to immediately update the selection value, even if the selection value hasn't seen the initial input trigger yet.
When the initial input trigger then does arrive at the 'select' input, it does nothing, because the selector recognises the trigger by its ID tag, and knows that it has already been acted upon.

That's the tricky bit of the trigger system - the invisible "call back" triggers ("secret collaboration"!)
In fact, the selector is about only way to easily 'see' these "backwards" triggers - here's an example...

Change the selector to the unselected input - as expected the selector doesn't switch because of the blocker. But set it to the unselected input, and then press the trigger button. "Magic" - the selector switches over, even though no trigger has come into the input side.
Because the selector has the little picture showing the routing, it can be used to check for reverse triggers in cases where you think they might be causing a problem - they can cause things to update before you expect sometimes because they propagate backwards a very long way, unless you block them by using sample-and-hold prim's.
That may well be why your zero values are sometimes still getting through, but I'd have to see the schematic to be sure of this.

Here is an experiment. Run audio and type "0". Some oscillators will be blocked, even if you change the value again to something else.

Trigger separation by order logic works here differently than separation by time event.

And by the way - oscillators could have some internal min/max by default, to avoid such accidental situations.

tester wrote:oscillators could have some internal min/max by default, to avoid such accidental situations

Yes, I agree with you there.
It's quite a common situation with oscillators, filters etc. - anything where the next value has to be calculated from the previous one. Once there is an infinity in there somewhere, the next value cannot be calculated - infinity + x = infinity etc. And it is certainly good programming practice to protect as close to the 'sensitive' part as possible.
The only reason I can see for the lack of protection is to save a very small number of CPU cycles - but IMHO, especially for software like this, designed to minimise programming effort, I would thing the bias should be for more protection.

Your schematic does exactly what I would expect - but I think it maybe shows that there is something I haven't explained too well - a misunderstanding about your meaning of 'entangled'... (and lack of explanation in the User Guide too!)

The rule that a trigger must be 'finished' before it can take another path always applies within the SM schematic - but timers behave like MIDI - the 'start' trigger is sent outside the schematic to Windows.
Just like MIDI, the act of sending the 'start' message to 'the outside' counts as 'done' for that trigger path, and other trigger paths (and other new triggers) are free to proceed without waiting for the timer to end.
The trigger that finally comes out of the timer is a completely new one, unrelated to the 'start' trigger - again, much like MIDI, it behaves as a new 'external' event.

This is why the 'timed' selectors are free to lock the oscillators - the trigger sets off the timer (done for that path), and then is free to proceed through the selector, because the selector doesn't switch until the timer returns its new event.

So any unpredictability is not caused by the trigger system itself, but the fact that we have given some control to an external force - just as we can send MIDI, but never be sure if the destination will actually play a note!

It also explains what is meant by the "race condition" jargon that I mentioned before.
The timer counts for a indeterminate amount of time (the value input is only approximate). Other events inside the schematic can happen at any random time too (user moved knob, new MIDI note). We can approximately know when either of these two things might happen, but it can never be known 100% for sure which will happen first - hence the analogy of a race.

this "trigger separation" is complete bullshit. You shouldn't use timers for this. As Trog stated earlier, timer primitives use windows timers. They are not guaranteed to fire anyway, especially when the window they are defined in is minimized or hidden. Windows is also allowed to kill timers, when the queue is full, or delayed by CPU intense processes.

I also don't think that there is anything wrong with the oscs input boundary. The freq connector clearly says: "freq in range 0-1". So it's definitely the users fault when he doesn't provide valid inputs.

I disagree. It solves some practical problems, not solvable (ambiguous, FS bugs) or difficult to handle with "order logic" only. Tested. Good makeshift is not bad if it works.

Hi Steven,

can u please have a look @ ur 'Settings File Manager'...

maybe a déjà vu:

Cannot '[Recall Defaults] - Restore all settings to the stored default values.'!!! in SM or FS...
from the default 'Custom Setting'

cheers,
Walter

Hi Walter, nice to hear from you.

Seems working fine here - but "here" means correct folder names are likely saved into the schematic.
Take a look inside module, Settings File Manager -> File Handling -> Paths - does the folder path look right? I only made/used this with Win XP, so I wonder if maybe it is a folders/file permissions problem?

Yeah - i'm more of a silent observer lately....

2 much ruby 2 explore

I wonder if maybe it is a folders/file permissions problem?

Nope: everything under control here in win 8(6) - All in \Roaming\path
Open works fine and a new ini will always be generated...

But - if i kill the ini and click on [recall defaults] the defaults are only saved from sample - not from the properties:

MyCo wrote:this "trigger separation" is complete bullshit. You shouldn't use timers for this

tester wrote:I disagree. It solves some practical problems, not solvable (ambiguous, FS bugs) or difficult to handle with "order logic" only.

I agree with Myco here tester...
I know at times it's usefull...but if ever i have to do it in a circuit to make it work...
to me it means I'm doing something wrong....
I find the need for it a clear sign I'm going about creating the circuit the wrong way...
In other words...using it i always feel like I'm cheating...