I’m starting with Renoise, and wish to make my X-Touch work with it. There is already support for (most of the) MCU protocol in Duplex, but it’s really not to my taste. Also, it seems the full potential of the X-Touch (like color scribble strips) can only be unlocked when using their proprietary Xctl protocol. So, I’m planning on working to implement Xctl in Renoise. It seems fairly simple, except I’m discovering the Renoise API and haven’t used Lua in, hm, over a decade (that’s not the issue I’ll get into it fast enough).
After a few quick experiments in the terminal, I could configure a scribble strip properly, so I trust this doc is solid.
Also, I’m planning to tailor the overlay to my very needs, so if anyone is interested, let’s discuss what overlay(s) to create!
Apart from that, I’m not sure whether it’s better to make a new device for Duplex or code it from scratch. It seems Duplex doesn’t handle screens or VU leds yet? Also I couldn’t find a proper tutorial to create a new Duplex device, nor could I find a proper starting point in the Duplex docs (Maybe it’s already there, I can easily overlook things when I’m browsing, especially the obvious. It happens.)
Nah, you’re right. The deeper innards of Duplex is not very well documented (except perhaps in the code itself).
So I would ignore Duplex for now, and write a simple tool that works.
The reason that there is no screen support in Duplex is that I’ve struggled to come up with a sufficiently “generic” solution. Unlike with MIDI itself, there are no standards that define what should or shouldn’t be possible. So such a thing would most likely end up being a device-specific feature anyway.
It’s going surprisingly well. Lua is a bit quirky in unexpected places, but overall it’s still a very decent language and the Renoise API is just fluffy for what I’ve seen so far.
I agree defining a proper abstraction for a screen is a few orders of magnitude more mind-boggling than it’s worth in the end, unless we settle on a terribly minimal feature set (and still…). Maybe over time I’ll be able to look under the hood and try and bring some help with Duplex.
I now have a class XTouch that maps all the X-Touch controls in a renoise Document so everything can be observed the renoise way and also provides a simple event system to handle explicitly events such as press/release (a button), move (a fader), etc. In addition, there’s a simplistic system to host various programs (implemented as lua files in a Programs/ subdirectory) and switch between them directly on the X-Touch. As of now, only MIDI is supported. I’ll need to do some packet sniffing to understand the ethernet protocol when I have nothing else to do toimplement the probably incomparably faster ethernet link.
It also includes a dirty—but working—hack to be able to attach a VU meter to the current level of a track.
It is heavily undocumented at the moment, but if anyone’s interested I can release it as a library. Otherwise it stays in the future X-Touch tool which I plan to release when I’m done implementing the Mixer interface program, at least enough to control the mixer decently. There is potential for controlling most of Renoise on this piece of gear, even though pattern editing on the X-Touch will probably not be desirable.
I’m happy enough coding X-Touch support for my own needs but it’d be awesome to hear anyone else interested in this Or maybe this can help inspire hacking other control surfaces…
My X-touch one arrived. The first impression is very good, especially for its price.
PS.
I’m working on a ‘universal midi controller’ tool for it, dubbed “Simplex”. Kind of like if x-rules and duplex had a baby. Basic concept: 1) Press “add event”, 2) Press learn, 3) Move knob, 4) Filter for midi code is added, 5) Enter sandbox code for the event … There will be one init function, and a sandbox environment for input and output section respectively. The init function can set up song notifiers needed, and helper functions like lcd output. And in the environment(s) you can store things like “scene = 2” (used for function buttons), for being able to check these values in the event codes.
I’m working on a ‘universal midi controller’ tool for it, dubbed “Simplex”. Kind of like if x-rules and duplex had a baby. Basic concept: 1) Press “add event”, 2) Press learn, 3) Move knob, 4) Filter for midi code is added, 5) Enter sandbox code for the event … There will be one init function, and a sandbox environment for input and output section respectively. The init function can set up song notifiers needed, and helper functions like lcd output. And in the environment(s) you can store things like “scene = 2” (used for function buttons), for being able to check these values in the event codes.
Count me in. My attempts at Duplexing so far have been less than stellar.
After failing miserably at getting bi-directional communication with my akai midimix working the way i wanted, I ended up doing the whole thing in puredata: https://github.com/Gimmeapill/midimix_button_control
That works but is a bit clunky, so anything in between would be welcome.
So, it’s taken me a bit longer than I wanted to get there but I’ve got most every feature of the X-Touch supported now.
The code is hosted at https://github.com/bl0b/renoise-xtouch-xctl.xrnx but I have yet to write a Readme and to release a packaged xrnx. Gotta fix a bug or two that remain before so.
Follows a quick description of what I have so far.
The Renoise views are mapped to the buttons below the LCD screen.
The ENCODER ASSIGN section (buttons on the top) switches between pages on the X-Touch. There are two defined at the moment: the mix view and the device chain view.
The mix view is almost complete for the channels, including the FLIP button to switch between pre and post, but not including the REC button. Most buttons on the right are still unaffected. Transport buttons and jog wheel work and can scroll through the entire song. The track name and track color are displayed on the X-Touch.
The device chain view shows one DSP device per channel on the X-Touch for the currently selected track. The encoder selects the parameter that can be edited with the fader. A click on the encoder will “enter” the device and display/edit one parameter on each X-Touch channel. The device and parameter names are displayed on the X-Touch.
In addition, it is possible to switch between different “programs” on the X-Touch, even though for now only the Mixer program exists. For more specific and different uses of the controller to be imagined later
Edit: Forgot to mention that the X-Touch must be configured in XCtl mode over MIDI.
I can’t believe my luck. Just downloaded Renoise 3.2 and was wondering why my X Touch wouldn’t work. And then I find this. But how do I install this bloody thing?
As a workaround, try and open the dialog from the tool menu and configure the MIDI ports, then reload the tool (or use Reload all tools from the tool menu). Hopefully it’ll behave after that. I’ll try and fix that this week-end.
I haven’t installed 3.2 yet, so I don’t know if it’s entirely compatible yet.
There is one more annoying bug that happens on the device view (PLUG-IN button in the ENCODER ASSIGN section), where the faders aren’t unassigned properly when you try and move the X-Touch “window” left or right. So, for now, don’t touch the faders or don’t move the window (or rather, don’t use the device view yet…).
I can package the xrnx when these two issues are resolved.
Then it’ll be a much nicer matter of “this function is missing” and “I want this button to do this”.
I am looking for a driver for my Behringer Motör 49 (9 motor faders, MCU pro protocol). Maybe I could base a driver on @joule’s or @Raul’s work?
Btw. in Bitwig, the standard MCU pro driver/javascript seems to work great with this device, there is a mixer and a dsp control mode. Maybe I could have a look into the javascript then:
You should take a look at the Duplex tool for MCU device support. You may find proper or almost-there support for the Motor 9.
I had to resort to the XCtl mode for the X-Touch because the color screens aren’t a part of the MCU protocol.
I’ll get into it fast enough).
Or maybe this can help inspire hacking other control surfaces… 
