Event loop in module

OK, so im new to reaktor. I have loaded up Carbon 2 and straight away when i load up preset 1, and trigger a note from my MIDI keyboard, i am getting Waring - Event loop occurred in module. Why is this happening. Its annoying as it is in the "factory" made ensemble

 

Found it

I had Globally disable event loops on. doh!

 

easily done ;-)

sowari

 

just so you know for later, globablly disabling event loops is really just for either debugging your own creations (or others while dissasembling), or in case you accidentally saved an ensemble that starts a fatal stack overflow crash from an eventloop on initialization only, this wont occur when saving but WILL occur when starting up. so, you turn globabally disable event loops on, and next time you open the ensemble it wont crash, but will instead break the loop and give a message, so you can fix the ensemble.

event loops are very useful in alot of complex event programming, just like "proper" programming, and thus alot of the expert builders (including all factory lib builders) use them.

just thought you might want to know why that option exists.

 

hmmh sorry don't aggree.
You are right to say event loops are usefull but it is not usefull to use them by switching "Globally disable event loops ON".
Allways i start a project i switch it OFF. If i need an event loop i try to solve it by using z^-1 (in CORE) or unitdelay (in primary level) or to find another solution. It is necessary to understand this.
But it is usefull to switch sometimes event loop ON when finding the reason of error messages. My opinon is that the final version of an ensemble should run with "Globally disable event loops OFF".

ciao herw

 

i knew id get in trouble with you saying that, herw! i totally respect your opinion, but this will always be something that i will disagree on (its a matter of opinion and taste). for me, i have been under the assumption that the global loop disabling in really just a debugging tool. the reason i give advice to the effect of only disabling loops at the ensemble level:

-1: many user lib ensembles use event loops, as i think alot of programmers find it more natural to work with loops than unit delays (especially if you want all events in the same audio sample). also, some factory ensembles use loops (like carbon 2)

- and -

-2: for my own creations, anytime i use a counter, accumulator or flipflop, i ALWAYS use custom versions i made that save their state using snapvalue modules. counters and accumulators always reset to 0 on global resets, including snapshot changes, and for me this is almost always undesirable. and, i cant think of any way to save a counter's state and restore it via a snapvalue WITHOUT an event loop, although it may be possible.

i dont know, to me it just seems easier to use a loop alot of the times rather than some other method, especially if the loop is safe.

OTOH, i feel the one main reason to AVOID loops nowadays, is because corecells dont work inside of them (so, core-heavy builders must learn to avoid them). this drives me crazy, mainly because of point 2 i made above, and i usually end up remaking in primary some event structure that can be made in 2 seconds via a core facory macro (like a threshold detector or impulse generator).

 

I'am the same.... if event loops were that bad why is there an option to have them?

 

no problem ;-)
i know i am a shouter in the desert. There are many conficts in some simple parts of ensembles only because the author is not willing to think about an assured solution - means: where and why is an event loop needed and how can i controll it, f.i. restoring values of multiple pictures, mouse areas, default values of knobs (setting from panel !), loops with send-receive etc..
Event loops are something what i want to steer by myself not from a simple GLOBALLY-DISABLE-EVENT LOOPS- OFF/ON - Button.
... cetero censeo ...

ciao herw

 

to add to this thread,

my reaktor 5 ensemble uses no sync, it's just a bunch of resynthesizers, a few LFOs and EFOLs, a mixer, a couple of audio recorders and a sample player... all connected to osc terminals that communicate with my buddies with other computers who have sensors like video cameras and such (cool!), so i get the osc messages and turn them into controls on the knobs of the instruments...

now, the question:
in this context, given that i have no sync-oriented material to work with, would disabling event loops from every place in the patch help it perform better? how can i get a stack overflow of events?

btw i'm hooking this machine up standalone with ABLETON so ableton memorises the controller note changes in midi clips and then plas them back to reaktor later on.

second question: would event loops affect / prevent midi info overflows from happening? or to prevent midi info overflows simply avoid patching midi loops between applications?

thanks!

 

Sorry I disagree. The reason for that option has only to do with the way in which reaktor opens/plays files and nothing to do with event loops themselves being good vs. bad. If reaktor could open files in "edit mode" and then switch to "play mode" then that "Globally disable event loops OFF" option would not even exist!

Programmers in all languages use loops all the time it's just a natural thing to do in programming. To say you want to avoid them is to handicap yourself by taking "do while..." and "do...until" out of your "programming language".

The fact that reaktor can have "infinite loops" and crash makes it no different from other programming languages - which can also have infinite loops and crash programs if coded incorrectly.

When using the unit-delay to avoid event loops, you are preventing yourself from having everything happen in one tick of the sample clock - which may be very useful in some cases. You may also not know that you actually have an "infinite loop" when using a unit delay on the events - you are simply making it such that reaktor doesn't give you an error but instead runs up the CPU by converting from audio to event and back constantly for events that shouldn't be firing.

Again, Reaktor is unlike other programming environments in that it cannot even open a file with an infinite loop, so they needed to add that "disable event loop" option so that people could go in and fix their bugs. NI wasn't trying to tell us that event loops in general are a bad thing. Who knows, maybe in the future reaktor will have multiple modes of operation; "edit mode", "debug play mode", "performance mode", and an "export to VST" - and then they can get rid of the "globally disable event loops" button!

- CList

 

yes, i totally agree with CList here, the Globally Disable Loops is more of a debugging and Ensemble-saving feature than a way of working.

of course, the iterator can help in alot of places instead of a loop, although it is also a loop internally, anyways. i try to think of an iterator as a "for" loop, and an event loop with a seperator of router inside as either a "while" loop, or a recursive function.