Avoiding event loops

The key to avoiding most event loops seems to be to convert events to audio before sending information back into a previous section. That way it doesn't arrive as a triggering event but rather more like a value that is scooped out of the signal path.

I'm think especially about cases where for example, you need counters to loop (without simply using a math->modulo)

Of course this may not be the most efficient way to go, but I have been able to significantly reduce complexity and module counts using audio signals instead of event signals.

Then again processing power is rarely the limitation for me, usually I have to deal more with the "too many modules" or "too many connections" rubbish.

What strategies does everybody else use?

 

Do you mean avoiding the event-loop messages or the loops themselves (that crash an ensemble)?

If it's just the messages you want to avoid - sometimes there's no choice but to turn the warnings off (see the FAQ link below for more info).

Otherwise the most common situation is that you want enevts to flow back under some situations but not others, so you use an EventSeparator where one side of the separator feeds back and the other doesn't, so at some point the looping of the event stops.

There's loads of feedback loops in the counters in my latest user lib. upload (it's on the "newest 20 page). For things like the "looping" being on - the last event of the count goes back and resets everything to zero sot he counter starts again. The trick here is that only a count higher than the length of the sequence will go out the "hi" output of the sparator and feedback and cause the counter to go back below the threshold of the separator.

- CList

 

I use a merge module with a single input just before the event feedback on itself. I can't remember where I found this out, but it seems to work.

 

Most of my looping circuits now use an ORDER module with some VALUE modules after it to 'latch' the data through a loop. The ORDER 1 and ORDER 2 outputs send data into the loop and the ORDER 3 output causes the result to be latched into a VALUE module, whence downstream logic derives its values.

This aproach has the advantage that intermediate values (such as loop overflow for example) don't get passed through to downstream logic.

 

>Do you mean avoiding the event-loop messages or the loops themselves (that crash an ensemble)?

I'm trying to avoid disabling the warnings as much as possible, even if it takes a little more processing power. I'm sure they have saved me a lot of headaches by now.

Most of all I'm interested in other people's strategies. You know how you get used to doing things a certain way and a year down the line someone shows you the smallest trick that completely flips around the way you do things.

The ORDER module method sounds like it could be pretty solid for certain cases. I tend to rely a lot on ORDER-VALUE pairs myself.

 

The warnings don't work 100% correctly - no matter what you do. I and other users have come across plenty of cases where the warnings pop up for no good reason - cases where there's no possible way there could be a real ensemble crashing event loop. SOmetimes cases where there's no event loop what-so-ever!

It's not a good idea to try and get the ensemble to stop issuing the warnings at the cost of reducing the efficiency of your instrument - because the warning system is very over-sensative (you could say "buggy", but I'm trying to be nice). Just suck it up, accept that the warning system is not 100% accurate, and disable the warnings for your instrument. Per the FAQ, you may need to re-enable and then disable the warnings each time your structure changes to get the warnings to go away.

- CList