How to Create an Event Bus in Reaktor

This tutorial is the fifth part of a series, Anatomy of a Reaktor Project . The idea is to outline and create a very large and complex Reaktor ensemble from scratch, showing each part of the process along the way. You can check out the first installment for an in-depth discussion of the ensemble we are building.

WHY USE AN EVENT BUS?

Due to the overly complicated nature of our ensemble, simply routing knobs and other controls to their preferred destination is not an option. For one thing, the knobs I outlined last week hold 128 values each, and the value currently displayed by the knob is not necessarily the one received by triggered drum module.

Another problem is that Reaktor macros have a limit of 40 inputs and outputs. Yet we are storing the vast majority of our knobs in a single Stacked Macro – there will be more than 40, to be sure.

There are several available Event Bus systems already designed for Reaktor, the most known of which is included in the Partials Framework, coded by NI employee Max Zagler. However, for the purposes of this tutorial, we’ll create one from scratch. I have a few reasons for this, but the most important one is that I find the Partials Framework to be excessively complicated, and despite having great manuals that come with, it also lacks documentation for it’s individual components.

Building our own Event Bus ensures that everything works the way that we specify – plus it’s always a good learning exercise to build something yourself! Also, we are creating a very specific ensemble with very specific needs – as a universal Event Bus, the structures I’ll be showing today are usable but a little clunky. However, the information provided should allow you to customize an Event Bus to your own needs.

Fortunately, there are only a few simple components to create.

CREATING AN EVENT BUS

The basic structure of an Event Bus is to create two macros: a Bus Send macro, and a Bus Receive macro. Each event source has it’s own Bus Send, and any spot that wants to receive values from the Event Bus has a Bus Receive.

The Bus Send macro is responsible for identifying the events with a unique index number. Each Bust Receive macro receives events only for a given index. In our project, we have the added complication of needing to send each event only to a specific voice as well (this because each MIDI note can play a completely different sound, with different parameters), but we’ll be able to ignore that until the very end of our build.

Let’s take a look at an Bus Send macro:

Well, I’ll bet you weren’t expecting that to be so simple! In fact, this is slightly more complicated than I would like, but it’s a necessary design for our particular project. The ‘Idx’ input is provided by a constant value that defines the index for any event sent out from this macro.

The ‘In’ terminal is provided by the event we want to send. Finally, the ‘R’ input is used to trigger the event (IE, send it to any existing Receive macros). Typically, you would want the knob (or whatever event was being sent) to be sent automatically, but due to the nature of our project, we only need to send events upon a new MIDI note press (and sending them at other times can in fact give us problems).

You can create as many Bus Send macros as you like. At the end, simply use a Merge module to merge together all the ‘Idx’ terminals, and another to merge together all the ‘Out’ terminals.

The Bus Receive macro, then, looks like this:

Again, this structure is exceedingly simple. As inputs, the macro receives it’s own (constant)index value, ‘[]’, and the merged event streams from the Bus Send macros, ‘Idx’, and ‘In’. As long as the values at the ‘[]’ and ‘Idx’ inputs are identical, the events to the ‘In’ terminal are sent to the output.

You may have noticed that in a large ensemble, these structures could create a massive amount of extra events, as we compare each incoming Index value to the Bus Receive’s corresponding ‘[]’ input. Many people will worry about these excess events and try to avoid them as much as possible.

Don’t bother! These values are being sent only on a new gate press. Even in a situation where we are triggering dozens of drum sounds a second, we are unlikely send enough events to make even a 0.1% difference in our CPU usage. All told, it should take less CPU than any single audio rate module (which must be calculated at least 44,100 times per second). It is therefore not really worth the effort to optimize this.

CONCLUSION

The Event Bus is a crucial part of many fantastic Reaktor creations. I haven’t looked into the strcutures of Prism or Razor, but both are built around the Partials Framework and most likely use Event Bus macros. Anybody looking to overcome the annoying 40 input and output limit on Macros and Core Cells should look into using an Event Bus.

Next week, I hope to cover how all of these disparate pieces we’ve been building for our project are going to tie together. Specifically, using the MIDI system we designed to route the Event Bus signals (provided by our special knobs) to the proper voice in our drum machine.