X-Touch (+Extender) MIDI Remote Script (MCU mode)

The problem is with all the different MCU clones out there and which buttons exist, and what they’re labelled as. You’d almost have to have a secondary file that contains the different device mappings via consts and then load those into the main script.

I’m just so annoyed at the ‘onchange’ bug issue currently, I had some spare time this weekend and I wanted to work on some bits myself but not going to waste my time until it’s fixed.

Steinberg need to add the ‘selected track’ style controls too, as the only way of utilising them is to build a script via the API and then add a mapping page via the surface editor, but then that makes screen/lamp feedback hard as it’s an odd ‘hybrid’ approach, and I have little faith in it not breaking either.

Excellent work though, enjoyed looking through the code and how you approached this project - very interesting. I’ve not used typescript before, only pure JS - but tempted to learn it as I do a lot of php/mysql dev nowadays.

1 Like

Tremendous work on this script, so professional. I just got an X-Touch today and had your script at the ready, been playing around trying it all out - simple example which impressed me: I add a compressor to a track, click the Encoder Plugin button, click the Flip button and I’m immediately controlling the compressor with the faders - amazing! Thank you!!! (I bought you a coffee, I think!)

1 Like

I have been following along and debating on getting the x touch from all this great work and progress! The challenge is I just purchased the Qcon Pro G2, and the only way to get the autobank/select track to work in cubase and it show correctly in the mixer, is through the midi remote, but I’m not a programmer

here is another thread about the best control surface for Cubase 12, and with this script you have created, it seems the x touch is it.

Is putting in a request and support for the qcon pro g2 to have a custom script built something that you can do? (it seems even if I wanted to order the x touch now, I still need cubase to do the next update after 12.0.60) QCon Pro G2 – Icon Pro Audio

Or from your experience, do you think x touch is the way to go instead?

1 Like

@bluesound Thanks for reaching out! I took a look at the Qcon Pro G2 and it seems to be widely equivalent to the X-Touch, at least feature-wise. When getting an X-Touch, you would mostly be trading angled (=readable) scribble strips against colored, but flat (=hard-to-read) ones. Having used the X-Touch with colored scribble strips for a while, I wouldn’t want to miss them anymore, but given you already own the Qcon Pro G2, getting an X-Touch would feel a bit redundant.

I’m open to the idea of supporting the Qcon Pro G2, original MCU, or any other (close-to) full-featured MCU-speaking device, if someone agrees to test with it. Let me think about this for a few more days and maybe draft something. @bluesound Can you try to manually add an X-Touch device surface (“+” button in the MIDI Remote pane) with my script and your Qcon Pro G2’s ports and let me know what works and what doesn’t?

That sounds like a reasonable thing to do (maybe even one file per “flavor”, sharing a common interface). I’m thinking about introducing “flavors” in the config section with the default flavor: "x-touch", but others available. A flavor would then apply to all “main” and “extender” devices, change the script’s vendor/device name, surface layout, and tweak some features. Consequently, the project name should be cubase-mcu-midiremote then, and the documentation would need a little rewrite. Nothing too fancy thoug, I think – it should even work in a feature release.

Thank you! Some say (xkcd?) the quality of code can be measured in WTFs/minute. Seems that I reached a decent rate here? :crazy_face:


@bjoluc Thank you for the fast response and I agree to test and work through this together - just guide me through what you need to know/help me when I get lost lol

I followed the setup instructions here:

-auto bank/track select in cubase, auto updates on the qcon, finally works - epic!
-The faders, pan, mute, solo, record enable, track select work perfectly
-when i press the pan button, it enables the track monitor
-bank buttons right and left work correctly
-move the bank select one increment at a time works correctly
-stop, play, record, fast forward, rewind, loop works correctly
-Dial works as expected

-the other buttons look to do random different things however the lights work correctly on everything - it seems that some buttons have different toggle and other functions that are affecting how they light up, and they are randomly pressing different buttons, which is to be expected for those

I have attached pictures of the cubase overlay that comes with the qcon so we can figure out a streamlined workflow with the labels on the buttons along with the success you have had with workflow and buttons with the x touch.

-are there any ideas for workflow that you would have in your approach to the configuration of the buttons? (with the layout of the overlay)
-could this be configured to control send levels, on and off of sends
-configure to control each insert, on and off sends
-what buttons or combinations for opening edit channel, edit vst instrument, each individual mixer,
-should we start another separate thread with the qcon pro g2 cubase 12 midi remote script

Attached is a script for editing that I built before finding your thread, I have a few basic workflow ideas but couldn’t get much of anything else to work lol

BSC_Qcon Pro G2 midi remote script.zip (5.1 KB)


Hello @bjoluc ,
I am very happy to try your great work!

Before proceeding I would like to ask you if it is possible to set the IN/OUT connections of the X-Touch (Mackie Control settings) to “not connected”, instead of deleting the Mackie Control Device.

This way I avoid deleting the MC settings… although I will be amazed by your great work!

Thanks @Danix78!

Yes, absolutely! I’m not quite sure why I settled on the more radical approach in the setup instructions – I think I wanted to make sure it’s unmistakable. Maybe I should mention the “not connected” option in the setup instructions too.

Nice work, @bjoluc!

Every time I launch Cubase, I have to re-add the X-Touch device - it’s not auto detected,

I suspect that perhaps the midi device name doesnt match whats in the script…? If so, what would be the best way to update it? Possibly PortPair.ts?

EDIT: I found this line in your output JS file:

    if (this.devices.length === 1) {
        driver2.makeDetectionUnit().detectPortPair(this.devices[0].ports.input, this.devices[0].ports.output).expectInputNameEquals("X-Touch").expectOutputNameEquals("X-Touch");

My device is named something like “X-TOUCH INT”…would it be “safe” to mod that line as such?

Would that cause any issues when I add an extender?

EDIT 2: seem to have answered my own question (use “X-Touch INT”) in the expectNNNN calls. Haven;t tried an extender yet to see how it behaves.

1 Like

It would be great if the plugin control button kept the same functionality as when it is in native mackie control, since it recognizes all the controls of most plugins, don’t you think?

I have the same issue: When I start Cubase, usually the X-Touch Midi Remote is usually gone, but sometimes just the ports arenb’t assigned anymore (I have a XTOUCH & Extender). I have to deactivate and re-activate the script in order to be able to assign the Midi ports again.
Any chance this could be fixed?

I havent solved that riddle yet - i’ve modified the code a little to my liking, and experimented with using the actual port names in the port initialisation section, but haven’t got it right yet.

Would love to here from the OP if there is a way to make this happen so we don’t have to reload the script to use the extender…

paging @bjoluc

Thanks for bringing this up @swinginguitar – on my Windows machine, I only have X-Touch and MIDIIN2 (X-Touch)/MIDIOUT2 (X-Touch), but I remember having seen X-Touch INT and X-Touch EXT somewhere in the past too. I’ll add X-Touch INT too, so both variants are detected.

I remember I couldn’t figure out how to make auto port detection work with multiple port pairs at all with Cubase 12.0.52, so I conditionally implemented port detection when only one device is configured. Trying again now with an X-Touch + Extender, it seems to work with two devices too – both with CB 12.0.52 and 12.0.60 :tipping_hand_man: Once released, this might also work around the problems you are experiencing with an extender setup @mat. Exciting!

@swinginguitar Wondering about the MIDI port name of your extender. Is it X-Touch-Ext like it is for me? Also, is your X-Touch port name X-Touch INT or X-TOUCH INT?

EDIT: Sadly, Cubase chokes on the same script changing the number of auto-detected port pairs over time :exploding_head: Once a device surface has been created with auto-detected ports for a single-device setup, changing the script to use multiple devices updates the device surface in Cubase to show two devices, but keeps instantiating it with only two ports. So unless this gets fixed, adding auto port detection for two devices could mean a lot of trouble for script users. Sorry :cry:
@Jochen_Trappe I don’t know the MIDI Remote internals, so I cannot explain this behavior – is it something you can think of a potential reason for, and maybe have a fix in mind? I’m happy to help with whatever information (repro steps etc.) might be needed.

1 Like

On my system, the main has “X-Touch INT” and “X-Touch Ext” (I’m using the INT via USB)

The extender is “X-Touch-Ext X_TOUCH_INT”

When you say that it “chokes over time” do you mean it works for a while but then doesn’t in future loads?

Do you mind sharing the line of code where you are specifying multiple ports? IOW where the call to makeDetctionUnit() is made

I experimented with .expectINputNameEquals et seq using both units in the array but never got anything to work

1 Like

Funky :sweat_smile:

Exactly: I load the script the first time with devices: ["main"] and it autodetects the X-Touch ports. Then I reload the script with devices: ["extender", "main"]. No matter what I try (reconnecting devices, deleting the surface, deleting the script, disabling and enabling the script, restarting Cubase), a script instance is automatically activated with only the X-Touch ports, i.e. only two ports instead of the four specified by the script, but still showing the extended device surface. The other way around, if I load devices: ["extender", "main"] first in a project, auto detection seems to work, but when I switch to devices: ["main"] afterwards, the correct device surface is created but with four instead of two ports connected. :man_shrugging:

The single-port-pair detection is working fine for me with multiple calls to expectInputNameEquals/expectOutputNameEquals:

const detectionUnit = driver.makeDetectionUnit();
  .detectPortPair(mainPorts.input, mainPorts.output)
  .expectInputNameEquals("X-Touch INT")
  .expectOutputNameEquals("X-Touch INT")

which displays as “X-Touch INT OR X-Touch” in the script console.
When I extend this by

  .detectPortPair(extenderPorts.input, extenderPorts.output)

in the X-Touch + Extender case, it displays as “X-Touch INT OR X-Touch | X-Touch-Ext”, but suffers from the above symptoms :confused:

So I will likely just add the X-Touch INT port names to the single-device setup for now…

Hi guys,

I am trying to make this work properly, but I have not colored strips. Am I doing something wrong? I’ve followed the steps and it works as good as the old MCU driver, but the color is missing.


Hi @Antonio_Escobar,
it sounds like your X-Touch is running on an old firmware version. Could you double-check that the latest firmware version is installed?

Hey @bluesound,
thanks for testing with the iCON QCon Pro G2. I started a draft Pull Request (#7) over at GitHub for working on a decent QCon Pro G2 support (I enhanced the internal structure and build logic a bit s.t. scripts for multiple devices with separate surfaces can be built and behringer_xtouch.js is just one of them, just like icon_qcon-pro-g2.js will be). If you don’t mind, can you sign up there so we can discuss things directly in the PR?

Can you comment on this discrepancy (for my understanding):

the version of the script i have accesses the ports via an array - this.devices[0]

the snippet you posted most recently uses a different rout - mainPorts.input / extenderPorts.int

is there any nuanced different in these two approaches?

Not really, I just rewrote the names in the snippet to be more meaningful than indices. If you have your extender on the left side, it is devices[0] and your X-Touch is devices[1] :slightly_smiling_face:

Hey all, I’m just learning about this awesome script and have a question. Something I’m needing is some kind of grouping / VCA support for my massive film score mixing jobs. I’d like to group different stem output busses (usually about 18-24_ so I can do a real time mix on a console in front of me with 8, or desk space allowing, maybe 16 faders.

I used to be able accomplish this via the Console 1 Fader with their Layers mode - but they removed that functionality in an update last year.

Is there something similar I could do with this script? Again, I want VCA-like behavior rather than changing my output bus stem configuration.