Event Init Sinals

Hey Everyone,

I'm building a step sequencer with a somewhat complex user interface in Reaktor. I find I am constantly having to deal with event init signals. I understand how they work, but I mean like, it's frustrating. I am constantly having to over-complicate my structures just to block unwanted event init signals from triggering.

It seems like Reaktor is geared to more to building synths than sequencers, but has anyone else found some useful work arounds for these kinds of problems?

 

here is a general text on initialization events.

http://www.nireaktor.com/reaktor-tutorials/global-reset-events-in-reaktor/

i'll be happy to take a look at specific structures and try to improve their initialization behavior.

 

Great tutorial! Thanks for the help. I think I am close to sorting out all my init reset bugs, but if there is one which I can't figure out I'll post it up.

I feel like hot and cold inputs would really save me a lot of time in reaktor. Once I finish a structure I then have to add in a bunch of Router modules which are there solely to block init events. It seems unnecessarily over-complicated and makes my structures less clear if I share an ensemble with other users.

Another example: if I want to use a button, but I don't want it to send out its signal upon initialization, then I must use a Mouse Area over-top of the button with a Separator blocking the output below zero and then hook that up to something that can output a 1 and 0 toggle signal and then finally send the output to an IC Send to the button.

See the example ensemble attached...

Edit: The Separators are actually unnecessary because Mouse Area doesn't send a GEI.

 

don't overcomplicate things. if something seems unnecessary it probably is.

remember that constants will fire events at a GRE and at no other time. you can use this information to your advantage!

here's a method of stopping a button from firing within 50 milliseconds of a global reset event.

 

yea, totally true. thanks for posting that method, that's a better alternative for sure.

 

hello,
another way to block init events is using core. An advantage of core in this case is, that it also allows to distinguish between "Global System Reset" ("GSR" = EnsLoad, Power Button) and Switch- / Sample Rate Resets (i call them "SwR" in Short). This is possible, because memorys are not reset to 0 by a SwR. This maybe helps to save some power instead of using a Hold module in primary.

Here the examples:
The simple ES-Control filters out every init event (GSR + SwR)


GSR Filter


SwR Filter


Keep in mind, that those filters only filter events of step 2 of the initialization algorythm (source modules, constants,...). Step 3 to 6 (EventLoop In ports, Order out 2+3, Iteration, Snap Value Array iteration) can not be blocked by this fiters.

greets, mark

 

awesome, thank you. I will have to try these out, I haven't taken a look into core yet. That's cool that you can distinguish between the two types of resets. Because sometimes it's only the "GSR" that I need to block.

 

ok, i´ll add a short description of how the GSR Filter macro works:

in step 2 of the init algorythm EVERYTHING happens simultaneous. In the same "moment". But the OBC-connection in Core (read --> write) has a specific order from left to right or master to slave. Also at the moment of initialization.
At GSR, the constant "1" is written to the memory logically "after" the same memory is read. And because all memorys are set to 0 at GSR before the events are fired, the compare module gets a 0 = False = Router bottom out --> no GSR event.

Every event after GSR step 2 (includes GSR step 3-6! and all SwR init events) are routed to output, because the memory is bigger than 0...

 

excellent. thanks man!

 

Would it be possible to update those pics as full images in this thread, whenever I try to open a thumbnail in this forum I get.

NI User Forum - Error
This attachment cannot be shown at this time. Please try back later.

And also the image viewer script doesn't work for some reason.

Would actually be nice if this could be fixed, so much valuable info that's inaccessible due to this error.

 

my picture uses a constant to trigger a hold module.
the hold module controls the position of a router. so when a GRE occurs it stops any events from passing thru the router for 50 ms (or whatever time you set the hold module to last for).

as for the error, when NI updated the forum they broke all their links to everything uploaded to the forum. despite several threads i don't think they have ever addressed this issue.

 

I see, well that's a pity with the pics, thanks for the walkthrough! I wish I had your Reaktor insight man you blow me away all the time!

I was more interested in these pics by the the way, but your's too!

The simple ES-Control filters out every init event (GSR + SwR)

GSR Filter

SwR Filter

 

The upper posting was for REAKTOR 5 because the initialization algorithm changed in R6.
1st picture

2nd picture

3rd picture


In REAKTOR 6 you have to use instead of picture 1 a primary event blocker (a solution from Mark Wadewitz aka quietschboy):


GSR-Filter is now the same as picture 1 in R5 or the „no-init”-macro from REAKTOR library:


ciao herw

 

Oh I am R5 still so that's totally ok and thanks a lot

 

Hey Herwig, thanks alot pointing to this.
The picture shows a solution for R6 Primary to block Init (GSR) and Re-Init (Switch Reset, etc.) Events. Post-init events coming from iteration or the Order Module`s Outport 2 and 3 will not be blocked.
The constant at the mergers bottom inport should be set to a value which is lower that the lowest value at the event source inport (upper) when running the ensemble. So it would be saver to set it to the lowest possible float by standard. I think it is -1E+38, isn´t it? Not shure for now.

 

A while back I collected the various GRE / Initialization threads into a google doc for my own reference. Fortunately, it contains these various images that are now missing / broken on the forum. I haven't reviewed recently but it seems to be pertinent here (all R5 related). Using Core (and R6) has vastly improved initialization handling in my experience.

Anyhow, I've attached a PDF of these R5/Initialization threads - with images.

 

Thanks a ton all, specially for posting the PDF, interesting read!

 

I've been searching to try to find the cell or macro to block GREs for R6 in the user library but I haven't found it. Also checked other discussions on the topic. I know this thread is old, but anyone have the link or name of a macro or core cell that does this?

 

do you have trouble to get events into a core (-> order 2nd output) or do you want to block inits? (-> core cell with event sensitve routing)

 

I want to block inits.