Reaktor 6: The Next Tick of The Future of Sound Arrives


Reaktor 6 is here! This is the first new major version of Reaktor since 2005, and expectations are high. Does Reaktor 6 satisfy our lofty expectations? Here’s what’s new:


  • Reaktor Blocks 1

The big wow-factor in R6 is Blocks, which is a set of synth modules implemented as connectable units on the instrument level, mimicking the style and functionality of hardware modular gear. Blocks is exciting for a number of reasons.

  1. It sounds awesome! Blocks comes not only with its own new and great sounding modules but borrows bits and pieces from Monark, Rounds and Driver. Did I mention that it sounds awesome? The oscillators and filters in this package are among the best I’ve heard.
  2. It’s easy to get started. Compared to building your own instrument, even using stock macros, this is a lot simpler… deceptively simple, perhaps. There’s deep potential lurking under the simplicity. And the ease of adding and connecting blocks will help casual users discover those depths.
  3. It allows audio rate modulation of parameters. This is fun and encourages experimentation. You can plug anything in anywhere. Audio rate filter modulation? Yes indeed. And that’s just the most obvious option.
  4. Speaking of audio, you can easily build Blocks effect chains to process incoming audio. Run your guitar or voice through the Monark filter, modulate its filter cutoff with an LFO, then run the result through the Rounds delay – it takes a few seconds to drag Blocks from the sidebar into an ensemble and patch them together, then create modulation routings.
  5. There’s a flexible 8 step sequencer, a clock divider, and a pitch quantizer – if you want to do the kind of self modifying modular composition that’s next to impossible in a linear DAW, Blocks will get you there. Simple example: you can modulate the offset controls in the sequencer and the quantizer for hypnotic morphing sequences that walk the line between order and chaos.
  6. There’s a framework for creating your own blocks. I can only imagine what this is going to mean for the Reaktor user library – I predict we’re going to see some mind melting uploads from users. Remember, everything’s easily interoperable with everything else in Blocks, so even Block creators will have little idea what strange purposes other users will find for their creations.

Table Framework: A New Sampling Paradigm for Reaktor

From the documentation:

“Table References are a new signal type in REAKTOR 6. They allow flexible and efficient shar- ing of data in the structure.

“A table is a two-dimensional array of data, and Table References allow you to access this data anywhere in the structure. These properties make the Table Framework ideal for working with samples.

“Core Cells read tables from a Table Reference like they have always handled tables and arrays. The advantage is that a Table Reference can exist in the Primary level, thus it can be used to share data between Core Cells, and can be stored in a Snapshot.”

TL;DR: it’s a whole new sampling paradigm. The primary-level sampler modules are sealed black boxes, whereas core cells are user-modifiable and buildable. The table framework is designed to get sample data into Core cells easily. This is a big, exciting change. Reaktor 6 comes with example sampling macros to give you a starting point. The new paradigm comes at the expense of CPU – the new sampling macros use more horsepower than the primary modules – but the trade off is arguably worth it since users can forge their own knives and blenders to chop and warp samples.

New Look and New Building Features

Reaktor 6 has an updated GUI, but it’s not just a change of skin. The structure cables now behave differently, curving to more easily show you what’s connected where. And the cables change colors to indicate what kind of signal they’re carrying.

One of my favorite new features is in-place editing for macro, control, and port names, and constants. No more jumping between the properties palette and the modules to change names and values.

Like to design panels for your own instruments? You can finally turn off the 4 pixel snap-to grid and place panel elements freely. There is also support for changing font face, colors and sizes in the text and multi text modules.

A neat feature you’ll notice quickly when using Blocks is that instruments and macros can be set to “flexible” mode in structure view, allowing them to stretch to accommodate larger icons and longer names for ports.

In a DAW, you can now drag the Reaktor plugin window larger in edit mode by grabbing the bottom right corner. Great! No more fussing with auto-resizing and setting static window sizes in the preferences. Very handy for building or tweaking in your favorite host.

New Core Features

The cornerstone of the future of sound since Reaktor 5 has been Core, and there are new building features here, too. Bundles pack and unpack multiple wires, keeping your cells organized. And scoped buses work a little bit like variable scope in a programming language, making connections between different layers of a Core structure. Scoped buses can send bundles. In-place editing works in Core too, allowing you to quickly change macro names, constants and quickbuses.

Two features that will excite Core builders are the ZDF (zero delay filter) and envelope toolkits, providing elements to more easily create your own filters and envelopes. If filter design is not your thing, the reorganized and repopulated library of core macros is stuffed with ready made oscillators, filters and effects begging to be Frankensteined together.


Reaktor now includes an event watcher debugging tool, based on a macro originally developed by Reaktor user Chris List which I’ve used often in the past when designing new instruments. This is a super handy tool for anyone who needs to wrangle Reaktor events and is wondering why things aren’t working as planned. There’s also a comprehensive MIDI monitor, redesigned scope and a 2048 band spectrum analyzer with A and B inputs whose signals can be compared, added and subtracted.

My goodness, what ISN’T in this release?

It’s not all  cake and ice cream, sadly. I’m disappointed that some features and fixes were passed over.

  • Abstractions: Reaktor needs a class / object hierarchy in its macros, so that modifying a macro doesn’t require editing or replacing every copy that’s hardcoded throughout an ensemble. My wrist is aching just thinking about it.
  • Scripting: some programming chores are clearer and simpler in a textual language. Kontakt has KSP; Reaktor deserves some RSP.
  • Sampler bugfixes: the primary level grain cloud sampler has a bug involving detection of sample length. I’ve had to code workarounds for years. The table framework is the new hotness, but there are hundreds of great sampling ensembles in the user library that were built with the primary sampling modules, and they could use a little love.
  • MIDI out tightness: Reaktor’s MIDI out timing has jitter proportional to the audio buffer size, and this can be noticeable when driving external hardware and software.
  • Multi-core support: would have been sweet, especially for running standalone, but I can imagine this would be a nightmare for NI to implement in the infinitely flexible Reaktor engine, if it’s even feasible. Maybe someday. I’d rather see abstractions and scripting first.

Putting aside the gripes, though, this is a solid Reaktor update, and I expect to see people building tremendous new ensembles with the table framework and Core additions, as well as quickly learning to make music with Blocks – whose ease of mix and match patching will probably attract a new population of users, and perhaps lure them into diving deeper.

I love Reaktor, I’m passionate about it, and NI’s dedication to keeping it fresh means that my love affair can continue. Between that and the new features, I’m very happy to see this new release.

What do you think? Do the improvements and additions outweigh the gripes?

More Info on Reaktor 6 from Native Instruments, inlcuding upgrade pricing

  • dj sad

    Any word yet on if it supports multi-touch?

    • That’s an excellent question. I don’t have a touch-enabled PC so the question wasn’t even on my radar. I’ll put out a feeler, no pun intended.

      • dj sad

        Alas… 🙁

    • Jason C

      this is sooo important

  • chaircrusher

    This is crazy. I hear about Reaktor 6 from you & Rich Devine on Twitter, before NI even sends me the press release?

    What I’m really wondering is whether I should wait and get the next Komplete upgrade to get 6 or buy the upgrade now. I have a feeling I’m getting screwed either way.

    • It seems like it’s always a dilemma for Komplete users that way…

  • Resist

    Blocks look like fun. I’m hoping more blocks will be released by NI themselves for example razor’s oscillators or filters.

    • Resist

      Or molekular modules within the blocks framework.

      • The more the merrier. But I think the really outside the box (blocks?) uploads are going to come from the user base, not from NI.

  • Mark Harris

    any idea if OSC has been fixed?
    (R5 used to not preserve the order of OSC messages correctly)

    • Are you thinking of incoming or outgoing? Or both? If it’s the problem I’m thinking of, then it’s related to the MIDI out jitter, or we might call it event-out jitter, and it hasn’t been addressed.

      • Mark Harris

        incoming OSC

        • Are you using TouchOSC by any chance? It was giving me trouble with event order that I wasn’t having with Lemur or Konkreet Performer.

          • Mark Harris

            no… I’ve written my own macros to process OSC messages from a Madrona Labs Soundplane.
            (you can see how i use it here

            I can retest them with R6 easy enough, I just have to remove the work-around Ive put in place to cope with the R5 bug.
            I just wondered if you had seen a changelog or similar for R6 which might have listed it.

  • Jason C

    dave Techdiff worked very hard on blocks for many MANY years.

  • Robin Parmar

    I am glad that Reaktor 6 is here, because it shows that NI is serious about retaining support for this excellent product, which is my main audio tool. Curved, coloured, and bundled wires, scoped buses… all cool. BUT version 6 comes without any of the serious features that developers have been clamouring for for about a decade now. Without abstractions, scripting, multi-core, and multi-touch, I can’t see a compelling reason to upgrade. (Blocks are an end-user feature.)

    • Believe me, I had a genuine dark night of the soul when I found out what was missing. However the more I learned about the table framework and the more I played with Blocks, the more I liked Reaktor 6. As for development, the Blocks template looks nice – – and comes with documentation.

      Aaaanyways. I can accept that multicore isn’t there. And I have a scripting workaround with Processing. But abstractions – that’s badly needed and everyone ought to deluge Native Instruments with requests for it.

      • Robin Parmar

        If they just gave us an API with Python library I would forgive them many other omissions. 🙂

        • I haven’t used Python lately – does it have a good, well maintained OSC library?

          • Robin Parmar

            Darn good question. I don’t know, because I still can’t buy any affordable OSC hardware!

          • You ought to be able to get signals in and out of Reaktor with Python OSC though…?

          • Robin Parmar

            Oh OK, now I see what you are driving at. My point was different, in that I want Python to control development, not just playback. I suppose an embedded scripting language would be even more useful.

          • That might be possible (controlling development from scripting) if Reaktor had open file specs – like, imagine if there was something like HTML / CSS to define what parts go where, how they’re nested, how they’re connected and how they appear, and the runtime interpreted that into an ensemble. I’ve suggested that a few times and been regarded as though I were a lunatic. But if they did that, you could edit Reaktor in a custom IDE, maybe even use the runtime as an embedded preview. Syntax highlighting… a proper debugger… I really am dreaming in technicolor. 😉

          • Robin Parmar

            We can dream, Peter. 🙂

          • joe

            sounds like supercollider

      • Jason C

        table framework really helps me.. also the bundles really helps me.

        • The TF is going to really shake things up, it’s bigger news than Blocks but not as showy.

          • Jason C

            long needed feature for power users

          • I really wish they could do something about the CPU usage of sample processing in Core though. It’s terrible compared to the primary sampling modules.

          • Jason C

            i haven’t had many cpu issues accessing table data in core. before 6..will test it out now once i get my head around the new framework

          • I think it’s more how the sample data is processed once it’s in Core. Just try some of the existing macros like the Core based grain sampler. It’s much, much less efficient than the primary level grain sampling modules. Maybe there are optimizations to be had… I doubt Core will ever be as efficient as C++ based modules though.

      • Robin Parmar

        “I can accept that multicore isn’t there. And I have a scripting workaround with Processing.”

        Do tell, Peter. 🙂

        • It’s just a method for passing arrays back and forth, so they can be processed in script and returned. And I have a Processing based LFO. I should package up what I have and put it out there.

          What Reaktor really needs though is an internal script engine that can address panel elements and modules, set properties, set dimension and placement and color, etc.

          • Robin Parmar

            Exactly. Without this, it’s crippled. And developers have known this for at least a decade.

  • Scott Josephson

    I’m an end-user, but a big part of what has made Reaktor such long-lived, popular, useful software are all the unique instruments that came out of the UL. As these were built by individual and 3rd party developers, adding in the functionality asked for by this community of builders would be a smart business move for NI, and would go a long way towards making this version of Reaktor as popular as past versions. Peter is right; if we can organize a flood of requests for these features, NI will be hard-pressed to implement them in future updates.

  • CaptainHowdy3

    You neglected to mention that Blocks are monophonic and eat absurd amounts of CPU.

    • OK, good points, and people have been bringing this up on forums. They’re monophonic but so are the coveted modules from Makenoise, Intellijel, Mutable etc. – and my 2 cents is, with the kinds of sounds you’ll be making you don’t want to play chords anyways. That’s not what this is for.

      On a technical level, Blocks are implemented as instruments, which can’t pass voice information between them. If you come up with an arrangement of blocks you especially like, it’s not impossible to copy and paste them as macros into a single instrument and make that polyphonic.

      As for CPU usage, I’m building a self playing Blocks patch that uses between 10% and 25% of a single core on my 6 year old iMac, depending on what filters and oscillators I’m using. Remember that Reaktor isn’t multicore, so its own CPU usage meter doesn’t reflect more than a single core’s load. Look at the DAW or system meter for a more accurate picture.

      All the NI factory blocks are oversampled AFAIK, and deliver sound quality that’s neck an neck with the best of the best in VA, stuff like Diva. So it’s a trade off. That sound doesn’t come for free.