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

Firs of all Thanks for spending your time on all of this!!!
I would Love to USE the SENDS button for this but in my cas it doesn’t work!
Maybe because I’m with an old script…?

1 Like

That’s weird; does the FLIP button work with other encoder assignments?

FLIP button does Nothing. SENDS button has a strange behaviour… makes all color strib the same color of the channel and theres no way to let it again on normal mode. I need to reopen the project.

Ok, that’s clearly not how the script works out of the box – I’m going to quote @swinginguitar on how to remove custom mappings:

Also, please update the script to the latest version – all v1.x releases remain compatible (and tested) with CB versions down to 12.0.52 too, so no worries about that.

As to

that’s the default behavior – you can change it in the latest script version by setting displayColorMode to "channels" in the config section (where you’ll also find details on the individual modes) :+1:

Hi @Ronnieg, the script in this thread is for the full-size X-Touch only – at least that’s what it was made for. That being said, you may succeed using it with the single-fader version too by manually adding a device surface and assigning the ports – note that it doesn’t visually match your single-fader X-Touch then. I’ve been told that auto banking works with the single-fader version too. If you need more advice, I hope @Darren.Jones is not mad at me for refering to him :upside_down_face:

Hi @isdjan and @David_781,

I’ve never been able to track this down, especially since I can’t reliably reproduce. It doesn’t seem to depend on the installation method (script file or Cubase-generated archive) at least. Is anyone of you using an extender too, i.e. do you manually add the device surface or is it auto-detected at any time?

I wish I could answer this. I see this too occasionally – script-wise, I don’t know what could be causing it :confused: All port names are unique and the order in which I create ports is always the same.

Hello my friend, how are you searching for the ports? Using contains, equals?

Oh, tech support is here, hi :grin: Using Equals for the X-Touch script (https://github.com/bjoluc/cubase-mcu-midiremote/blob/100a61ee183f39f22dd52982164a946338a000b3/src/device-configs/behringer_xtouch.ts#L55-L59) – currently with two alternative options, but I’ve already been told of this issue before introducing the second pair of port names.

1 Like

You have two pairs of midi ports? If so, then unfortunately I couldn’t find either a way to do this, and I did open a thread about this issue:


1 Like

Hi @chupacabras,

Hmm, is the extender in MCU mode and its firmware up-to-date? Hearing this for the first time :confused:

Wait, reading the script
detectionPortPair .expectInputNameEquals("X-Touch") .expectOutputNameEquals("X-Touch") .expectInputNameEquals("X-Touch INT") .expectOutputNameEquals("X-Touch INT");

I think you could just have the contains(“X-Touch”). Not sure what the multiple equals do, I mean I think they should do a logical AND rather than an OR, but I really don’t know. Doesn’t the contains work as expected?

It would, but extenders also start with X-Touch :see_no_evil: Currently, I’m only adding port name assertions when there’s only one port pair configured (to avoid running into your issue).

Cubase displays them with an “or” and I checked that either of them are detected. I would’ve been the first to blame port detection issues on this, but they did also happen before adding the second port pair :thinking:

Not sure if this would be of any help, but while building for Novation SL MK3, I did initially use the port names with the equals, to no avail. Then I did this:

deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameContains('Novation SL MkIII')
    .expectOutputNameContains('Novation SL MkIII')

and it started working. Just as a test, I replaced the second contains with something that’s not there, and no detection was done. This is why I assumed that we have an AND in these statements.

1 Like

I have no extender. It worked without a problem for a while but stopped months ago. Of course I reinstalled/updated scripts but that didnt change anything.It will just open with some saved projects where I manually added the device at some point. It doesnt with a fresh empty project. Indeed I just checked with a new empty project and opened the midi remote script console. It seems to load the script, but it doesnt add the surface!?..

1 Like

I am not mad!

Auto-banking works fine for me on the X-Touch one, I just changed the name of the MIDI device in the script to the X-Touch One port name and then ‘it just worked’. There is some re-mapping that I also did of some of the buttons (not all of them worked), but I did it quite a while ago on an older version of the script… and didn’t make any notes.

I will re-do it when I get a chance, and document my changes. Can’t even remember what didn’t work now! But it was so much better than MCU mode as the auto-bank changes make it work like a faderport version 1, which was what I always wanted.

1 Like

Hello Bjoluc,
Thanks again for the great script for the X-touch . I’m having a little problem with the pan encoders at the moment.
Since Cubase 13, you have to rotate for a long time until you find the right pan setting.

This behavior was not present in Cubase 12 (much shorter)
Can you set this PAN setting again like 12?

greetings Chriss

1 Like

Hi @bjoluc :slight_smile: ,

i think this is kind of preparing encoders for a better scaling feature, but it seems Steinberg could not complete it in time. What happens if you longer turn the encoders (like turning them several times) ? I am sure they will still working. If so, then i am pretty sure with my assumption. (Relative) Encoders that support MCU style behaviour, can support more steps then only 0-127, like 0-4096. It just seems it is not finished properly. Same goes for the post above mine. It would also explain, why they are less sensitive now.

1 Like

I’ve been experimenting with the port detection again and I bet I didn’t test this by creating new projects back when adding the alternative port name pair (“X-Touch Int”). It seems the detection of a port pair with multiple options (“X-Touch OR X-Touch Int”, as per @David_781’s screenshot above) doesn’t work (I didn’t bother to test if it worked up to a specific CB version). Thanks for pointing out the obvious @m.c! :man_facepalming:

Revising my port name detection decisions, I think the best solution for now is to check that input and output port names equal “X-Touch” (given the majority of standalone users seems to have “X-Touch” port names). This will break (if not already broken) the auto detection of ports named “X-Touch INT” (sorry @swinginguitar), but there’s no way around it: Checking for startsWith instead of equals wouldn’t work either because when there’s “X-Touch INT”, there’s also “X-Touch EXT” and they both start with “X-Touch” so there’s no unique match and Cubase wouldn’t auto-detect ports anyway. SysEx ID detection would be awesome, but is not supported by the X-Touches.

I’ll be releasing a patch for the port detection soon – thanks @isdjan and @David_781 for flagging this!

1 Like


This is a known and already reported issue. Thank you.

It’s not an issue of this given script, but of all scripts using the Inc./Dec. encoders.