R6 Initialization info

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.

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

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!