Unboxing Blocks with Philipp Dransfeld and the REAKTOR team

You’ve seen people having fantastic fun making sound with wires – and maybe you’ve even been bitten by the modular bug yourself. But what if new toys like this were available on your computer – a rack full of sonic worlds to explore instantly? That’s the vision of REAKTOR Blocks.

With the recent release of REAKTOR 6.3, plus BLOCKS BASE and BLOCKS PRIMES, the Blocks virtual rack is opening up more sounds to more users. Blocks were previously only available to those who owned the full version of REAKTOR – now they run in the free REAKTOR PLAYER. As with the full REAKTOR Blocks, you can patch on the front panel, finding and adding modules is easy, and new documentation is available.

This is just the start. More and more builders are introducing modules, some even derived from hardware, and hardware modular developers Michael Hetrick, Genki Instruments, Holonic Systems, TOYBOX, and ACL, have all already released Blocks modules.

To find out how this new direction came about, and to get to know the people behind the release and learn how they work, we talked to REAKTOR Product Owner, Philipp Dransfeld, and his team.

Can you tell us a little about your background? How did you end up doing what you do?

Philipp: I was fiddling around with piano and guitar in my youth and played in some mediocre bands while going to school. Not exactly knowing what to do after school, I decided to get an education in audio engineering, which led to work in studios and doing music composition and sound design work. I had a short but quite fun intermezzo as an artist, just touring with my live act through clubs on the weekend and producing during the week.

But even after a stint studying economics, I followed my passion for music and the weird world of the arts. That’s how I ended up at Native Instruments.

I’ve been working for several years in the marketing department and switched two years ago to the new role as product owner for the REAKTOR platform.

REAKTOR is a product with an enormous history. How has your team tackled that legacy?

REAKTOR has taken quite some turns in its 20 years of history – and so did the development focus.

While REAKTOR started as a kind of digital modular, it became way deeper with the addition of the low-level programming language Core. On the other side, REAKTOR also changed with the introduction of “Powered by REAKTOR” products, like THE FINGER by Tim Exile, or the fantastic RAZOR by Erik Wiegand [a.k.a. Errorsmith]. With the introduction of these products, REAKTOR turned into a multifaceted thing, which is less easy to position sharply. It’s for a lot of people just a shell to run synths in, but for others, it’s a fun builders’ platform – especially the community contributing to the User Library. And for another group, it’s a deep programming language for audio.

So, whatever we do, we have to balance the interests of these groups carefully.

Typically we start with evaluating how we can contribute to the bigger picture at the company, and then pitch our ideas. As soon as we start the project, there are so-called ‘sprint reviews’, when stakeholders check in and teams present their past two weeks of work. Whenever applicable, we try to get real people on the product to see if we are on track.

Technically, we work as a team of four developers – a designer and a quality assurance engineer. The latter one has a pretty important job, as stuff is quite likely to break while developing a new feature, given the enormous size of our codebase.

So, when you open this new REAKTOR and Blocks, those front-panel patch points are visible right away. That seems like a big deal – not only to REAKTOR users but REAKTOR PLAYER, as well. Do you hope this will get them involved in patching themselves (inside Blocks, or even deeper in REAKTOR itself)?

Yes, the majority of our users are using the free REAKTOR PLAYER. But even among owners of the full REAKTOR, we’ve learned the Structure view is daunting and hard to understand for newbies. With the introduction of front-panel patching, we removed this additional layer of complexity. Thanks to the universal compatibility of Blocks in the framework, we have now a rather playful approach for experimentation with synthesis. That is, anything made to run with the new Blocks format will run in these Racks.

Once users understand the general concept of signal flow and the difference between control, timing, and audio signals, seeing the ports in the structure later will be more familiar.

I assume the idea of front-panel patching was obvious, from the start of Blocks. How difficult was it to implement inside REAKTOR – did it require big changes in how patching works?

Ha, that was actually not that clear for us. In the beginning, we just wanted to switch to a new reference-based file format. We saw people struggling with patches not being saved with DAW sessions. Also, it’s not exactly the nature of hardware modular synthesis having ‘presets’ within a patch, because the patch itself acts as a kind of preset.

Right, that makes sense – some people even have kept ‘patch books’ with drawings of patches by their hardware. So how did users receive it?

The reaction in user testing was: “Hey, that looks exactly as it looked before, what did you actually change?”. In these interviews, we also saw people struggle between Structure and Panel views.

One of our developers, Georg, had luckily added front-panel patching during our internal Hack Days [an annual week-long event where Native staff are encouraged to break/hack/mess with Native software and hardware in creative, useful and fun ways], so we were able to test this quickly with the users. And that did the trick, making the depth of the update visible and tangible. There was still a lot of work to implement the panel wiring properly, but we didn’t have to change the general architecture – the wires on panel are just a different visual representation of the Structure wires.

I know for us as users, it’s easy to ask for stuff. I’m sure it’s the same even internally as teams work with engineering. How hard is it to then implement those features – like what was here in REAKTOR 6.3?

Oh, it’s often surprising to me which features are in the end relatively smooth to build, and which aren’t. If you want to see developers laugh, just say “It can’t be that hard, guys!”.

With this project, we had some dependencies to our partners’ project timelines, so we had to align our development timeline partly to their needs. So, for instance, you have to get the file format right in the beginning, as bigger changes will affect the compatibility of existing content. At a certain point in time, you will also need the tooling to make a ‘real product’, as you will always find some issues which were not caught the first time around. In total, we spent over a year to get everything sorted.

Do you make prototypes to features first, or do you really go from idea to code and then immediately to testing?

Jonathan Baruc [Interface Designer]: We prototype as much as possible. Paper prototypes, click-dummies, hacked builds – the usual suspects. When and where cheap enough, we take the approach of implementing and merging, then let the feature marinate. Using logic and brief user tests are informative, but can be deceiving!

Really breathing the user experience [UX] day-to-day in our personal REAKTOR hours is the best way to make design decisions we feel. If myself, the designer, developers, and beta fanatics around the office agree on the same hiccup in a proposed workflow, we change it.

One of the most interesting design decisions, which was heavily user-tested, was the front panel patching. The hardware-like ‘droopy’ wires were tested against a more streamlined ‘graphic’ approach. It became apparent that not only do users not mind the ‘messy’ wires, but they embrace this visualization. Some are familiar from their current hardware setup, others desire said setup, and even newbies said it made them feel like ‘mad scientists’ and <that it was> ‘easier to follow.’

But if they’re not for you, CMD+2! [CTRL+2 on Windows]

Wow, that’s a great tip – shortcut noted! Now, you’ve already pointed out the interesting and diverse range of REAKTOR user types – so user testing is probably a little different than for other Native products. Who was testing these builds?

Jonathan: We tried to bring in as much fresh blood as possible. There were folks ranging from enthusiasts who want to break in to music, who will just use the bundled rack content, to DJs and producers who want to warm up to synthesis, up to people who want more modular in their life, but perhaps don’t have the budget of, say, a SpaceX turbine.

We were sure to bash the feature developments against more pro or legacy users as a sanity check. But our focus was primarily on newcomers who, until now, may have found REAKTOR intimidating or inaccessible.

What was necessary to make the Rack file format work?

Georg Haupt (Software Developer): First of all, it was obvious that to reduce the data size, we would have to get away from storing the patch the way we do when using Blocks in Ensembles. Instead, one main part of the Rack file data is a list of the used Blocks as referencing items that let us find and load them when the Rack file is opened on some computer, provided that all of the products the Blocks belong to are installed using Native Access. Then, besides the preset data (knobs positions and so on), we needed to include all other data the user can edit in Rack mode.

What can we expect from some of your partners working on Blocks modules? How did they come onboard this new ecosystem?

Philipp: We started in the middle of last year, starting with Michael Hetrick to make his incredible contribution to the user library available for Player users. TOYBOX mastermind David Alexander also approached us with ideas.

At Superbooth 2018 we showed the prototype of our update to companies who are now on board, like Holonic Systems, Genki Instruments, and ACL. Holonic Systems and Genki are working on new concepts of interaction with musical devices, which we see as the perfect match for modular patching – freedom and control. ACL is a Berlin-based boutique modular company, and one of their developers is a long-term REAKTOR super user. You will see a fantastic effect module, which makes a fluent change from chorus/flanger type effects to delay/reverb possible – perfect for adventurous modulation!

Part of what makes Eurorack work is that so many makers have been able to create devices in this format. What will that look like in the world of REAKTOR – is this a place where creators will be making their own modules? Do you see a business model for them there?

Indeed, the variety of modules coming out in the last few years is a driver for the whole market. And with the initial release of REAKTOR Blocks, we provided a good template and documentation on the Blocks framework in REAKTOR – which lead to a lot of incredibly good contributions to the user library.

The template and the documentation for building will be updated soon with the patching ports on the GUI front panel, so the contributors to the user library can also build Blocks with these too.

But currently, these user-generated Blocks cannot be used in the new Rack format. This format was intended as a ‘fail-safe’ for inexperienced users. At the moment we don’t have the tooling to make this available for user library Blocks. We ask for some patience as we look at how to deal with user-generated content.

For those builders who want to make commercial releases, we already have a business model in place – as you see with the products already available.

How do you see the relationship of REAKTOR Blocks to physical hardware, especially with these new improvements?

For me, personally, the physical and the software world are complementary. I love my little hardware modular at home, but somehow I’m still pretty resistant to investing hundreds of euros a month into more envelopes, LFOs, sequencers, and so on. The initial purchase already made me broke!

Additionally, in the digital world, you have completely different possibilities. If you’re looking, for instance, at the Blocks from the Kodiak family, these designs are hard – or even impossible – to build in the analog world. Also, things like saving patches for later, sync options to other entities (via Link, or anything else) become handy if you’re starting to really record a track with modular involved. With a DC-coupled audio interface, you can even record automation tracks via REAKTOR Blocks in your DAW, and make more complex and controlled movements possible.

To get started with BLOCKS yourself, try out BLOCKS BASE for free. Or if you’re a REAKTOR 6 user, you’ll find the free update to version 6.3, including BLOCKS PRIMES, in Native Access.