Global Reset Events in Reaktor

This tutorial explains what Global Reset Events are, what causes them, and how to avoid some of the most common bugs associated with them.

GLOBAL RESET EVENTS

A Global Reset Event (GRE) is an initialization process in Reaktor. Due to the fact that event programming in Reaktor is esoteric and often poorly understood, GREs have a tendency to cause frustrating bugs that are difficult to track down and eliminate.

Several things can cause a GRE to trigger in a Reaktor Ensemble: opening the ensemble, changing the position of a Switch, editing the structure, changing the input of a Receive module, and so forth.

If you experience an ensemble that changes it’s behavior after a Switch is changed, you are experiencing a problem with a GRE! A very common problem of this sort affects Sine Banks, Multi Displays, and other modules that require specific event ordering. We’ll get into the details of that below.

HOW GLOBAL RESETS WORK

GREs cause many modules to re-initialize, which in turn creates unpleasant audio glitches. For this reason, any panel element that causes a GRE (such as a Switch or a Receive module) should not be intended for use while audio is playing.

If this advice is followed, the problems associated with GREs are limited to the re-initialization of modules that output events. Since many builders are unaware that GREs even exist, it is likely that a large percentage of bugs in Reaktor are caused by this behavior.

Consider the following structures:

You might be tempted to believe that these two structures will function identically. In normal circumstances this is true – In both structures, an event at the input will not cause an event at the output if the button is off; it is also true that both structures will output a value equal to the input + 1 if the button is on.

Then what is the difference? Well, the difference is that the top structure will output a value during a GRE regardless of whether the button is on or off, and the bottom structure will retain it’s standard function, only outputting a value if the button is on.

What causes the top structure to output an event on a GRE? The Constant module with a value of 1 is our culprit! All Constant modules will output events in response to a GRE. In the case of the top structure, this triggers the Add module and sends an event to the output of the macro. In my experience, innocuous errors like these are the most common problems with GREs.

Generally speaking, the behavior of the bottom structure is superior to that of the top structure. The reason I say this is that you usually want to build structures that respond the same way to an initialization as they would to any normal event. This is not always the case, but as a general rule it is how I try to program.

Unfortunately, the behavior of modules in response to a GRE is not mentioned in the Reaktor Manuals to my knowledge. We do, however, have tools that can help us better understand what happens during a GRE. My favorite tool for tracking down initialization bugs is CList’s EventWatcher, which can be downloaded here.

Using the EventWatcher to check what happens during a GRE is easy. Here’s an example:

As I mentioned above, flipping a Switch module will trigger a GRE – even if that switch is attached to nothing and affects no other component of the structure. So you simply attach the structure you want to check to the input of the EventWatcher, and flip the Switch on or off. On the panel view, the EventWatcher will record each event that arrives at it’s inputs, so you can check there to see what happens. If you duplicate the structure above, Eventwatcher should not record any events on a GRE. If you replace it with the first structure I posted, you will see a new event arrive with every GRE.

Make sure to send only mono signals to the EventWatcher! Forgetting to do this has caused me a headache more than once. As a further word of advice, only use one input of EventWatcher at a time for this purpose – during a GRE, EventWatcher has a tendency to misreport which input the events arrived at if more than one is connected (I suspect this is due to some special behavior of the Merge module which I’ll get into below).

RESPONSE TO A GRE

Using the EventWatcher, I tested the outputs of every module in Reaktor that contains an event output to see which ones trigger automatically on a GRE, and which ones do not. I made a quick chart to contain all of this information:

It can be presumed that any module in the left column will always output events in response to a GRE. The middle column, mostly composed of ‘hybrid’ modules (that can accept and output either events or audio depending on the wiring), will only output an event in response to an event at the input (remember that this can be something as simple and innocuous as a constant value). Finally, the right hand column never outputs events during a GRE, as far as I can tell.

AVOIDING ERRORS WITH MERGE AND ORDER MODULES

There are (at least) two modules that have special behavior during a GRE – the Merge module and the Order module. These modules behave differently to an event during a GRE than they would to any other event. Needless to say, this can create problems.

The Merge module will only output a single event during a GRE – even if the module itself receives a dozen events, only the bottom event will be passed to the output.

The Order module only outputs an event to the ‘1’ output during a GRE – the other outputs do not fire until the initialization process is complete.

The most prominent way that errors are caused with these modules is when they are used together. I was surprised to find such an initialization error in the Reaktor Manual itself recently. Section 12.2, starting on page 338 of the Application Reference, there is a quick tutorial on using the Sine Bank module to create a simple synth with 5 partials.

Each partial has a knob that controls the amplitude of that partial. Together, the macro that controls the partial amplitudes looks like this (picture is from the Reaktor Manual):

What is wrong with this structure? Well, during a GRE, all of the knobs will fire an event, and go through an Order module. The ‘1’ outputs all get merged together, however, since the Merge responds in a special way to a GRE, only the bottom input is actually passed through the module. So the Idx value gets set to 5.

After the GRE is finished, the ‘2’ and ‘3’ outputs of the Order modules fire. The problem is, they all write their information to control partial number 5, since that is what Idx is set to. So on a GRE, or upon opening the ensemble, none of the information gets written to the Sine Bank module properly.

As a result of all of this, the example does not work. When you load the project, you must first turn each knob individually for it to work properly. Not exactly a user-friendly interface. I should mention that the authors were aware of this and mention the problem in the text (they presumably did not want to go a several page tangent in the middle of an unrelated tutorial). I am simply using it as an example of initialization errors.

In my first tutorial on Additive Synthesis, I show how to avoid this problem by only using the ‘2’ and ‘3’ outputs of the Order modules. In this case, the Order modules wait until the end of the initialization routine to fire an event out of the ‘2’ output. Since the Merge module is no longer acting strangely due to the GRE, it outputs all five of the events it receives instead of just  the one.

Because of errors like these, the modules most likely to cause you problems in conjunction with Order/Merge modules are modules that have Idx inputs and require events to be sent in a very specific manner. In particular, Multi Displays, Sine Banks and Modal Banks can be very difficult to work with.

For more on the subject of Order and Merge modules, you can check the Application Reference, starting on page 245.

CONCLUSION

The fact of the matter is, GREs are very complex and require a great deal of understanding of the Reaktor environment. Although I have outlined a few common pitfalls in this tutorial, the subject is vast and poorly understood.

I would like to write another tutorial or two on this subject, delving deeper into specific GRE problems and solutions. To do this, I need your help! Please send me examples of any GRE problems you may be having, and I’ll be happy to take a look at them and try to fix any bugs. Of course, the simpler the ensemble, the more likely I will be able to do this. Please send me any problems at salamanderanagram at gmail dot com.

I hope to hear from some of you and get deeper into the problems with Global Reset Events. Please let me know in the comments if anything was unclear and I will do my best to explain better. Thanks for reading!