Best practices to prevent initialization bugs?

BLAIR

I hear initialization bugs can be weird and hard to track down, I also heard someone avoid using the first outlet of the order module to prevent it, does that work? And what are other ways you can prevent it in primary / core? Cheers

MvKeinen

Do you have any specific case?

User Quietschboy (m. wadewitz) has a great overview about init behaviour

https://community.native-instruments.com/discussion/5120/r6-initialization-info

Often it happens that a value isn't properly "updated" during init. eG if you have a counter counting values like so:

and outside of that counter we have this:

the output $ of the counter will be 15 on init.

if you want the counter to output a value only on "user input" either use a mod math module or put the latch behind the add.

Seems simple, but I guess around 80% of the init bugs come from that problem maybe more.

to track down initialisation bugs the ACEW from the same user Quietschboy is a great tool

https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/10125/

BLAIR

oh okay awesome thanks for linking the thread

Quietschboy

Hey Blair, there´s no best practice to prevent init bugs, but it´s a good practice to learn how initialization works in Reaktor.

Which main initializations do exist? What are their steps? How do each of them differ in Primary and Core? These are a lot of combinations and they are less intuitive, unfortunately. But this whole task is absolutely doable. My Table and the comments in the thread MvKeinen linked may help, ACEW may help. Play around and try this and that. With time, you´ll get into it.

The upper outport of the order module should be left free, if the downstream structure should NOT be updated at the simultaneous initialization step, but beeing shifted to post init, leaving it as a normal Reaktor event. Many Builders leave port 1 always free (maybe without knowing why exactly). In most cases it is OK to delay an init event to post init (using outport 2 to n), but sometimes..., sometimes it must be on init time (port 1). But yes, mostly it doesn´t hurt to shift it and it costs nothing. On the other hand: Port 1 can be used in most cases. So it depends on you.

It´s worth to learn the initialization in the first phase to avoid a lot of headaches later on.

Beside that, there is another awkward topic that can lit up, especially when using Multiplexing:

It is called "Thread safeness issue". This is about events shaked through GUI and Audio thread (these are different threads on your CPU), resulting in a changed event order... But this is another story. Max Zagler wrote a great PDF about that. It should be downloadable somewhere. Search for Partial Framework or Thread safeness.