Counter Reset ( Red trigger loop question )

trogluddite · 16 Dec 2011

I tried your setup in SM2.0.5, with the new trigger system turned on, and the only way that I could make feedback show was if the comparison was always true (i.e.Rec Limit <= 0). I also see that the red loop is illogical - i.e. why are neither of the links between 'greater/equal' and 'trigger switch' highlighted? So the only possibilities I can think of are... - You have an older version of SM, or maybe an old version of a primitive that has been updated - the feedback system had a few bugs when it was first released that gave these illogical red loops. - The value of Rec Limit has been zero at some point (when typing in a new value etc.) - it takes a while for the red loops to clear after you remove the cause of the feedback.

lesobrod · 16 Dec 2011

Wow! I like such a "devil's trill" examples. Well SM 2.0.5. after pressing trig butt shows red lines.

In some my examples reds appeared right after some ports was just connected. Let's think about it some time..

lesobrod · 16 Dec 2011

Yeeaah.

trogluddite wrote: it takes a while for the red loops to clear after you remove the cause of the feedback.

Trog is right, as always )) Now he seldom appears at forum ((( Please look at this (in both schms trig butt was pressed):

I use "Trigger Delay" often enough, it helps to avoid many weird enigmas. It makes me think about some deep questions about human brain and process of making decision.. 😈

trogluddite · 16 Dec 2011

lesobrod wrote: In some my examples reds appeared right after some ports was just connected.

Yes, making links normally creates triggers. In fact, if you look using the trigger counter, making a link seems to always send two triggers - I don't know why two, maybe a trigger from the device at each end of the link?

lesobrod wrote: Now he seldom appears at forum

He he, I am always lurking around, just a little too busy at the moment to contribute much.

lesobrod wrote: I use "Trigger Delay" often enough, it helps to avoid many weird enigmas

Must take care with these though, they have their own special 'enigma' - if the start originates from MIDI or VST Host automation, the delay will not see the trigger. (because of different CPU threads - use a de-threader component to fix this).

lesobrod · 16 Dec 2011

trogluddite wrote: Must take care with these though, they have their own special 'enigma' - if the start originates from MIDI or VST Host automation, the delay will not see the trigger. (because of different CPU threads - use a de-threader component to fix this).

Aha. See it, thanx. But what about attic' quest? Maybe here delay will be useful? (o_O)

trogluddite · 17 Dec 2011

lesobrod wrote: Aha. See it, thanx. But what about attic' quest? Maybe here delay will be useful? (o_O)

It really shouldn't be needed - so long as resetting the counter always makes the comparison go false, there is no reason that there should be any feedback.

If the CPU were loaded very heavily, a trigger delay could also make the schematic a bit unreliable. The timer inside the delay is on a very low priority thread - and as CPU load rises, the delay time will (on average) get longer and longer. This can lead to situations where sequential events end up happening in the wrong order. In the worst case, the timer will receive another trigger before the time has elapsed, causing it to reset to zero without sending an 'end' trigger output - you can 'stall' a timer indefinitely if you keep sending it fast enough triggers.

In a case like this one (driven by a slow ticker), that is very unlikely to happen - but I would suggest that good programming practice would be to always avoid timers if possible.

Note as well, that using a 'de-threader' to ensure timer triggering from MIDI will compound the problem, as the 'de-threader' has a ticker insider (yet another Windows timer). This can lead to annoying time lags and jitter for MIDI triggered events.

attic · 17 Dec 2011

Lesobrod & Trogluddite two of my favorite people and always to the rescue. 🙂 I was away for a day and had my latest show so I just got back to find these reply's. I managed somehow not to crash and burn during the performance using this very code but its easy to crash at least on my system. If you mess with the rate control cpu can go thru the roof.

I am using the latest version SM2.0.5 but there is stuff from an old schematic as I raided an old XY pad for components but what should I replace? I think Trogluddite maybe right on it being a midi trigger thing but I haven't used the dethreader before and Im not sure where to place it in the flow? The cpu can be pretty high on my project at times so that could also be a problem (more missed triggers the higher it go's). I don't want a trigger delay if at all possible.

I hope that I can keep the current accuracy of the knobs & sliders while crushing some of the buggy behavior and bring that cpu down. If you have any ideas on making this more cpu friendly please share even if it means gutting some stuff.

There are also the other oddity's of this schematic like why on my system does the rate control when 80 to 100 percent send the cpu thru the roof, and why the crash when I try to remove the resample module in the record section (See below .jpg below). Its a bit of a mess in there as I have been trying many things but maybe the two of you would be willing too look at the .osm?

Thanks Attic.

lesobrod · 18 Dec 2011

Thanx for good words, attic, truly! (^_^) And I'm glad to find my Dr Jekyll as Trog 😈 But what about your osm....OMG.. It's a really complicated!! Well I sometimes 'away by' module programming and make 7-8 levels of modules (like a russian doll Matroshka)))) Maybe it's not good, but please if you can - add at least 2 levels and 4-5 modules just for to make schms more readable and clear. Anyway I'll try to find what is the problem.

attic · 19 Dec 2011

It's a really complicated!

I'm really sorry that its not cleaner in the module. I just bashed the thing together barely in enough time for a live performance and needed some time to practice with it so I never got a chance to clean house or document anything. I just performed with it the other day and it worked so now I will make it more stable clean it up and hopefully crush the bugs ... but huge apologies for the mess it is right now. 🙂

trogluddite · 19 Dec 2011

attic wrote: I just bashed the thing together barely in enough time for a live performance

Like your style! 🙂 Living by the seat of your pants.

Only had a quick look so far, and it is rather confusing in there, but here are my thoughts...

DeThreader - as far as I know, only timers are affected by the MIDI thread bug, and SM2.0.5 has fixed the feedback bug with MIDI signals. Still, there's always the chance that other rare setups have the same problem. The de-threader can go anywhere directly in the path between the MIDI input and the primitives that need triggering When a trigger gets 'de-threaded', it becomes a whole new trigger with a different identity, and will stay 'de-threaded' no matter how many links it travels through on its way. So it makes sense to put it as close the the MIDI source as possible, so that it is shared by all the possible destinations. You may also need to de-thread the integer values coming out of a MIDI splitter, which can be done like this...

High CPU etc. - This is undoubtedly caused by the volume of triggers. I've only tested so far on my little Atom netbook, and that maxes out a CPU core at about 30% rate. The sudden 'shooting up' is probably caused by triggers being generated faster than they can be processed - I guess there must be a buffer somewhere that stores 'pending' triggers, and the queue of triggers is too long. A quick look with a trigger counter doesn't show masses of triggers in any one place. I think the problem lies more in the 'flurries' of triggers that result from signals going to many places at once, and generating yet more calculations when they request parameter values. I'd suggest having another browse of my trigger tutorial - especially the section about how 'reverse triggers' behave - this explains how many 'invisible' triggers are created when you think there is only one. Judicious use of trigger blockers and sample and hold should make some useful reductions in CPU use. This applies specially to GUI ReDraws - a trigger counter shows that many of the ReDraws are happening very fast, and that reallly sucks CPU.

Crash on Module Delete - Confirmed the crash - instant lockup when I pressed delete. Can't see anything in there that should cause this. I did have the same problem once, but it was caused by an assembly module. Regular SM primitives are supposed to be utterly stable, even if connected in silly ways, so I would send OutSim a bug report.

PS) New version of Loopa will be posted this week - has very CPU-lite 'motion control' recording for many of its controls. I will try and post up just the automation part as a separate module - don't think it is quite the same function as yours, but maybe some bits would be useful.

attic · 20 Dec 2011

Yes living by the seat of my pants. 😉 It actually scares the hell out of me to go in untested but I wanted this sound I was hearing so I did it anyway. Here is the song it was used in. http://www.box.com/s/qgobcfveexa174617xbk You maybe surprised to know that those knobs are on a modified version of your SK1. I liked the sound of your grain section in the SK1 when its down at the millisecond level but wanted to wobble it a little as that's what the kids want to hear right now. I added some pitch shifting from oddson not that your's isn't great but I was looking to keep the wobbles synced on key change. The kids would probably laugh if they knew I was going home after the show to listen to some smooth jazz. I'm going to put a remixed version of your SK1 up on the SK1 thread here at the forum as soon as I can get the cpu down and other bugs I introduced fixed.

I pulled out version 1.3 Beta 01 of Soopa Loopa to take a look at what you have in there, the code in your knob under the Loop and Ramp module is daunting. It will take me some time to understand what I am looking at. I have been trying not to use the Mono to Float because I haven't thought of how to get it to remember its last settings yet. (IE when I shut down the audio stream all of the motion data is gone.) I will try the DeThreader and see if it helps with the bad loop and yes I need to reread your entire triggers tutorial.

Judicious use of trigger blockers and sample and hold should make some useful reductions in CPU use.

This is probably the first thing I need to do. My machine is pretty fast so hearing that it maxes out at 30% isn't good I max somewhere between 85% & 90% depending on whats happening. Anyhow thanks for the SK1 example it has been invaluable in my learning process and points me in the direction I will take with SM.

attic · 22 Dec 2011

Trogluddite how much cpu do your motion control knobs use? After messing about trying to get the cpu down it seems maybe the high cpu is just down to far to many redraws.

I haven't ran into the the red loop problem again, I have a feeling I will see it again but that's making it hard to test or fix. It turns out if I disconnect the Tick25 I am able to delete the section that was crashing on attempted delete.

trogluddite · 22 Dec 2011

Hi, I meant to reply to your other post earlier, but got distracted by moderator duties (***<many expletives>*** spammers!).

Hard to say how much CPU my auto knobs use in isolation as I've only ever tested them within Soopa Loopa. On my Q6700 CPU machine, the load is generally below 10% (Task Manager reading) - that's for the .exe version with eight loops, each of which has a dozen or more automation-capable knobs.

Some of the things which I think contribute to the low CPU are...

1) Generously hopped code for the main routine. I think that in some cases like this, hopped code can be more efficient than green. I don't see the point of having automation built in to a plugin unless you're actually going to use it, so the fact that the code is always running doesn't bother me. Some sections of code are also completely bypassed when not in use (e.g. record section shuts down when only playback is needed). On the samples where the code does run, only the actual intended algorithm is being processed (i.e. efficient code/assembly), whereas doing the same with green must involve a lot of CPU for tracking the progress of all those triggers. i also exploit mono4 throughout the code, so that I can run four controls from one code block. I suppose you could say that using code gives the developer control over the CPU usage - there are no hidden overheads to catch you out.

2) ReDraw efficiency. Quite simply things only get ReDrawn if absolutely necessary. There is a master 'frame rate' clock setting the maximum speed that things can be updated. Extra events, in between clocks, are not redraw at all. If a parameter has changed, I also check that the change is big enough to cause a noticeable movement on screen (i.e. a new animation frame) The animated controls are deliberately placed very close together and share a single redraw. A small module calculates the smallest area that will cover any/all knobs that have moved, and a single redraw trigger does the whole lot in one go. For these reasons, I also compromised a bit on graphics quality - most controls are only 40px square, and only have 31 animation frames - which also meant using simple, bold knob designs rather than 'photo-realistic' ones.

Great to hear one of your tunes; despite my advancing years, i still have moments where I like to listen to stuff like that very LOUD, and waggle my beer belly in time to it! That's a pretty mean live set, you really manage to keep the music pushing on with the unexpected chops and changes - there's some lovely interplay between 'soft' and 'angular' sounds too. I'm still at the stage with Loopa where I can spend 5 minutes just staring at it wondering what the hell to do next, so it's inspiring to hear something in a similar vein that keeps my interest from start to finish. By the sound of it, my old SK sampler project is in good hands - it's something I'd like to return to when I have more time, but already you have picked up the baton and taken it into areas that I had never thought of. Your idea of modulating the grain size is inspired - it tempts me to add automation to Loopa's grain size control, but I know what I'm like for adding bugs when I put new features in, so I'll get the current one posted first! I'm looking forward to your 'Mutant SK' post. 😉

Interesting the delete crash thing. I can only guess that SM doesn't like arrays being moved/deleted while there are triggers still to process - maybe the primitives try to access memory that has been released by SM when the arrays are erased?

attic · 3 Jan 2012

Oh no they have you on spam control, just a horrible waste of your talents. 😉

the code does run, only the actual intended algorithm is being processed (i.e. efficient code/assembly), whereas doing the same with green must involve a lot of CPU for tracking the progress of all those triggers.

This I am becoming all to aware of now, doing this in green is probably not the right choice. I have managed to hack most of it together now with fairly good results but the cpu is still very high. It will work for the shows but It would be nice to tame that cpu usage. Right now you can really only run one copy at a time. I used the master 'frame rate idea and that helped a lot (IE Heartbeat) thanks for that. I appreciate the comments on the music, its always nice to hear what others think. The idea of modulating the grain size just wouldn't have been possible without your windowing function, I look forward to the time when you can shift some of your efforts from the Soopa Loopa project as I have a feeling you've got some other insane vst ideas just screaming to see the light of day. I will be posting the Mutant SK project here soon for better or worse, but if I cant tame that cpu it may be mostly useful for frying eggs on your processor.

it tempts me to add automation to Loopa's grain size control

Oh yes do that! I don't think I have seen a looper with grain size automation. +1

sunsynth · 4 Jan 2012

@trog:

2) ReDraw efficiency. Quite simply things only get ReDrawn if absolutely necessary. There is a master 'frame rate' clock setting the maximum speed that things can be updated. Extra events, in between clocks, are not redraw at all. If a parameter has changed, I also check that the change is big enough to cause a noticeable movement on screen (i.e. a new animation frame) The animated controls are deliberately placed very close together and share a single redraw. A small module calculates the smallest area that will cover any/all knobs that have moved, and a single redraw trigger does the whole lot in one go.

Very tricky -indeed (already found it) 😍