Ever wish your music software could do something your way, something it can’t do now? Wish you could just get in there and change it yourself?
That’s some of the ambition of Renoise 2.6, the multi-platform music creation tool. By opening up the entire music tracker to scripting, users can create custom functionality and control surface. But scripting – while it sounds like the domain of hard-core geeks – doesn’t have to be daunting. That’s important, as presumably you want to spend some time making music. Scripting should save you time and let you express ideas more directly, not act as an impediment. So, the design of the Duplex feature in Renoise does work to make this customization accessible.
Renoise 2.6 has just gone gold master, meaning you can add it to your stable music setup. New in this release:
- Lua scripting. Customize the app using an elegant, clean, friendly language.
- OSC, MIDI support. Integrated control with Duplex (MIDI/OSC), native Open Sound Control support.
- Extensive hardware support. Maybe you don’t want to write a line of code, ever. You can let someone else do it for you, and reap the rewards. Already, Renoise has native, fully-integrated support for the AlphaTrack, BCF-2000, BCR-2000, KONTROL49, FaderPort, microKONTROL, nanoKONTROL, Launchpad, Remote SL-MKII, Nocturn, Monome, Ohm64, iPad via TouchOSC… all thanks to community support for the new scripting engine.
- Sample autoseek. Absolutely essential to making audio behave in the way it does in linear arrangement tools, the sample will play back from the position in the timeline, rather than from the beginning each time you hit play. (Seems obvious, but it’s part of making Renoise bridge tracker-style apps and more conventional, linear ones.)
- Better performance, compatibility. Tweaked performance on Linux and Mac, expanded file format compatibility, plus 64-bit Linux, DSSI Linux support. Renoise is a reason to run Linux, and Linux a reason to run Renoise, if you hadn’t guessed that yet. No, seriously, you’ll enjoy it. (I always feel like it’s telling someone to go vegan. Linux can actually be fun. And you still get to eat bacon.)
The release date seems the perfect time to really explain what Duplex is about, and what it means to you. First, it’s best to see it in action in this Duplex video. What you see is fully integrated hardware and software, but in a way that doesn’t necessarily require specific hardware. (There’s no “Renoise” logo on the controller – and you could substitute something very different and get the same impact.)
More information on the Renoise forum from the video’s creator, Danoise: Duplex – Playing With Loops
Basically, I’m arranging a small song on-the-fly, using a Launchpad + monome. Since the song was basically written using the StepSequencer, the vertical resolution of each pattern is just 8 lines. I then use the new loop feature in the Matrix to “pair” patterns into longer sequences.
This is just one possible workflow among many, but it’s one that’s I’ve found to be immensely rewarding when you’re sketching a tune out.
Bjørn Nesby, Duplex’s lead developer, explains his creation to CDM:
Duplex is aimed at both people who are willing to create their own scripts, and those who just want a nice way to interact with their music using Renoise. Many of the scripts (called ‘applications’ in Duplex) are pretty generic in nature, and will simply take control of a specific part of Renoise, like the Mixer or Pattern Matrix. This is something everybody can use, so this is where I focused my efforts to begin with. More exotic applications are also planned, but we needed to get the fundamentals in place first.
A thing that was clear from the beginning was, that the whole setup and configuration process needed to be as simple as possible. I think we succeeded in that, as my personal copy of Renoise will automatically launch the applications I need when the program starts, on three separate controllers. And I’ve heard from many people that they love this aspect of Duplex, as it reduces a potentially tedious startup process to an absolute minimum. Of course you can have an initial device setup process that you need to go through (like selecting the input and output ports for your device, which might vary from system to system), but in most cases you’d only need to go through this once, after which the device is ready to use.
And I believe this is not just about ‘convenience’, because sometimes you need to be absolutely focused on the music and not the order of which you launch various programs – especially true when you bring your music to the stage.
However, I have to point out that the configuration process is not perfect yet. There’s still room for improvement when customizing application mappings – this is currently done by editing some of the accompanying configuration files by hand, and although that might sound scary, it’s actually a pretty straightforward thing to do (and if not, the Renoise forum is there to help people out). Also, finetuning a setup like this is hardly part of the music-making process itself, so I hope it’s something people can live with for a little while longer.
From a developer point of view, the Duplex framework might be technically interesting as it attempts to follow the ‘write once, run everywhere’ model, as known from the mobile computing world, but instead applied to musical gear. For example, the Mixer application is able to run on all devices, from the Novation Nocturn to the monome128. Physically speaking, those are two very different devices, but everything in the Duplex API is abstracted to the point where a standard user-interface element like a slider can be a rotary dial (Nocturn), or an array of buttons (monome). In the application code, you simply create a slider, and base your logic around that. The framework will do all the dirty work of translating that into *actual* controls. This is possible because everything in Duplex is based around a descriptive XML file, the control-map. Unlike a traditional MIDI implementation chart, the control-map will not only describe the parameters and their ranges, but rather the complete physical layout of the device. Once a proper description has been made (and they are not hard to make, several of Duplex’ control-maps are user-contributed) you can launch an application on e.g. the monome that creates virtual sliders from individual buttons, because each button “knows” where it’s located in a X/Y coordinate space.
I’ve also tried to keep the syntax as familiar as possible. Many people who’ve done a bit of actionscript will probably recognize many of the concepts in this framework, hopefully making the whole experience a little less daunting for budding scripters.
One unique aspect of Duplex: the virtual control surface. When Duplex is installed, you can try out all the various supported devices, even if you don’t own them. Again, it’s the control-map structure that makes this possible, as you can define things like button size, color etc. Of course, this is not the same as the real thing (try hitting two buttons simultaneously using a mouse?), but it’s still interesting to play with, a huge advantage for developers as you can design a control-map that device owners can then try out and test, and makes for self-documenting applications, as you can assign tool-tips to the control surface that display exactly what each button does.
More information:
What’s New in Renoise 2.6 – Renoise Geek Edition.
And, of course, you can discuss Renoise and other trackers on our own Noisepages community. Specifically, we’re looking at how to use trackers in live performance.
Trackers for Live Performance @ Noisepages