Anatomy of a Reaktor Project, Part IV

Welcome to the fourth installment of the Anatomy of a Reaktor Project series. For an overview of the project I am building in these tutorials, please check Part I, where I describe the basic idea, and what it will require from us as programmers.

In this tutorial, I’ll cover the special knobs I created for this project, which can hold up to 128 values at once, one for each ‘cell’ in the project.

MULTI-KNOBS

I chose to build these complex knobs to hold all of our values for several reasons. As I explained in Part I, the ‘simple’ way to implement our project would simply be to use a Stacked Macro to hold 128 identical macros, each containing every knob needed for that cell.

The problem with the ‘simple’ implementation is that it seems easy but ends up creating an endless stream of headaches. For example, say you want to set up the project with a MIDI controller, such that when you turn a knob, it controls that knob in the selected cell – the built-in MIDI system in Reaktor won’t handle this properly, and creating a work around would be clunky and ugly.

By contrast, with the implementation I show today, there is only one of each knob, not 128. You can simply set that knob to be controlled by any CC value and it will write that value into an event table for the currently selected cell. This is a good example of how thinking about exactly how you want things to work can pay off in Reaktor.

So, let’s take a look at the knob structure I designed, and then I’ll break it down piece by piece:

There are several things to note here. First, there are two Event Tables, sharing data (IE, writing to one table also writes to the other). This can be set in the table properties. Second, the IC Send module is connected via IC to the knob. The knob (named MIDI Min in the picture) and the IC Send module must have the same range. The range for both modules can be set in the function tab of their respective properties.

Okay, let’s take a look at some smaller pieces, starting with the knob itself:

On it’s surface, this is a very strange piece of code. It simply ends up delaying any event coming from the knob by a single millisecond. What’s the point? Well, looking again at the first picture, you’ll notice we have an input, ‘Act’ (for ‘Active’) that reads out a value from the top Event Table.

‘Act’ receives an input when the user selects a new cell from the interface. All of the knobs just to the value of the currently active cell. So, an event at ‘Act’ reads a value from the table and sends it to the knob. However, if the knob receives a value that ends up flowing directly back into the Event Table with no delay, we will get an event loop warning from Reaktor, which is fairly annoying.

So, by delaying any value from being sent back to the table, we avoid this problem.

Next, we have this simple code fragment:

This necessary piece of code is simply to turn off the knob during the loading of a new snapshot. Therefore, the ‘Rcl’ (for ‘Recall’) input is almost always set to on, except when a new snapshot is loaded.

Thru extensive early testing, I found a bug that occasionally caused the wrong values to be loaded upon recalling a snapshot, and added in this bit of code. Test your work, try to break it and make sure everything functions as planned!

Okay, that leaves us with the Event Table controller:

‘Act’ sets the active cell. That means, any change of knob position gets recorded and recalled with that cell. When we receive a new active cell, we first read out the value of stored at that location and send it to the knob. Therefore the act of selecting a new knob changes the knobs on the screen to the values held in that cell.

Notice that the active cell also sets which element in the Snap Value Array the knob will be stored in. The +1 and -1 modules are necessary due to the SVA having a range from 1 to Length, and the Event Tables having a range from 0 to Length-1 (A massive design flaw in Reaktor in my personal opinion).

Finally, the value of the knob in any cell can be read using the Read input.

CONCLUSION

That wraps up the design of knobs in our project. Next week, we’ll discuss designing an Event Bus to get all of the values we’re creating to their appropriate destinations.