Trigger issues with V2.03

Mo · 31 Mar 2011

Seems related to the bug reported here: Slow OR *SOLVED*

trogluddite · 1 Apr 2011

Hi All, I received an email from Malc today regarding the SM2.03 trigger system; it may help us with identifying/de-bugging some of these problems. There are 3 main points...

1) Some SM2.03 users may not even be using the new trigger system! Depending on what previous SM versions you had installed, the new system may not even be running... leading to point 2...

2) Open SM, and press SHIFT-CTRL-ALT-'T' - a little window will pop up with a tick box, where you can enable/disable the new trigger system. You can see here if point (1) applies to you. You can revert to the old trigger system by un-selecting this box - to test if your problems are indeed caused by the new trigger system. (it's not clear if the setting takes immediate effect - so I'd suggest shutting down and re-opening SM, just to be sure)

3) There is one primitive - the Integer Switch - which has changed, regardless of whether the new trigger system is enabled. Apparently Malc discovered that the Int Switch had not kept up with previous SM updates, and so this primitive required re-coding to make it compatible with the new system.

sunsynth · 1 Apr 2011

Really strange Luddite - on my 2 PC's both are unselected 😕

trogluddite · 1 Apr 2011

sunsynth wrote: Really strange Luddite - on my 2 PC's both are unselected

Same here, it seems my problems were caused by the new Int Switch. I get the impression that this will be the case for anyone who has 'over-the-top' upgraded through all the SM2 versions.

I've asked Malc if it would be possible for him to write a summary of the rules for passing triggers - I think it would be really helpful if a least a few of the forum 'gurus' understood the system in more depth. At the moment, I feel that it is very hard to know if trigger problems are caused by genuine bugs, or simply misunderstandings about how is is 'supposed' to work. The bug reported here is a prefect example. According to Malc, it is completely unrelated to the new trigger system, but is a pre-exisiting bug with the array primitive. But, due to the lack of clarity about how triggers work, it's not surprising that we all assumed that SM2.03 was to blame.

aliasant · 1 Apr 2011

Mine was also unselected and Im wondering... Is there anyone here that had it selected?

Activating it screwed up some of my gui but Im working on ways to fix that.

Realizing that my problems I had lately all involved a Integer Switch 🙂

Mo · 1 Apr 2011

Cool, i'd just selected the tick box and things starts to work again. Many thanks.

MichaelBenjamin · 1 Apr 2011

the new system wasnt activated here - i installed 2.03 over 2.02

DigitalWhiteByte · 1 Apr 2011

In fact, within the parameters of the register has been added to an entry: - Trigger Limit, which set the new trigger system

So to implement the changes necessary to close and reopen SM

infuzion · 1 Apr 2011

aliasant wrote: Mine was also unselected and Im wondering... Is there anyone here that had it selected?

Not I. I hope the configuration is saved with exported VSTs & EXEs.

Thanks trogluddite for your extra investigation!

trogluddite · 1 Apr 2011

infuzion wrote: Thanks trogluddite for your extra investigation!

No problem - thanks mostly to Malc, he really is very responsive and friendly when contacted directly.

...and some further clarification from Malc. He says that problems with Int Switches should only happen when SM2.03 is used with the new trigger system disabled - once it is enabled, Int switches will work the same as all the others.

tor · 1 Apr 2011

I also got mail from Malc. But he denied differences in CPU consumption v1 vs v2 SM. Now I checked trig version and now my EQ is down to prox 15% CPU with all audio processing active. A little difference from 30-40% GUI only CPU consumption. 😉

THANK YOU!!!!!!!!!!!!!!

Tzarls · 1 Apr 2011

But if no one had the new system activated, and none of this had been described before (the way to activate it), what was the point of having a new system at all?

Anyway, it would be great to also know the differences between both systems, right?

Sasu Honka · 1 Apr 2011

Unselected here also... All versions updated.

trogluddite · 1 Apr 2011

Tzarls wrote: But if no one had the new system activated, and none of this had been described before (the way to activate it), what was the point of having a new system at all?

Just a mistake by Malc, I think - he realised when we started reporting problems with the Int Switch that he'd accidentally left it turned off.

Anyhow - is anyone else having problems with the feedback detection? My Loopa schematic has gone nuts with red modules and 'Red' links. What is very weird is that the red links make no sense at all - they are dotted around all over the place; sometimes a chain of Red links will have a green one right in the middle of it (and vice versa); some modules have red and green links coming from the SAME input/output; and some are most definitely not any part of feedback loops. Seems to be causing dropped triggers at times too, which has really screwed up my schematic. There's also no way to clear them, so that I can see which button-press/knob-move is causing the red links to show - so I have absolutely no chance of debugging this 🙁 Have to go out now, but I'll post some screenshots tomorrow so that you can see.

Mo · 1 Apr 2011

trogluddite wrote: some modules have red and green links coming from the SAME input/output; and some are most definitely not any part of feedback loops. Seems to be causing dropped triggers at times too, which has really screwed up my schematic.

See Infinite Feedback in the User Guide v2.0.3. There's some changes.

trogluddite · 2 Apr 2011

Mo wrote: See Infinite Feedback in the User Guide v2.0.3. There's some changes.

Yes, I have seen that - the example using only two primitives is very clear - an entire loop is highlighted, as you would expect (and as would have happened already with the previous system). The feature, in principle, seems good - I really like the way that modules containing Red links are highlighted so that they're easy to find too. However, what am I supposed to make of this...

1) There is no loop - seriously, not even off the edge of the screenshot where you can't see. 2) Two isolated Red links - if there are too many triggers (or triggers with the same ID) flowing through those Red links, then why is the rest of their journey not highlighted. I realise that with counters etc. I could track them down etc., but still, the Red highlighting behaviour looks inconsistent - for example, why isn't the lower 'Greater than' also seeing too many triggers?. (In fact, a tick100 is the source - so I know that the data rate is not unreasonable) 3) This little section works perfectly 99% of the time with no Red highlighting - yet 1% of the time "feedback" is detected. the conditions and timing of all inputs are identical in both cases. 4) In the new system, Red links still allow a limited number of triggers through. My schematic cannot tolerate this limiting - it is part of a counting and sequential logic system - every single trigger has a particular meaning, and must generate an outcome. Even one dropped trigger messes up the entire system.

I realise that with some tinkering, the schematic is probably fixable - but the point I'm trying to make is that the method of detecting feedback has been changed, and we don't know how. We really could do with more detail about how it works - because I have dozens of places all over my schematic where the meaning of the Red links is not clear - maybe they are highlighting something important that I ought to change, but I know that whatever is causing them, it is not infinite feedback loops.

DigitalWhiteByte · 2 Apr 2011

mmm... Rather than a feedback, this seems to trigger a limit, but how many, it is calculated on the id, for primitive? Would better define youself which is the limits?

sunsynth · 2 Apr 2011

I had these and even more strange loop thingies showing up in v2.02... Also there where 100% no real loops and i think no trigger limit 2...

Oops - Loaded a simple Osm with MidiYoke IO on the same channel - cool steady loop hanger - tried to make a screeny but CPU was totally overloaded...

P.S.: Just tried 2 cancel loading a big OSM w/o Loop on Prog start with [ESC] - crash 😝

trogluddite · 2 Apr 2011

...and mvwdlee also reported problems with the feedback detector crashing.

I'm going to gather a few more bits of 'evidence' from my schematic and get back in touch with Malc. I already asked if he could explain more the new trigger system (maybe in the manual) - but he wasn't keen. He said that the new system will be so easy to use that we would not need an explanation. Maybe that is true when making a whole new design, but I think we need help to get our old schematics working properly again.

DigitalWhiteByte wrote: Would better define youself which is the limits?

Yes, I think that would be good - I think the new system must be too 'sensitive'. I made the example from the manual (adder and trig.blocker), and it allowed only 4 triggers before cutting off. Also, I did some more testing of the schematic I showed earlier - I made the part with the float switch. See how all 3 inputs come from one source, that arrangement definitely does not make any duplicate triggers - one trig in -> one trig out. So it seems the Red links might be sensitive to triggers even with different IDs (or maybe the ID thing has also changed?)

stw · 3 Apr 2011

The whole new behaviour of trigger flow looks strange to me. It's like you say, if a schematic is done from scratch it could be fine but if an older one is used there's some trouble around. My actual osm was totally screwed after opening it first with 2.03. Many parts were broken because even in a very primitive trigger flow some triggers were blocked and values couldn'tpass through. Workarounds like sample and hold prims or dethreader helped though there was still no obvious reason why it stopped working at all. I got red "loops" too which definitely caused no internal feedback like the pictures example. But most remarkable is after enabling and disableing the new trigger system a few times that behaviour changed. The broken trigger flows suddenly started working again no matter which trigger mode was selected. SInce then i couldn't reproduce the state after opening my osm first time. Even the red loops disappeared. Other infinite loops appeared but this time they could be correct (they didn't cause a red loop in former versions) depending on the function and trigger routing of some primitives. So all in all some oddities which i can't reproduce nor find a convincing explanation.

trogluddite · 3 Apr 2011

stw wrote: oddities which i can't reproduce

That's especially where I'm struggling. Even with no changes to my schematic, the isolated Red links will appear in a different place each time I load and restart. Sometimes the Red links will not appear until if have had the schematic running for 20mins - other times, it is almost immediately after loading. When I emailed to Malc, I did point out to him that I was unable to be more specific about the conditions that create the problem - the problems just don't correlate at all with the way I'm interacting with the schematic (e.g. Red links will sometimes appear in a part of the schematic which is only 'idling', yet not in a part where I am wiggling a control like mad).

DigitalWhiteByte · 4 Apr 2011

This is another oddity, trying to change the boolean, nothing happens, the Trigs are right, in my opinion.

aliasant · 4 Apr 2011

DigitalWhiteByte wrote: This is another oddity, trying to change the boolean, nothing happens, the Trigs are right, in my opinion.

Nice example. yes. that should work.

Have you tried any "fixes" likes inserting a De-Threader somewere or any other way to make the same scenario work? Seeing what can make it work is a nice clue perhaps but Malc needs that one.

I have been lucky I think. The first days after the new update I had several really weird issues like the ones you have been talking and I emediatly sent schematics to Malc. He did fix them and I know how little time he has so Im very grateful that he did. I also suggested that he really could benefit from writing a guide about this new trigger system and especially a guide on how to make our old schmatics work with the new system. That would have saved him from a number of bugreports.

That part in the manual about loops was helpful but quite hard chapter to find. With a big change in the softwares behaviour like this one I think most of us would expect a decent walkthrough of the cans and carrots? Any help to make the transition gentler to the greys...

One thing I noticed is that previously, when I added several triggers into one trigger I never got more triggers from the sum then from the one trigger with the max N triggers. Now they seem to add. If I have 2 signals added with an Add Primitive both triggers will come thru and that happens a lot so triggers in the end can be crazy high. That needs some new attention. Several times I have had triggers like 1000+/second going into a redraw and slowing down everything to almost a complete stop.

Maybe thats good news for those that still seeks the unholy graal; The Super Ticker 🙂

trogluddite · 4 Apr 2011

DigitalWhiteByte wrote: trying to change the boolean, nothing happens,

That is an odd one - no feedback detection too - adding another S&H into the loop makes it see the feedback (but still can't change the bool), and it works fine with the new trigger system disabled. May be worth posting that one to Malc - he emailed me back with some details of the new trigger system, and your little schematic happens to include both of the main changes. I'll try to give a quick summary here of Malc's mail (pretty much verbatim because I'm not entirely sure that I have fully understood all of it)

1) There used to be problems where maths modules/comparisons were a bit flaky in situations where the same trigger caused both inputs to change at once - sometimes only one input would see the change. To combat this, primitives which sample a value when triggered now create a new ID for the triggers at their output. Mostly that will be the obvious S&H and Switch prim's, but there are a few others that work in a similar way.

2) Creating new IDs at S&H's etc. breaks the old version of feedback detection, because the trigger ID in the loop might be constantly changing. The new system works by looking at both outgoing (L to R) and incoming (R to L) triggers. When a value changes in a prim it sends a trigger out - NB, not a value, just a trigger. When downstream modules receive the outgoing trigger, they send one back the other way to request the value (I assume that the ID of this one would never be changed by any prim's). The new feedback detection looks to see how many times the outgoing and "data request" triggers cross paths - if they're in a loop, then they should be going round and round in opposite directions. If they cross each other more than twice, it "blows the fuse".

In theory, the new system seems sound enough, but Malc thinks he might have spotted a potential problem in rare cirumstances where triggers originating from different threads collide. I am pretty clueless when it comes to understanding multi-threading, but Malc says to look out for schematics that use the 'Trigger Thread' and MIDI/Note Event primitives. Malc is looking at one of my problem schematics at the moment - but it's quite a big one - so if anyone can replicate the anomalous "Red link" behaviour in a very simple schematic, I'm sure he'd be interested to hear from you.

trogluddite · 4 Apr 2011

Latest news... Seems that the problems I'm having (and this will almost certainly affect other SM2.03 upgraders) stem from the MIDI system. If you are running SM2.03 - try this little schematic...

...just a stock knob, really - boring eh? Wiggle the knob loads with your mouse - nothing happens except some boring numbers get displayed.

Now try controlling the knob with MIDI CC messages (I've set it to use mod.wheel CC#01) - I get a blast of 'fake' feedback detection, sometimes even going on and off a few times before settling on a definite feedback condition. If you start chaining other modules after the knob, they will also often start detecting feedback - but only if the knob is driven by MIDI. Enabling/disabling the new trigger system makes no difference, the 'feedback' detection is independent of that setting.

I've passed this on to Malc, and he is busy working on a diagnosis and treatment.

DigitalWhiteByte · 4 Apr 2011

Adding a "Primitive NOT" now seems to work, even if the expected result would be the opposite of the boolean changed.

trogluddite · 4 Apr 2011

Something very screwy with the trigger flow there! I tried your first example, but with floats and integers. As you type a value in, it gets constantly overwritten with zero. When you press enter, or click outside the box, the value you typed magically re-appears - but the final output remains unchanged. It also still doesn't see the feedback loop, even though it is obvious to see.

MichaelBenjamin · 4 Apr 2011

silly question: the things you are demonstrating here, are they with the new trigger system strg+alt+t checkbox option turned on?

DigitalWhiteByte · 4 Apr 2011

MichaelBenjamin wrote: silly question: the things you are demonstrating here, are they with the new trigger system strg+alt+t checkbox option turned on?

between enabled and disabled, there is a response reversed.

trogluddite · 5 Apr 2011

Malc says fixes are on their way very soon - he's already identified the sources of the problems (the triggers and feedback ones), and they can be mended without any major re-writes.

DigitalWhiteByte · 5 Apr 2011

Are always welcome good news 😀

nix · 7 Apr 2011

That's great trog, I haven't upped anything, but yeah, am getting lots of dotted links with the new system. Cheers Malc!