The purpose of this FAQ is to provide a central repository for answers to common questions related to the software Reaktor (what is Reaktor?). These questions often come up in the Native Instruments online forum, or the various Yahoo mailing lists related to the software. Having a document such as this allows people to answer common questions with a simple “Read the FAQ <link>” type of an answer. I’ve tried to gather as many of the most common questions as I could, though some things may have been left out, and those should be asked in the appropriate forum(s). Questions related to such subjective topics as; “Mac vs. PC”, and “what is good music” have been intentionally omitted due to their controversial and/or inflammatory nature.

The intent in providing a FAQ is to make the information freely available to whoever needs it. You may copy all or part of the FAQ, but please be sure to include a reference to the URL of the master copy, and do not sell copies of the FAQ. If you want to include information from the FAQ in your own web site, it is better to include links to the master copy rather than to copy text from the FAQ to your web pages, because various answers in the FAQ are updated at unpredictable times.

If your question is of a general nature related to synthesis, digital audio, PC or Mac hardware, etc., then the best thing to start with is one of the many general web search engines:
http://www.google.com/
http://search.yahoo.com/
http://www.alltheweb.com/
http://citeseer.nj.nec.com/cs

Reaktor-specific questions are best answered on the Native Instruments Reaktor forum:
http://www.nativeinstruments.de/forum/forumdisplay.php?s=&forumid=30

Is general terms, Reaktor is an audio software package created and distributed by Native Instruments (aka "NI") that is used for synthesis, sampling, and electronic composition. The beauty of Reaktor is that it allows you to build-up your own unique instruments from small building-blocks (or "modules"). These instruments can then be saved as files and shared with others. The following is a description from their website:
In my opinion this little blurb hardly does the software justice. You can read the full description here.

Reaktor Session alows you to open and use any instrument created by someone else using Reaktor, but it does not allow you to modify that instrument's stucture or create your own instruments. Again, from the NI website:
In other words, it's a less expensive version of Reaktor for those who are not interested in building their own instruments.

Relating to Max/MSP, forum users had this to say:

The most obvious and active place is the NI User Forum:
http://www.nativeinstruments.de/index.php?id=forum_us

There are a couple of Yahoo Groups (mailing lists):
Reaktor Builder's Forum
Reaktor User's List
Reaktor Romp (a spam-free Reaktor User's List)
Native Instruments (devoted to NI's whole product line)

There are also several sites with forums related software-synths and electronic music making with software:
KVR fourms
http://theoreticalplayground.co.uk/forum/index.php

The most obvious place is the NI Online User Library, with over 1500 files here:
http://www.nativeinstruments.de/index.php?id=userlibrary_us
...of course you need to be a registered Reaktor user to get files from there, but then I *know* everyone's doing the right thing and buying this great software - right??

Other places to get files:
Thanks to D.Coffin for compiling this list!
http://joeorgren.com/tech.htm
http://www.lost-online.com/
http://www.mindspring.com/~clist/reaktor/files.htm
http://www2.charlielamm.com/reaktor/download/index.php3
http://www.midiworld.org/AuReality/products/reaktor/reaktor.html
http://www.swiftkick.com/
http://www.martin-brinkmann.de/ens.html
http://www.kvr-vst.com/bank.php?getbank=54
http://www.creativesynth.com/subgroups/NIZone.html

www.reaktions.com ...is a website devoted to showcasing "Reaktor-centric" music. I.e. music composed using Reaktor as one of the main instruments, or the only instrument.

Submitted by Jonathan Leonard of Native Instruments...
There are quite a few manufacturers and models to choose from, and these days certainly more hardware can be used with reaktor than in the past. For the most part, if you already have a professional audio card for your Digital Audio Workstation (DAW), reaktor should run well on this. In general, soundcards that come with prebuilt computer systems or used for games are to be avoided. When considering a soundcard for reaktor bear these points in mind:

1. Do I do other things besides Reaktor?
If all we ever did is run reaktor standalone, this section would be shorter.

2. Latency:
Reaktor to be used for live instrumentation must achieve consistent artifact free low latency operation. Most human sensitivity to timing is between 15-20ms. Musicians however due to their very different training are more sensitive and generally prefer something < 10 ms. This is also on par with hardware instruments. Many factors contribute to latency, or the time between striking a key and hearing a sound. These include the speed of the CPU, the priority by the OS given to the application and the driver, and the quality of the driver itself. Remember that the goal is not ultimately the lowest latency value possible, but the lowest consistent operating value under typical soundcard parameters and CPU load that is artifact free. Given these considerations, when selecting a soundcard you should be looking for one that can perform to these expectations. Generally if you have a fast computer, look for a professional soundcard that has OSX and XP support. Standards to look for are Coreaudio in OSX, ASIO or WDM driver support in XP, and ALSA drivers in Linux.

3. Outs AND Ins:
Reaktor is not just a virtual synth. It is a very capable processor for Live effects. To ignore this aspect of reaktor is like not being able to roll down the windows in a car. When choosing a soundcard for reaktor, bear in mind that some of the most interesting effects available in software come in ensemble form and that reaktor can sample itself while processing the inputs. Get a soundcard with inputs and further get a soundcard that can use the inputs at low latency settings. A bad example would be emagic's emi-2/6 which can put out quick, but cannot monitor at those same values.

4. Video and Interrupts:
Reaktor has alot going on visually including scopes, LEDS, multipictures, waveform overviews. The canonic tech says that graphics is tasked to the video card and nothing in graphics should ever load the cpu, and certainly never affect the audio output. In the wild however, graphics can be shown to load the cpu, and sometimes especially with PC's; cause artifacts. Some audio card / driver / platform /component combinations work more smoothly than others. When setting up a system and installing the selected audio card, look to see what happens to your audio output when you use the windows. Try minimizing, maximizing, moving the window. Try hovering over a window button, and even try launching other programs to see what happens to audio output. If you hear any bullshit whatsoever, then COUNT on this happening when you take this card live. Let me also say that program launching causing artifacts may not be related to video but virtual memory or swap file use...that often contain things like window positions and data.

5. Other Audio Clients:
Some audio card drivers support Multiclient use like those made by EchoAudio. This means that more than one program can access the audio ins and outs at a time. That usually does not mean the SAME set of audio ins and outs. Just that maybe one program uses 1-2, another uses 3-4 kind of thing.

6. Reaktor over system link:
Another thing to consider is whether you are setting up a spare cpu for instruments, or are clustering ala System Link with CubaseSX/Nuendo and Vstack. You may need more than 2 inputs on a node to connect to system link which uses spare audio channels to share events and synchronization messages. I mention this because system link may be the best way to integrate one or more reaktors into your studio.

*In general, whatever is good for a DAW should work ok for reaktor.*

Manufacturers:

RME: Makers of the Hammerfall series interfaces. Pricey, but highly regarded and may have the most solid low latency drivers.

Echoaudio: History of writing respectable drivers in windows and now OSX. They make a popular laptop interface called the Indigo that comes in in/out and double outs for dj's. (Multiclient)

MOTU: This company offers interfaces in many sizes. Respectable latency...

Emagic: Stay away and don't buy the hype.

Frontier Systems: Great equipment, low latency.

Digidesign: RTAS still has fixed internal buffer size and digi has only marginal interest in softsynths or anything that doesn't cost $10,000. Avoid these if Reaktor is your focus.

Maudio: Very affordable audiocards with respectable latency. Not the lowest, but usually a good bang. Their audiophile models are good entry level cards for beginners, students and music labs. They just announced that they are the first to write 64bit drivers, but as we know reaktor is far from being 64bit or multithreaded.

Creativelabs: NO.

Emu: Possibly.

Search for "optimize windows for music" in yahoo. Here's some links to get you started:
http://www.tascam.com/products/computer_recording/W2k_XP_Optimize.pdf
http://www.musicxp.net/tuning_tips.htm
http://psbg.emusician.com/ar/emusic_windows_washing/

Reaktor (like all NI software) requires an authorization that is based on your current hardware. The software generates a "system id" based on your hardware configuration, you send this key to NI (usually over an internet connection, but you can send it other ways as well) and they send you an authorization key that unlocks the software.
From the NI website:

To my knowledge, it is only availble in PDF format in the NI "Komplete" collection.

The current version is 4.1.2. It is generally considered to be a very good release level and largely bug free. The biggest current complaint is a degradation in video performance from the last release.
It is avaiable here: http://www.nativeinstruments.de/index.php?reaktor4updates_us.

If you want to know; "where should I start to learn how to make electronic music (in general, not with Reaktor)?" - then you are asking a question that is better answered outside the realm of Reaktor. You might get some answers to this kind of a question on the Reaktor forums, but the answers will inevitably be as vague as the question. Additionally, answers to these types of questions on the Reaktor forums are often more annoying than they are helpful thanks to a few avant-garde intellectual-types, who'll gladly use your question as yet another opportunity to remind everyone that they think the more popular forms of electronica are oh-so banal. (This should not be taken personally, it has to do with them, and not you or your question!)

The best place to start is to ask yourself "what kind of electronic music do I want to make?". Then go out on the web and search for some forums or websites devoted to that type of music. Then look for your answer there (someone's probably already asked the question). After some more research like this on the fundamentals and getting a clearer picture of a process that some people are using to make the music you want to make, hopefully you'll be in a position to understand if Reaktor is right for you and understand what it will do for you and how you'll use it.

Get some magazines - the tutorial-style ones like "Computer Music" are especially helpful. Just take what they say - and especially their reviews - with a grain of salt. They are, in the end, an advertising medium after-all and they want you to buy more gear and software than you may actually need!

Then when you can understand the benefits of the glorious software that is Reaktor, continue on with this FAQ, read the forums, and ask some more specific, better informed questions when you have them.

The "Synth Secrets" series from Sound-On-Sound magazine is a great place to start. You can find them all grouped under this search-link:
http://www.soundonsound.com/search?page=1&Keyword=Synth%20Secrets&W...
Unfortunately, there's no way to change the sorting, and they are sorted from newest to oldest, so you need to go to the last page and start there with the "May 1999" issue. This series is not Reaktor specific, but covers pretty much everything about traditional (and not-so traditional) synthesis techniques in a lot of detail.

The; "Ok, I just got Reaktor, and I am totally lost." question is indeed very frequenty asked. You can read a thread that starts that way here. Don't get discouraged, it's a long road when you're starting out, but many have travelled it and arrived safely at their destination.

Here are some other nuggets of wisdom from the NI forum:

See Question 1.8 ...above.

One of the best ways to learn how to build is to take apart an existing ensemble that you like and see how it works. Unfortunately, this can be a very frustrating experience because many of the structures may not be well commented. Even the standard library instruments that come with the software are not well commented (something that really sucks IMHO). Getting into these ensmbles can take a LOT of time, but so can the building process. Still, if you want to learn how to build Reaktor enembles well, it is the best way to learn.

As an example, when I wanted to make some heavy modifications to the Vierring instrument in the Standard Library, I spent a solid 8 hours picking apart every bit of it, adding comments to the macros, changing macro names, changing port names, commenting ports, commenting panel controls, reorganizing the layout of the modules in the structures so the wiring made more sense, etc., etc. Only after doing all of that did I start actually modifying the structure.

Doing this can be a *very* educational experience and I highly reccommend it. Pick an ensemble, pick a place to start, anyplace. Start adding comments on the macro and the ports of the macro. If you can't figure it out what a macro does, dig into it, or skip it. Figure out the structures that are upstream from it so you can better comment the ports feeding it. Figure out what's downstream from it and comment that and the ports running out of it, then come back to the strange macro later when you've gotten a better feel for the builder's style or what the inputs and outputs are doing. Save often! The last thing you need is a Reaktor crash after writing 1000 words worth of comments! (Crashes happen rarely if ever if you're not changing the structure, but better safe than sorry).

One of the toughest things to do during this process is to ask for help, but give it a try. If some bit of coding has you stumped, send an email to the builder, they'll usually explain it. It could be you've just found a bug the builder didn't even know about, so they'd be grateful. Don't be shy, if the builder doesn't get back to you, ask on the forums. You need a certain level of humilty to get through the learning process as quickly as possible.

When using Reaktor in stand-alone mode, there are basically two ways to record the output. The first, and simplest is the "Recorder Box". This is a window that allows you to save audio from Reaktor directly to a file. A lot of people don't realize it even exists because it's usually hidden. To use the Recorderbox, go to the View menu item and select "Show Recorderbox". The functions are pretty intuitive, but you can read about it in your manual if you ave any problems.

The other way to record is with the Tapedeck modules. They can be found in the "Auxilliary" group of modules. Adding the tapedeck to an instrument's output lets you record it directly to a file, it is, however, a little more of a complicated process as you'll need to build a structure to control the module.

The short answer: Make sure the "Globally disable event loops" setting is un-checked in the system preferences, and the "Event Loops" setting in the instrument properties is checked. If it is already checked and you are still getting the warnings in that instrument, try unchecking and checking it. The Long Answer: As of v4.1, Reaktor has the ability to "Disable Event Loops". When Event Loops are disabled, Reaktor will stop events at places in the signal chain where it thinks an event loop is occurring and issue a warning. The idea here is that if you have an instrument or an ensemble with an event-loop you may not be able to open it because the loop would cause Reaktor to crash. When you have the "Disable Event Loops" setting turned on, you'll be able to open the instrument and correct the problem. The issue as of r4.1, however, is that Reaktor sometimes thinks there's a bad (uncontrolled) event loop when there is not, and sends up these warnings all the time. This can be especially annoying in complex sequencers and things where there are a lot of counters and complex feed-back type event activity. By telling Reaktor to *not* disable event-loops, it allows the loop to happen and doesn't give you a warning. If you need to debug something that is crashing reaktor, turn the settings back to not allow event-loops.

When describing Reaktor modules used in structures it is common practice to use a form of "camel notation" - something of a carry-over from the computer programming world. In camel notation, words are combined together but each new word is capitalized. In addition, to tell the difference between Audio and Event modules the word Audio and Event is often prefixed onto the front of the module name. There's no hard-and-fast rule here, but most users can usually figure out what the author is taking about. So when you see things like: EventSeparator, AudioMirror, EventRouter, etc. in the descriptions of structures you should know that they are modules. Similarly when describing a structure for other people, it's a good idea to follow the same conventions.

Sometimes this programming lanuage paradigm is taken one step futher when describing how modules are connected togther by listing the inputs and outputs of modules with a "." notation. So if the output of an EventMerge module were connected to the "Val" input of an EventValue module, the author might write;
EventMerge.Out -> EventValue.Val
...or possibly...
EventMerge -> EventValue.Val
...since an EventMerge always has only one output.

Sometimes you want a knob to be controlled by some function in the instrument rather than by (or in addition to) the mouse actions of the user. If, for example you are saving the values of the knobs in a table rather with a snapshot. Or if you want to add some random jitter to the panel controls, and you want the user to see this happening. There are two ways to automate knobs, switches, buttons, etc., in an instrument. Thay are; internally routed MIDI messages, and Reaktor-specific "wireless" connections.
In both cases, there can be value mapping problems. For example, MIDI-CC messages fall into the range of 0 - 127, so if you're sending messages that fall into the range 0 - 200, with a stepsize of 1, you going to lose some values. As of 4.1.2, this seems to have been addressed for both internal MIDI and wireless connections, but I'm not exactly sure and haven't gottten into a serious debugging session to check out the details. Just be aware and watch for it.

Internal MIDI Messages
In this case, standard MIDI CC (Continuous Controller) or PolyAT (Polyphonic Aftertouch) messages are sent from either a panel control, or a MIDIOut module in the instrument and received by another panel control or MIDIIN module in the same instrument. In order for this to work, the instrument must be set receive messages from "Self" (itself) in the Connections section of the instrument's property page. Once that's done, any MIDI-out messages will be sent back to the instrument and can be picked up by any control set to receive those messages with the same MIDI-CC or PolyAT number.

Advantages:
Before the most recent release of Reaktor, this was considered the most stable way of doing panel automation in an instrument as there were problems with Reaktor-Wireless connections getting lost or broken on file save and restore. As of 4.1.2, however, this problem seems to be fixed so this is no longer a good reason to use the MIDI message type of automation. This leaves few advatages for MIDI over reaktor-messages;
- Allows you to record / playback the messages in a host sequencer.
- Allows you to monitor the message activity outside of Reaktor (not really a very good reason).
- If the Reaktor-Wireless connections ever break again, you'll know this is working :)
Disadvantages:
- You need to remember to set the "Self" connection for the instrument. Something that can be easily forgotten if the automation is happening in a macro that's getting cut-and-pasted into a different instrument.
- You use up MIDI CC or Poly AT channels that you might want to use for panel controls.
- The panel controls that are automated might get accidently hit with MIDI messages from someplace else in a plug-in environment, causing strange behavior

Reaktor Wireless Automation
In this case, Reaktor keeps an internal list of objects that are linked together. For a description of how to set this up, see question 6.3 below.
Advantages:
- Internal connections are saved with a macro - External MIDI does not interfere with the automation - Knobs can also be controlled MIDI - separately from the wireless automation - Better for insuring the exact value sent is the one recived since it's not mapping through a 0 - 127 MIDI value Disadvantages:
- Used to be unreliable

This question can also be asked as; How to I turn off two (or more) signals using only one panel control?
Posted by mirjun and ewistand: read the full thread here.

Posted by CList: read the full thread here.

Posted by CList: read the full thread here.

Take the following structure;

Anytime one event source (in this case a MIDIGate module) has two wires coming out it, you need to remember that the two things "downstream" are not going to recieve the same event at the exact same moment.
Events are "procedural", which is to say, they do one thing, then another, then another - like stepping through lines of a program.
This all happens in one event "tick" - i.e. at effectively the same time in terms of milliseconds - but at a fine-grained level, one thing always has to happen before the other.

So, getting back to this picture, when a MIDIGate event is generated, one event will be sent to one LFO and one will be sent to the other - but which one will get the first event??
The answer is: you don't know! Traditionally, it has been the case that the order the modules were pasted into the structure set the event order, so if you knew that LFO #2 was pasted in before LFO #1, then you would know that it would receive the event first. There's two problems with this. 1) You can't tell by looking at the structure which one was pasted in first. 2) As of 4.1, I'm told by very reliable sources that if you save an instrument ad then paste it in to a new ensemble, this rule no longer applies, the event-orders get completely rebuilt!

All of this means that you must be absolutely sure to use the EventOrder module when the order in which events get processed is important (it's probably not important in this case).

Most times people think Reaktor has a bug in the software it's because they are not taking event orders into account. The bug is in their ensemble and not the software. One such example came up o the forums recently and I'll paraphrase it here.
Take the following structure:


The idea behind this structure is for the BeatLoop sample-player to reset when a MIDI gate signal comes in. Everything looks good, he has a clock oscillator sending out ticks at a tempo-synced 96th note rate as required by the BeatLoop.Clk input. The Reset for both the Clock and the BeatLoop *seem* to be happening at the same time.

The problem the builder has having was that there was a slight delay between the time the MIDI gate arrived and the time the BeatLoop started playing the sample - a noticable delay of about 10-20ms. Why? Was it a bug with the Beat Loop module? No! The problem was that he was not controlling the order of events to the two resets and (just by chance - see item #6.5.1) the event was going to the BeatLoop module reset *before* the ClockOsc reset.

Think about it - if the MIDIGate event goes to the ClockOsc first - what happens?

1. The oscillator receives the reset event, it resets itself, and sends a "1" out it's output - a new clock tick.

2. The beat looper receives this clock tick, which may be out of time with what it's currently doing, but it just adjusts itself for that.

3. The reset event goes to the BeatLoop module. Now the BeatLoop resets itself to the start of the sample, but it won't start playing the sample until the next clock tick on the Clk input! It's going to have to wait one full 96th note until the oscillator does it's second tick.

Now, if the reset event goes to the BeatLoop first - what happens?

1. The reset event goes to the BeatLoop module. Now the BeatLoop resets itself to the start of the sample, but it won't start playing the sample until the next clock tick on the Clk input.

2. The ClockOsc receives the reset event, it resets itself, and sends a "1" out it's output - a new clock tick. This happens after step #1 but at essentially the SAME moment in time!

3. The BeatLoop receives this clock tick - which it was waiting for after the restet and starts playing the sample at the same time that the gate signal told the ClockOsc to reset.

So, how can we fix this? By adding an EventOrder module to force the event to always go to the BeatLoop module first, as follows;

This macro is designed for debugging events by showing them as they appear at the inputs. Let it be your best friend...
http://www.mindspring.com/~clist/re...tWatcherv03.zip

Here's a demo of it with some tips on usage...
http://www.mindspring.com/~clist/re...WatcherDemo.zip

Here's a new version that's smaller and also stores a "history" of about 200 events that you can scroll through. It's a little less efficient, and should not be used for debugging event problems associated with ensemble start-up, but I like it better...
http://www.mindspring.com/~clist/re...WatcherDemo.zip

It's probably not your fault.
See Question #4.2 ...above.

A question was asked on the forums recently...
...basically the "delete a wire, or flip a switch" problem relates to #6.5.6 (above), and has to do with the fact that event-sources all refire when the structure of any instrument in the current ensemble changes (or when audio is stopped and started). The problem is that somehwre in the stucture there is a constant that's firing at start-up *before* some other event source that's telling that constant where to route it's value and it's value is getting lost.

Here's my full reply from the forums...