R6 Initialization info

Quietschboy

This is a shortened copy of the original thread in the old Reaktor Forum from 2016 before it´s getting deleted some day...

Since then, i did not recognice any changes in the initialization behaviour. So, these 6 year old statements including the pdf table seem to be up to date (R6.4.0) ;-)

This thread is about the initialization behaviour of Reaktor 6

Only want to add my personl declaration of initialization for the following statements:

• Initialization: or Full Inititialization happens when loading an Ensemble or turning Reaktor Audio Off and On.
• Re-Initialization: short: re-init, happens when making changes to the structure, turning switches, lists, receives, etc.

Ensemble Load is often followed by a re-init if switches etc. are set at load.

https://www.native-instruments.com/forum/threads/r6-initialization-info.268630/

First post, March 7, 2016:

Hi all,

here comes a pdf file with a table about the different initializations in Reaktor 6 and their behaviours.

The initializations has been very simplificated in Reaktor 6 and the table got very clean since R5.

So, look into it to get an overview of "what happens when".

If you have questions about that or feel something is wrong, please don´t hesitate...!

Cheers, Mark

-------------------------------------------------

UPDATE Nov. 2016:

Initialization R6.0.4 V3.pdf

- added R5 behaviour at re-init

- added behaviour of unconnected Order Module

Initialization R6.0.4 V3.pdf

Next post, March 9, 2016:

oh, opening an "Initialization Info" Thread i forgot to mention the following:

I use these expressions of "init" and "re-init". I saw them by a NI developer a longer time ago. So i decided to use them too.

Of course there are other expressions (also by other devs). I´m not sure if it exists an official expression. Never saw that mentioned somewhere. The documents only speak of "Initialization".

For the full initialization "init" you also find "hard reset", "hard init", "GR", "General Reset", "GSR"... in the forum posts.

For "re-init" also "soft reset", "soft init" and maybe more.

Getting back to the changes in R6, there is something that is not clearly apparent in my init-table:

Re-Init now always happens asynchronous.

Asynchronous means inbetween Sample Ticks. No Audio Port fires an audio event at re-init. This is also true for connected Core Cell Audio Inports, my table is missing. The SR.C Pickup in Core never fires at any Init in R6.

Not new, but it should be mentioned here, too:

It is not a bad idea to full initialize Reaktor after changing the number of voices (see the table...)! Just turn the Audio Engine off and on in the upper right corner of Reaktor. In contrast to the Sample Rate Change Init the Voice Change Init left some bad taste behind (R6.0.1)!

You should also always full initialize Reaktor when building and before testing.

Next post May 18, 2016:

So, there is another heavy weight change made in R6 CORE:

Re-Init events, which are simultaneous in Primary Level, appear NON-SIMULTANEOUS in R6 Core Cells!

And the best thing is: They get simultaneous again after leaving the Core Cell!

The order of re-initial events at the Core Cell´s inports is from top to bottom.

I would like to say: *****?

Instead i suspect this behaviour is necessary to the new R6 Core Cell design in some way.

So, what´s the problem?

There are two problems:

First, the re-init event is only catchable/blockable with some headstands.

Second, there are now three states you have to notice in Core. This mostly should be less important when building pure audio structures with some parameter inputs. But when the Core Cell and the previous Primary structures contain logic event processing, the order of events gets more important.

In R6 you have these three states in Core:

1.) Init: every inport fires simultaneously

2.) normal events: every inport fires when an event arrives

3.) Re-Init: the Inports fire from top to bottom

edit: to be clearly, only inports which get events from Primary fire at init or re-init

edit of edit: ...meant for connected Inports. Non-connected Core Cell Inports always fire at Init. They do not fire at re-init.

The new Re-Init behaviour could be a problem when filling/triggering latches or other OBC Memories in Core!

The order could be messed up!

arachnaut

Thank you for your years of investigation into this part of Reaktor.

Quietschboy

Thank you Jim for your kind words!

I just can add to all other builders and beginners, that initialization is unfortunately one main part you should imprint into your minds. I made all these investigations to understand Reaktor myself, and in the end to build the ACEW Debug Tool and more.

Everybody who builds in Reaktor comes to a point (earlier or later) when unexpected things happen. Often this is due to some initialization pecularities. So, really knowing initialization while building helps a lot to reduce the debug time later on. This includes the time to learn the initialization behaviour when a particular bug in your ens appears.

Of course, learning the table i posted above by heart isn´t the solution at first. Furthermore it needs individual experiences. Build and learn!

Nevertheless, i just can put on your heart to use the table released above and the ACEW Tool to learn and understand Reaktor and it´s initialization algorythm. ACEW 4.1 is rock solid til now (R6.4.3). The only thing is, since ever, not to believe in the showed order when primary events are compared. ACEW can and mostly does change the order when plugged into Primary Structures. This is due to the Reaktor module sorting at initialization itself.

ACEW is free and to you by love. USE IT and READ THE MANUAL! See my link below.

Infrabass

Very interesting!

I'm now facing exactly this kind of issue.

So how can we avoid initialization events?

What are the classic strategies?

In my situation, those 2 buttons (index 1 and index 2) are triggering an event at each init and re-init which changes the index knob value (because those IC send are controlling this knob).

Thank you very much for your help dear builders!

Infrabass

I have the feeling this macro is designed to catch specific initialization events, am I wrong?

I'm not sure to understand what it does though…

colB

https://community.native-instruments.com/discussion/comment/85595#Comment_85595

Can't really help without context. What are the buttons for? and how are their parameters configured?

Quietschboy

https://community.native-instruments.com/discussion/comment/85595#Comment_85595

This is an macro to block init and re-init events:

The idea is to use the simultaneity at init and re-init.

The init event on the input (that one you want to block) enters the merge module simultaneously to that value from the constant module below.

In that case, the value on the lowest merger inport will be forwarded (here a most small number like -1E+38) to the separator module. That means the value from the input event is discarded and replaced.

To now get rid of that init event from the constant module, the separator´s threshold value is set by the same constant - simultaneously, as we are in the simultaneous init step. In consequence, the event ends in the separator´s Lo Output, because it is equal Threshold.

All following events should be forwarded to the ouput as their value is assumed to be greater than threshold.

Btw., the other macro named [/] you mentioned above is just an iteration macro. Input value [?] sets number of iterations (-1) and starts the iteration.

Quietschboy

For buttons with a triggering function, you can also use just a simple separator module, like this:

On init, the button sends the off value, which is 0 and gets stopped by the separator. The On value event (1) gets through and triggers any value.

I can just recommend not to use the Trigger mode, but the Gate mode for such buttons. With Trigger mode, at some circumstances, seemingly unpredicted things can happen (which are correct, though).

In the example above, the IC Send gets no init event. Maybe if you push and hold one of those buttons during a re-init?

Quietschboy

block re-init.zip

Here a macro that blocks only re-init events on Primary level (Init events are let through)

top and btm are connected to one Primary Constant Module.

On re-init, events in Primary are processed simultaneous but not in Core! Instead, the Core Cell Inports are processed from top to bottom. If you know that, it is relatively easy to understand the macro. But, to be honest, i myself don´t know today why i placed that event merger (it´s an additional (full-) Init bang) in front of the 1 value. It could be that it is needed for init caused by voice or clock change or something else.

Infrabass

Wow thanks so much for your help guys!

Bicycle week-end and work kept me busy these days but I'm gonna try asap!

I think all I was missing was the separator module in my case.

Also, I was using buttons in trigger mode but based on your tip, Quietschboy, I'm gonna switch to gate instead.