Duplex Beta Versions

Btw. I think it’s not too much “hacked” in the new StepSequencer application code … maybe a little bit, but I didn’t changed the old code. I only added some workarounds to get the new grid mode working. :slight_smile:

Hey, I’m a new renoise user (I love it), and want to find a controller for it to get things even faster.

I was offered trade a monome 256, but I couldn’t be sure if I can get Duplex to work with 256 version.

Or maybe other solutions that I’m not aware of?

I don’t know if I can get anybody to help me with creating a custom tool.

So I would like to know if there’s anybody using 256 with renoise also :slight_smile:

Ta-daa. A brand new version of Duplex (v1.01) for your consumption!

Check the first post in this topic for download:


It fixes a number of issues, brings new features (perhaps most importantly, high-res automation recording is now standard).

And it also represents my initiative to reduce the codebase by transitioning to cLib/xLib libraries where possible - this release represents the first step in that direction.

I have tested this as much as I could, but I would really appreciate if you could lend me a hand here.

The list ofknown issueshas shrunk to just 2. But I’m sure there are more lurking…

So basically - if you own one of the supported controllers, run some of the configurations - play around, and see if something breaks.

Also, there is some much improved documentation for the applications and Duplex itself.

Once we find that the release is solid, I’ll strip the debug information and release it on the tool page. Until then…


Changelog for this release:


  • Added: High-res automation recording for Mixer, Effect, XYPad and Repeater apps.

But does this mean, Renoise will neverget proper highres recording natively? :wacko:

And something like:

  1. Renoise could get the possibility to record any slider, not only for right mouse button. So in context menu of any slider “enable recording” and “disable recording”, plus an additional “record automation” button next to the record button, which disables all recording. So you could also record any meta signals. So from the API, you would simply enable recording for a slider and let Renoise do the automation recording.

coll, it might finally be time to get my head round this… prospective gear I have includes:

Korg PadKontrol


Novation Remote SL

Stanton SCS3 (WEIRD Ribbon thing!)

@ffx: you’re referring to the tuned shortcuts, I guess?

There also is an “endless feedback” problem in Renoise’s current implementation of observing VST parameters. While writing automation, the automation values are sent back to the vst, so the vst parameter observer will trigger again, which writes again automation etc. etc. Stuck in an endless loop. This should be prevented internally. Also vst plugins may round the value, so the sent in value and sent back value will differ. It is not possible to filter this out by checking for same values. I would define the following problems/thoughts about it, that should be fixed (IMO):

Oh, I remember that we talked about this. The “xAutomation” approach I’m using now is simpler than it used to be - I ditched the “latch mode”, it now has only two modes: “punch in” and “interleave”.

But with plugins, indeed that particular thing (rounding) might still pose a problem, I dunno… I say, let’s investigate :slight_smile:

coll, it might finally be time to get my head round this… prospective gear I have includes:

Korg PadKontrol


Novation Remote SL

Stanton SCS3 (WEIRD Ribbon thing!)

Launchpad is definitely plug and play. It has a lot of “configurations” ready to go.

And it would be awesome to (finally) get the PadKontrol into the family. I’ll revisit this thread from 2014:


As for the Stanton and Remote SL, they were missing from thelist of controllers. I’m sure we can get something running. But I own a Novation Remote myself, the SL-MKII model, and it’s great quality (hardware) but the LED feedback via Automap/MIDI is unfortunately not 100% working. I even contacted Novation to let them know of the issue.

So I’m pretty sure that the first model fares equally well. Which means, great because you’ll most likely be able to record precise automation, but anything beyond that (bi-directional communication) is a bit unknown.

@ffx: why the smiley, it seems you are genuinely concerned?

You should know that MIDI notifiers are fired in the “realtime thread” and picked up by lua almost immediately. Of course, we are talking computers so nothing is ever completely realtime, but it’s pretty damn close.

We need to produce some measurements before we can talk about “accurate” timing, no?

Also, I was not aware that OSX should behave any different. Could you check that this is still the case? Like I mentioned, the implementation has changed.

I have a Mac too, so I can test this from here as well. But it’s a hassle because I would need to reinstall a bunch of software.

Well, if you’re not feeling like testing this thing, you can still throw me a bone or two.

Remember, it’s a different implementation now. I am aware that the previous version could screw up high-LPB automation - my bad.

Also, I was not aware of any difference between OSX and Windows. This is obviously important to know, as the API is supposed to work similarly across platforms.

Sounds like I need to boot my Mac up and run some tests after all.

Now, for the bone: can you give me an example of a plugin where you experience problems with rounding/feedback? Preferably a cross-platform, non-commercial one.

If I’m lucky I might be able to make some parameter feedback ** cue ugly teeth smiley :badteeth:**

Another beta , v1.02. Get it here


- Core: replace OscClient with xOscClient
- Added: Detect Renoise OSC server on startup
- Added: Tool options dialog + clean up menu
- StepSequencer: Changed default options (always write, enable preview and note names)
- Updated documentation

Detecting OSC on startup is a good one: you’ll be a lot less likely to wonder why some features (Keyboard, forwarded MIDI messages) aren’t doing anything.

And a dedicated tool options dialog means that I could clean up the tool menu a bit.

Also, I found myself wondering why the newly upgraded step-sequencer didn’t write any notes - d’oh!

So those default options are now more intuitive - you can always configure it differently later on.

Yet another release, v1.03

Guess this the first time that Duplex got two releases in one day :slight_smile:

Also, the OSC server detection is now waiting a bit longer before it concludes that no server is available.

Don’t want the fix for a nuisance to become a nuisance in itself…


Core: Improve performance by using table-based lookups where possible
Added: MMC transport control is now optional, can be enabled/disabled via options
Added: pitch-bend as an additional input method for the UISlider component 
 (this also fixes issue with Mackie Control: https://github.com/renoise/xrnx/issues/50)
Fixed: StepSequencer: error when pressing button in out-of-bounds area

A new beta has arrived. 1.04,

This release contains improvements to several applications.
Not manyopen issuesare left, so if anything is broken please let me know.

- Added: StepSequencer - allow transposing while playing / holding down button
- Added: StepSequencer - cycle layout mapping (implemented in Launchpad config)
- Added: StepSequencer - more finegrained control of track/line follow behavior
- Added: Keyboard - grid display options : key/sample highlighting + note labelling
- Added: Launchpad configuration - "Drumpads" (four instances of Keyboard app.)
- Added: Matrix - on-the-fly pattern switching tries to 'keeps the beat'
- Fixed: StepSequencer - could throw error when navigating to non-selected pattern
- Fixed: StepSequencer - force-remove all observables, some performance tweaks 
- Fixed: Keyboard - HarmonicWrapped layout + scales no longer shows duplicate notes
- Fixed: Navigator - more stable when switching between non-/selected patterns
- Changed: don't run OSC server test by default. Can still be run from options
- Updated Mlrx configuration for Launchpad (now includes all mappings)
- Deprecated UIKeyPressure, UIPitchBend (using UISlider instead)

Here’s an example of how the new keyboard options work:

I would suggest that automation reading of a parameter is completely disabled while recording. So like an “arming” mechanism. Even on overwrite, the already existing data should not be read. Imagine a motorized fader, how annoying overwrite works then. Such a mechanism is missing Completly, AFAIK.

I happen to have a BCF with motorized faders. Well aware of the issue that they are not always set to the right value.

Luckily, such feedback detection/prevention is built in to Duplex when controlling hardware.

Now, I need to figure out under which circumstances this automation issue could arise. Then, a similar solution should be possible.

Looking forward to testing it thanks. Just one idea , could the vertical triggers on the right be mapped to the velocity of the pads?

Also if you have Voicerunner installed, could you map one of the keys to sort the notes into unique columns, or after a timeout?

Just one idea , could the vertical triggers on the right be mapped to the velocity of the pads?

OK, I thought you had an idea by leaving them unassigned. So I figured I wouldn’t totally screw around with the configuration.

I only fixed the invalid notes and added the labels to make those groupsmore obvious.

But sure, it’s possible. I can even think of two ways: one, where they all share that strip for controlling their velocity, and another approach where the strip would be mapped to control the keyboard velocity in Renoise (you know, the little button in the topmost toolbar that controls the velocity of the QWERTY) - because, Keyboard can use this to control the volume level level as well. I think both are valid, just a matter of preference.

As for Voice-runner, last time I checked, all the important buttons were MIDI mappable :smiley:

So you just need to enable “pass unhandled messages” in Duplex, then you should be able to assign it to the Launchpad…

All good - I just wired up the velocity as you said. When you say they all share, did you mean all the pad banks?

Just noticed something in the Keyboard config with that same bank of buttons that they no longer change the harmonic key. Throws this error:

Warning: voice manager received a process without a configuration userdata: 0x0x103e9f64 (BrowserProcess object)

Cheers :slight_smile:

Thanks for the update. Tried to use the XY pad (issue #55) with TouchOSC, but something has broken I think. Renoise throws the following error message when you want to control anything via TouchOSC:

'C:\Users\...\AppData\Roaming\Renoise\V3.1.0\Scripts\Tools\com.renoise.Duplex.xrnx\main.lua' failed in one of its notifiers.
The notifier will be disabled to prevent further errors.

Please contact the author (danoise) for assistance...

no static 'pack_args' in class 'cLib'
stack traceback:
  [C]: ?
  .\Duplex/ControlMap.lua:701: in function 'match_osc_param'
  .\Duplex/ControlMap.lua:821: in function 'get_osc_params'
  .\Duplex/OscDevice.lua:222: in function 'receive_osc_message'
  .\Duplex/OscDevice.lua:201: in function <.\Duplex/OscDevice.lua:160>

Thanks for reporting. it was indeed related to the recent update. So I’ve fixed the fix :slight_smile:

Makes me wish it was easier to grab Duplex from github, but here is my current development version:

7411 com.renoise.Duplex.v1.04.1.API5.xrnx

Btw: if you’re running that particular TouchOSC configuration you might want to disable the tilt sensor. For some reason, it’s flooding that layout, making the XY pad very sluggish.