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

Cubase
,
469

Well, I guess it’s time for a quick update and sign of life from me! :waving_hand: I’ve relocated to Hamburg last year and am working full-time since then. I haven’t had much spare time for open-source projects in the past year. I also don’t find the time to reply to most messages that are reaching me, but I am receiving and reading notifications and would definitely step in in case there’s anything urgent that I can fix in the scripts. Unfortunately, as it seems, the vast majority of deal-breaking issues are out of my control as a MR script author. If there are any known fixes, or Steinberg’s support mentions actionable items, please don’t hesitate to let me know :slightly_smiling_face:

Re new script features: I believe there’s not too much I can add or improve with the current MIDI Remote API. That being said, I am thinking about taking some leave later this year to dedicate to open source projects. If that happens, maybe I’ll be able to provide some small enhancements then. Anyway, I can’t do magic here, so don’t expect too much. Also, my goal with the project is to provide a stable alternative to Cubase’s Mackie Control integration that’s not too opinionated and works with the MR API, not against it. There’s always some trade-off between supporting individual workflows and keeping the script useful for everyone. Many features may also be doable from a technical standpoint, but would require a fair amount of hacking. I’d like to avoid overly complex or potentially unstable JS-heavy solutions for the sake of simplicity and maintainability here.

That’s all from me for now – have a great week, everyone!

TLDR: I’m not giving up the project, but I don’t find much time for it at the moment and I think it’s generally in a good shape. Contributions always welcome!

470

Hi and thanks for the update and of course for this great script in the first place :slight_smile:
There is one issue I currently have and Cubase 15 (on macOS), which I hope you can have a look into whenever you’ll find the time:
with C15 the script generally works fine but for some reason, the LCD on my Behringer X-Touch (and 2 extender) stay blank until I set a random track color. After that, the display works just fine for that track but all other tracks (with unchanged track colors) remain blank. Do you have any idea what is causing this?

Thanks!

471

Nothing more to say than thanks, thanks, thanks, you make an invaluable work and still try to support all of us.

Maybe all the big controller firm should think about giving you som reward in any way, and Steinberg/Yamaha has to hire you to make some really working controller script for their flagship software, that’s is one of the main failure it has.

Thanks again. cheers, Eriberto

472

Hello Bjoluc. It’s nice to have news about you. Hope your new job in Hamburg is great and interesting. I think that we all look forward that you will have time to dive again in the fantastic script you have already written, and to propose new enhancements !

Anyway i confirm the problems with new windows midi service. I had the same results (no more colors, issues with fader, and so on…) untill i uninstall Windows update (realised in october 2025). Then i installed the firmware 1.25 in the xtouch (with “SendSX” software it’s perfect). And your script works perfectly again !

473

So further to my uninstalling the Windows Updates that caused this problem, I set Windows Update to delay installing any updates for 5 weeks. I’d hoped that MS would have sorted out the problem by then but they haven’t. Windows 11 installed some new updates after a reboot without giving me any choice and the issue is back.

I’d saved a restore point in anticipation of this problem, but in the end, I just uninstalled the following updates:

Security Update for Microsoft Windows (KB5079473)

Feature Update for Windows 11 25H2 via Enablement Package (KB5054156)

And it’s working again. I suspect I only needed to uninstall KB5054156. I’ve now set my PC to delay another 5 weeks before attempting to update again. My PC is now back to version 24H2. I hope this info helps others with the same issue.

Of course, this can’t go on forever. I have raised it with the Windows MIDI Services team ([BUG]: Steinberg Midi Remote script for Behringer X-Touch no longer works · Issue #995 · microsoft/MIDI), but they’ll probably blame it on the script. The other option would be to update to 25H2 as normal, but then find some way of disabling the new Windows MIDI Services and reverting back to the legacy one. Has anyone tried this? If so, please share here. All the best, Paul

474

Hi All

Thanks for filing the bug on our Github repo. @ doctorlaz

Uninstalling the latest updates is going to just uninstall the bug fixes. The first release of the new MIDI stack when into PCs at the end of January. Each monthly release after that includes updates/bug fixes.

Not sure why you’d say that. I’ve been all over these forums helping people out, same with our Discord server, which is where the pinned posts in the forums here direct you to go for MIDI support.

Although that is a bit suspect, and something to keep in mind. The new MIDI stack is only in Windows 11 24h2, 25h2 and 26h1, and only since the end of January.

We didn’t start releasing the new stack until January, so that would be something very different.

The VDJ bug mentioned was caused by apps not allocating SysEx buffers before opening the ports. Virtual DJ fixed that in their app, and the workaround for that issue went into Windows starting last month. Most people will have it enabled by now if they have kept up with updates. I don’t think that’s the problem here.

Looking at the scripts, it seems the X-Touch has multiple MIDI ports, so, this could be just a naming issue where the wrong port is picked up. I’ve seen that with some NI devices where a MIDI port is picked up instead of the DAW port.

If you have a non-working setup, can you post a screenshot here of the studio setup in Cubase showing all X-Touch MIDI ports? I see names in the script, but not sure which ones to expect. This may be as simple as downloading the MIDI settings app and setting the device to use new-style names.

Pete
Microsoft

475

This is the most common reason I’ve seen when a script is not automatically recognized. :+1:
Inside the scripts we can find the detection units, in the case of X-Touch I see:

main: function(detectionPortPair) {
                return detectionPortPair.expectInputNameEquals("X-Touch").expectOutputNameEquals("X-Touch");
            }

I have no idea of what the real ports are, so it’s good that you’ve asked for the MIDI Ports Setup screenshot.

476

Yeah, that’s how I saw it too.

I mean, up until an early version of Cubase 13, the port names weren’t checked very strictly, which is why some scripts used to work if the controller was the only MIDI device. After the stricter name checking was implemented, they stopped working, leading to comments that Steinberg had supposedly broken something that was already working.

477

Hi Pete, thanks for taking this bug report seriously and commenting here.

Because it may well turn out to be something in the script - I just don’t know. Also, there’s an element of ‘just my luck if…’. Please don’t take it as a slight. Most of us here are musicians not programmers and we just want to get back to doing our music. I’m certainly grateful you are willing to address the issue.

Don’t take too much notice of that. It was posted by someone who wasn’t suffering from this problem.

We’re not always great at reporting the exact details you need to diagnose the problem. However, I can say with certainty that the issue is caused by the inclusion of Windows Midi Services included in KB5054156 (see my post above).

Unfortunately I can’t post a screenshot here, but I can tell you that the MIDI Port used for Midi Remote Control is called “X-Touch”, and the other MIDI port (used for plugging in additional controllers etc) comes up in Studio Setup as “MIDIIN2 (X-Touch)” and “MIDIOUT2 (X-Touch)”. I hope that helps. If I can perform any other tests that help with diagnosis, please let me know.

Note: It would be useful to know if anyone on this forum is successfully using an X-Touch with Bjoluc’s script on a recently updated Windows 11 PC (25H2) that includes the new MIDI stack. Please let us know.

All the best, Paul

478

Thanks Paul. Is that how they come up in a non-working system, or a working system? The script uses port names, and I’m assuming those are the non-working names.

On the Discord server, under #workarounds-and-instructions I explain how to change the port names to “new style” names. This is the key thing to unblocking most scripts. Windows MIDI / Audio

Pete
Microsoft

479

That’s how they come up in both working (Pre-new Windows Midi Services) and non-working (WMS) systems.

Here’s what I tried: Downloaded the Windows Midi SDK and changed the X-Touch Port names to the new style as instructed in the Discord Page. The new style names were X-Touch_INT and X-Touch_EXT. Bjoluc’s script seems to check for the new type names, so I tried it both unmodified, and also explicitly checking for ‘X-Touch_INT’.

In both cases I got exactly the same fault as before. The control surface partially works, but some of the scribble strips are blank or unlit, and when you exit the project, the X-Touch doesn’t reset like it should.

I don’t think this is down to port naming. It’s like only half the messages are getting through in both directions.

I hope this info is useful. The only workaround I have at the moment is to uninstall any update that contains the new MIDI stack. The system is unusable otherwise. However, that precludes me from getting any important security updates in the future. In the absence of a solution, is there any way I can make Cubase/the X-Touch default to the legacy Midi driver in 25H2?

Atb Paul.

480

@ doctorlaz
@ Psychlist1972

Hi doctorlaz,

your problem could actually be caused also by the script itself.

I’ve been working on my script for over three years now, and there are cases where I had to implement an artificial slowdown in the script to ensure that data exchange works properly.
I don’t consider this a bug of MIDI Remote. It’s just necessary to make sure everything runs smoothly in real time.

If the new MIDI stack is faster than the old one, it stands to reason that other older scripts might no longer run perfectly because those scripts would also need to have such an artificial slowdown.
I see, the error you described on the X-Touch looks like it could be caused by this.

Best regards,
Christian

481

Hi Christian, I have wondered about this, and Pete has mentioned cases where the new MIDI stack has been too fast for older drivers etc. in other forums.

However, Bjoluc’s script works on Apple computers, which presumably are just as fast.

It would be nice to know for sure. If that does turn out to be the case, then we really could do with a way of reverting to the older MIDI stack.

Paul

482

That may not be relevant. The overall speed of a computer and the way a specific data exchange takes place can vary. This also depends, for example, on how the operating system implements system-specific slots during multitasking. So maybe the best solution would be for Bjoluc to implement also an artificial slowdown in the problematic sections of his script.

483

Doesn’t it seem a little peculiar that Steinberg, a division of Yamaha (the largest maker of musical instruments in the world), isn’t able to produce a decent control surface that they can support. You would think that there would be considerable demand for a decent control surface that just works right out of the box with Cubase, Wavelab, Dorico and Spectralayers.

I have an X-Touch, not because I love Behringer, but because it is really the only option for an 8 (or more) channel control surface that (kinda) works. Mine works most of the time, but I am still on Win10. I need to replace my computer to get to a better platform for running the AI stuff, but I am staying on Win10 for the moment mainly because of this control surface issue.

I’d happily pay $1000 for a good control surface that just works without me having to fiddle around with it so much, especially if it came with deeper integration into Cubase.

484

I get what you’re saying, especially as the CC121 was such a solid controller and well loved, but the only other product is the Yamaha Nuage system which costs an absolute fortune and already has been left to rot. I’d be furious if i’d invested in that.

So all things considered, I do prefer this open approach that they’ve gone for with the MIDI Remote API. As they provide a platform that we can interface with, so there’s no lockdown of an eco system that leaves you stranded.

The problem with deep integration with Cubase is that you can go in any number of directions with it and therefore ‘a’ controller doesn’t suit everyone. My requirements would be different to yours, and the next person.

Whereas this approach allows us, with a bit of work, to get what we need.. or very close to it, with whatever controller(s) we prefer to use, and use them in multiples.

For them to put out something that is deeply integrated and caters for most users needs, they’d probably need three pieces of hardware: a main fader console, an extender and some kind of channel strip/plugin controller.

To release that to only Cubendo users, who already can pick up a Nektar CS12, Mackie, X-Touch, Econ, SSL, or Faderport and use across a variety of software - I don’t think is all that financially viable.

I’d also imagine that Yamaha have sights on MIDI 2.0, so perhaps there may be something in the very near future that utilises property exchange and all the good things that were touted years ago?! Who knows.

Big problem is that it’s very hard to beat the mouse and keyboard, as sterile as it can be. :frowning:

What surprises me the most is that there’s been no open source controller that caters to people’s needs that can be easily mapped to Cubase. A standard controller that is not tied to any one eco system would be perfect (imo).

485

Does the MIDI Services SDK come with any facility to slow it (Midi 2.0) down? This would enable us to diagnose whether speed is indeed the issue. Bjoluc has already said he’s not going to revisit his script for at least several months (if at all), and I’m no programmer. I don’t want to go blundering putting delays in a script I know little about when the actual cause of the issue may be something else entirely.

For us users relying on these things, just let us have a ‘use legacy midi’ checkbox please.

If not, I’m hopeful that Pete can pull something out of the bag.

486

True. And also touch screens can cover most of what we do with control surfaces.

487

My problem with the LCD (missing text, some LCDs remaining dark) and my master keyboard not being recognized suddenly appeared after KB5079473. After uninstalling it, the X-touch + eXtender and everything else worked as they should again.

gruß chris

Update: This KB5079473 update must have reinstalled itself undetected in the meantime. But since everything is still working as it should, it will remain for now.

488

Hi Chris, So are you saying that your X-Touch is working fine with Bjoluc’s script and the new MIDI stack? If so, that’s very useful data - you’d be the first person who’s reported it to be working fine.

atb, Paul