Duplex 0.92

The next version of Duplex is ready for you to grab, but I’ll just stick it here for now to make sure that the release is solid before it goes on tools@renoise :slight_smile:


[/b]EDIT: please go to tools.renoise.com to download the newest released version[/b]


With v0.9, we saw the introduction of real OSC support for monome and touchOSC. The 0.92 release focuses on supporting the more advanced MIDI controllers out there - yes, I’m thinking about the Akai APC40/20, which is transmitting/receiving on multiple MIDI channels. As this release comes with full MIDI channel support, it should now be possible to support those devices as well. The syntax for specifying a channel is simple: modify control-map value attributes from “CC#10” with “CC#10|2” to make a control-change transmit/recieve on channel 2 (or leave it as it is for all channels).

Also, usability should be a improved a lot by the introduction of more useful tooltips for the virtual control surface. Before, the tooltips simply told us the name of the parameter, and the note/cc number it was transmitting. Instead, it’s now possible for applications to assign new tooltip values to the control surface, even in realtime (as the Effect application will list the name of parameters, as the different DSP effects are chosen). Hopefully this is a large step toward “self-documenting” apps, as it was not always obvious what any particular button was doing before - but now all you have to do is to hover the mouse over a control, and it will tell you.

Finally, thanks to the people who’ve contributed to this release: Beatslaughter, In-fluence, Daxton, cuubic etc… You know who you are

Full changelog for versions 0.9 - 0.93:

Done 0.9  
* OSC device / protocol support  
* Monome128 support (monome-specific class)  
* TouchOSC support (as generic OSC device)  
* Variable-sized controls (not all buttons are born equal)  
* XML comments is now supported  
* Fixed: Broken colums issue   
* UIComponent:set_pos() - supply just one value to set the index  
* Transport: follow player option  
* Device-specific release() methods for monome, Launchpad  
* Matrix - removed "BUTTON_HELD" (broken with hardware toggle-buttons)  
 (edit: reintroduced with check for toogle button input method in 0.92)  
* Korg Kontrol 49 Support  
* Korg nanoKONTROL support  
Done 0.91  
* Fixed: Transport: always turn off "start" when hitting "stop"  
* Matrix: all mappings are now without dependancies (no more "required" groups)  
* Application:add_component() automatically unregister components when exiting   
 o Existing apps updated to support the new method, destroy_app() removed.  
* Fixed: Effect: check if "no device" is selected (initial state)  
* Specify color-space as <group> attribute in the control-map <br>
 o Support for devices like APC, where not all buttons are the same<br>
 o Colorspace is still specified via the device class, but a colorspace defined <br>
 in the control-map will override the device colorspace<br>
* Specify MIDI channel mapping as an extension to the <param> value attribute<br>
 o Simple syntax : "CC#23|2" to match channel #2<br>
 o Optional: if undefined, simply match all channels<br>
 o Affects all messages that support channels (CC,Notes,etc.)<br>
* Seperate notifiers for press/release on the virtual control surface <br>
 o Now, it's possible to properly support "held" buttons events<br>
Done 0.92<br>
* Transport<br>
 o New option: "stop playback" when pressing play while playing<br>
 o Re-arranged Launchpad configuration (uses the new option)<br>
* UITriggerButton<br>
 o Added release event, and "wait_for_release" mode (a.k.a. sustain)<br>
* Daxton's Launchpad StepSequencer<br>
 o TODO make configurations for other grid-controllers as well...<br>
* Make tooltip descriptions for all applications <br>
 o Effect has contextual tooltip support: show name of DSP parameter<br>
 o The remaining apps have "basic" tooltip support<br>
* Replace the mapping property "required" (not used) with "greedy"<br>
* Add "ui_component" to mappings, to describe the type of UIComponent<br>
 o for the planned visual mapping dialog, this will be needed<br>
 o also helpful when browsing application class code<br>
Done 0.93<br>
* UIButtonStrip, for controlling/displaying a sequence<br>
  o Can control position and range simultaneously (Matrix sequence triggers)<br>
  o Optimized for monochrome devices<br>
* UISpinner improvements (better togglebutton support)<br>
  o TouchOSC and other controllers using togglebutton input should now <br>
    display the UISpinner correctly at all times...<br>
* Browser: <br>
  o Switch between device presets/configurations using function keys<br>
  o Forward keypresses to Renoise (except those we use for switching)<br>
* Application: <br>
  o Application.options[].on_activate(): specify a method to be executed <br>
    immediately before the application is started - for example, to provide a<br>
    UIComponent with values *after* it has been constructed<br>
* Matrix:<br>
  o Updated to support interactive pattern looping (via UIButtonStrip)<br>
  o Utilize "blinking" feature to display a scheduled pattern<br>
  o "follow_player" mode in Renoise will now update the matrix immediately<br>
* StepSequencer:<br>
  o Display playposition and volume simultaneously (via UIButtonStrip)<br>
  o Better support for other/monochrome devices (Monome)<br>


Looking good!

Im just starting to get into the new beta and duplex now. So forgive my easy questions, but how do I control more than just the first four tracks with the mixer template of TouchOSC? Do the tracks that are controlled change with which track currently highlighted in Renoise? If not can this be achieved?

Is there any way that changing view say from pattern to mixer in Renoise can automatically switch templates from mixer to matrix in TouchOSC (when its running on the hardware)


Does this mean Korg Kontrol 49 Support now?! Is this the release I have been waiting for… Not at home atm so I can;t try it out but the link has been sent to my personal email and the SECOND I get in the door… =D




Edit: oops, must read your question more carefully. The “actual” answer for this is: it’s something that is planned. And since it’s really not hard to make, I promise it will be part of the next update :slight_smile:

Since the touchOSC “simple” template only holds four tracks, but the buttons below it (which are used for mute) could easily be exchanged with another functionality that flip through tracks. Here are two different variations, which are simple modifications to the TouchOSC.lua file :

1: Use buttons 1 & 2 below the tracks for flipping through tracks (this leaves buttons 3 & 4 available for something else):

 mappings = {  
 levels = {  
 group_name = "1_Faders",  
 page = {  
 group_name = "1_Buttons",  
 index = 1, -- because this is a "UISpinner" it will take up two buttons, starting from the first index...  
 master = {  
 group_name = "1_Fader",  

2: Keep the mute buttons, use the fader above the tracks for scrolling through tracks:

 mappings = {  
 levels = {  
 group_name = "1_Faders",  
 mute = {  
 group_name = "1_Buttons",  
 page = {  
 group_name = "1_Fader", -- still a UISpinner, but this time assigned to a fader...  

I did not use black magic or secret codes to pull this off. It’s just a matter of looking up the device configuration (in this case, TouchOSC.lua), and then browse through the mappings. Each one corresponds to a matching entry in the application that the mappings are for (in this case, the Mixer application). Once you know the name of the application, you can open the application and it also has a section called “mappings” (usually located in the beginning of the class). Each mapping should come with a description of what it does, so it’s just a matter of entering the name into the configuration.

OK, there’s a bit more to it than this, but that really is the basic concept. The remaining part involves understanding how the various user interface components interact with the controller, which is a bit more complicated…

No, there isn’t. But I’ve heard this idea mentioned before, so maybe someone just makes it happen? It’s not going to be me, as I’d like to be able to use Renoise simultaneously with a friend on a controller, and a “focus follow” like this would just not be any good then…

PS: Note also that the whole TouchOSC template is missing the two middle sections - they are only there as placeholders for now. What they could be used for:

  • XYPad with four buttons underneath. Expose any XY devices in the song, switch between them? - 4x4 grid with four buttons underneath. A sample/drum-trigger with instrument switch?


Thanks for the quick reply danoise.

I am more interested in using TouchOSC/similar as a supplement to the actual composing stages instead of live performance.

What are the current limitations with this idea…(TouchOSC is probably the closest thing to this touch application I describe)

“Focus shift in Renoise to effects window brings up “effects” template in touch application. The current effect´s sliders are then mapped to the template´s sliders along with names of the parameters. Same template has buttons to toggle through effects in the current track thus scrolling along the effects window in Renoise”

This seems to me as the best way never to use the mouse when composing

Or would a touch-screen monitor here be more to the point??

@Daymoe : you might be interested in the ideas presented in this thread ?

IS there any special set up other than the regular drag and drop? How do I set this up to my librarian? When I run the duplex I get a crash after selecting the Korg Kontrol 49 both the options… I have a picture of the message that pop’s up if that helps atall… but it crashes Renoise basicly… It’ll switch between the error message and the screen that says that the script isn’t running properly and asks me if i want to close the script but wont let me select yes or no it just keeps on flasing in between those 2 messages… ARGH! lol… I can recreate this EVERY time not ONCE has it worked for me… Anyone getting the same thing?[center]
[/center]edit wow in my “task manager” (because I couldn’t get Renoise to close) there were like 12 Lua script failures running… Think we got a big bug =S

This could be just my renoise installation but every time I start renoise and just load the Kontrol49 setup for Duplex, I get the message below:

It flickers a lot while it gets stuck in a loop and I can’t quit renoise (another message pops up too). Will capture more messages if you need them but it’s tricky whilst it keeps grabbing focus.

I think In-Fluence is encountering the same problem?


looks like this is from the MIDI clock messages the Kontrol49 constantly sends. Maybe we should skip all realtime messages, other messages than CC,Notes,PB - completely?

I’ll take care of the flood of error messages internally, avoid that Renoise freezes in such cases…

Done, please re-download.

Duplex has been updated with a small fix so only recognized messages pass through…

Cheers for the unparalleled ‘3-star Michelin service’ chaps!! All good now.

One other thing, It still says to press Pad 16 to turn off padblink on the K49 - it’s Pad 12 ;)

Sorry if I’m a bit out of the loop on this, but was my sysex hack (or something similar) ever implemented? If not, could it be?

I’ve got a bug report:

In Duplex 0.92 + Renoise 2.6b6, the nanoKontrol does not show up in the device list. I went and downloaded the old nanoKontrol user scripts from a previous forum post and was able to install them by replacing the lua, bmp and xml files in the Devices/nanoKontrol folder, and they work just fine. So it looks like something is up with the bundled one. Is there any debug info that I provide?

I’ve also got a question:
I’d like to use 2 launchpads simultaneously. Is the best way to accomplish this, to copy the Launchpad device folder and change the name of the files, folder and namespaces+display names etc… form Launchpad to something like Launchpad2?

Thanks! The tooltips are great.

Strange, it’s working here. You used which previous version?

Simply clone a particular configuration entry in Launchpad.lua and assign a new device display-name (for example, you might call the new configuration Launchpad_Two) and then reload the tools.
It should appear as a new entry in the device list, that you can assign different settings to.

Thanks danoise, that method worked perfectly, and you taught me something about Duplex. That could have totally been answered with a big RTFM, so I appreciate the hand-holding explanation =D

Ehhrhm…what manual?

No, I honestly didn’t understand it, so I did not add it. But let me try - the idea was to create some presets for a hardware synth via sysex - a kind of librarian feature? I’m not convinced that Duplex is the best/most practical interface for this, but correct me if I’m wrong in the following assumptions:

  • The sysex dumps are static, meaning that Duplex is limited to initiating sysex dumps that doesn’t really have any need for interactive controls (e.g. sliders).
  • The user-interface does not need to be representative of the actual hardware - they could might as well be “fantasy interfaces”.

If have have understood all of this correctly, then isn’t it better to create a dedicated librarian software/tool for all of this?
I’m thinking something along the lines of a dialog box with named presets, a “record” and an “export” button?

Edit: on the other hand, some kind of sysex will be needed, if we are going to support devices that need an initial sysex command - this is the case with the padcontrol and kaosspad, AFAIK.

I think this is an upgrade problem on windows (overwrite existing older duplex XRNX bundles). We’ve renamed the Nano Kontrol files and folder from “nanoKontrol” to nanoKONTROL. The Duplex controller file autoloading mechanism is case sensitive, but upgrading an old XRNX duplex bundle will keep the old “nanoKontrol” folder intact on windows: people have old “nanoKontrol” folders with “nanoKONTROL” files in it.

Could fix this by making the the autoload controller thing in duplex case insensitive, or in Renoise by completely trashing the old bundle (except the preferences.xml) before installing the new version.

Interesting, that would probably explain this as well:

I’m on OSX, but maybe the problem is the same? I have trouble working out the logic there, as OSX folders are overwritten wholesale when they are overwritten. Maybe Renoise is updating the Library files recursively, rather than with 1 swipe, but if that were the case then I’m not sure my problem would exist. Let me take a look at my file structure.