Misbehaving Triggers

infuzion · 14 Apr 2010

Finishing the multi stage modulation envelope The "Reset to 0" did work not long ago, now does not. It relies on the index of the point & a trigger pushed through the same index Integer to work. Now it doesn't.

oddson · 15 Apr 2010

Here are two examples which I think would not previously have required the trigger tick to get the desired results:

Assuming there may be something OSM specific in the behaviour here's the not-too-secret project they're from... (a guitar tuner)

One is from the readout values module the other is from the get string and note of string module inside the find expected pitch/display string module

infuzion · 17 Apr 2010

Now I feel embarrassed since an OSMs that didn't work properly a few days ago now do. hmmm

oddson wrote:

This seems to be working for me with & without the trigger "kick"; either way I get both the readout & audio note. Actually, it works better with out the kick since with the kick about 200 triggers are sent for each note. But an old value is not triggered again (atleast according to the trigger counter I put in) when a repeat of a note is played.

oddson · 17 Apr 2010

You're right... it doesn't seem to be needed anymore but I assure you I didn't put it there for no reason. At some point along the way it didn't work without it.

I see the other example is similarly not needed yet I can still get the buggy behaviour under some circumstances:

This one seems much more like the one in the original report in that it's a standard math primitive that's not updating consistently.

infuzion · 17 Apr 2010

Ok, perhaps it is not me seeing random non-updates. Seems to happen after SM is open for a while... back to my long-standing suspicion (confirmed by another SM super-user) that SM doesn't write/read to memory fully properly.

MichaelBenjamin · 18 Apr 2010

infuzion wrote: Seems to happen after SM is open for a while...

this may well be, as i not so seldomly get some green wierdness after some time which gets only fixed by a reload.

infuzion · 18 Apr 2010

This looks like another hard-to-track random SM bug.

trogluddite · 18 Apr 2010

Yup, certainly seems random to me. I've utterly failed to recreate the problems with logic schematic that I mentioned in my first post - BUT, an old schematic I decided to dust off, suddenly seems to require the 'kicker' trigger, like oddson's pictures above - (except for the times when it doesn't!). Still messing with trigger counters to see if I can nail something down worth sending to malc.

infuzion · 21 Apr 2010

related? Freq Splitter not Samplerate independent

McBarGig · 7 May 2010

I posted a problem here earlier where I could not get a 1/x to give me the right number...That was a trigger issue and it was solved by adding an int to color like so...

trogluddite · 7 May 2010

Here's another that looks very closely related... 250 + 250 = 752?

infuzion · 7 May 2010

trogluddite wrote: Here's another that looks very closely related... 250 + 250 = 752?

I think you're on to something Trog; good bug-hunting!

Malc?

trogluddite · 9 May 2010

This schematic might narrow it down a bit.

When you move the knob, the top subtract doesn't update correctly, but the others do. You can see that where there is no S+H used, or one S+H is shared, there is no problem - but if both paths have their own S+H, one of them is not updating the subract correctly. I've been looking at some of the other schematics that have this problem here and in other threads - a lot of them seem to include other primitives that (like the S+H) don't just pass a trigger directly from input to output e.g. Array reads, selectors and multiplexers etc. - they are all primitives that either have their own 'done' trigger output or have a 'choose something' input that affects trigger flow in some way. Seems that as soon as the 'output' primitive has received its first trigger, SM thinks 'Great, that's that trigger dealt with' and then ignores other trigger routes which are maybe delayed slightly by needing some processing doing on them.

Eska · 11 May 2010

I too have a variety of switches, all with multiple triggers and S&H inside, that stopped steadily working in 1.17. Maybe the displayed order of trigger connections does not represent the real order anymore? Forget it! 😊

attic · 11 May 2010

Any news? 😠

infuzion · 12 May 2010

attic wrote: Any news? 😠

Nothing official; McBarGig lit a fire under Malc's toes since this is holding up Shred's release, & I got only a "Thanks" when I emailed a possibly related crash report.

MichaelBenjamin · 12 May 2010

it seems this issue is when 2 separate triggers get merged, like in the first example with the two time modules. i have a similar case where 2 random modules get added and i need an additional kick trigger to display the correct value. with a larger schematic this becomes quite irritatingly inconsistent and i had to make a global kick trigger that fires from a tick 25 for half a second to make sure everything gets the right values.

McBarGig · 12 May 2010

Malc's Explanation... "Each trigger in SM has an id. To prevent green feedback loops from crashing many components will only let a trigger with a particular id pass through it once. As a consequence of this there are some occasions where a trigger can be ignored when you don't want it to be."

So, what you need to do is RE-ID the trigger. That way it has a new number and as such will appear different to SM which in turn will allow it to pass. Malc said to use a INT Loop for this as it generates a new Trigger from the original. So far this has worked out pretty well. Although I am still testing...

Here's the fix from Malc to the numberCrazy thing I posted...This has an example of using the int loop for re-iding the trigger...

Hope that helps...

rl · 12 May 2010

pardon me?

I hope that's only a quick workaround until the real fix will be released!

I think there's nothing wrong with feedback loops. Maybe define a certain threshold for passing triggers (e.g. 1000?)

BTW: just tested: a pair of trigger blockers will also do the trick (in this special case):

Thanks, McBarGig for the follow up

Tzarls · 12 May 2010

Don´t know about earlier versions, but just tried the problematic schematics in 1.1.4 and it does the same, so this is not new. Funny that no on ever noticed it before?

Does anybody have 1.1.2 around to test?

infuzion · 12 May 2010

Tzarls wrote: Does anybody have 1.1.2 around to test?

Computer Music (UK mag) coverdisks?

infuzion · 12 May 2010

McBarGig wrote: Malc's Explanation... "Each trigger in SM has an id. To prevent green feedback loops from crashing many components will only let a trigger with a particular id pass through it once. As a consequence of this there are some occasions where a trigger can be ignored when you don't want it to be."

Ah, interesting, thanks for sharing. However, there are times when for instance a simple S&H would block the triggering. In the attached pic, the S&H absolutely will not pass any data, even if you remove the Ticker & bypass the Selector or remove only one of them. So, it seems to me that the triggering system needs revamping.

SM2.0 can not come soon enough. 😠

Tzarls · 12 May 2010

infuzion wrote: Tzarls wrote: Does anybody have 1.1.2 around to test?

Computer Music (UK mag) coverdisks?

What I actually meant was if anybody had 1.1.2 at hand - I have a copy at home (I keep a copy of every release), but I´m not currentlyt at home and was curious to know if that behaviour was always the same.

McBarGig · 12 May 2010

Infuzion I agree, It would be nice to also see more of an object driven approach as well..

In your Schematic, could you not connect the re-id thing that Malc sent me directly to the input trigger of the S&H? Then connect the float and ticker to that?

I'm just curious what the outcome of that is, and I am also curious whether that would affect CPU and if so by how much...The scenario is relatively typical and as such you could need potentially hundreds of those re-id things..

infuzion · 12 May 2010

McBarGig wrote: In your Schematic, could you not connect the re-id thing that Malc sent me directly to the input trigger of the S&H? Then connect the float and ticker to that?

After I tried that & using the Int Loop with several connections I could not see any difference.

McBarGig · 13 May 2010

Weird...PITA...