Don't remove Generic Remote, instead improve it? Or Improve MIDI-Remote to have same function

I’m trying to get into MIDI Remote, but honestly I don’t have the time.

I’m not seeing how I can use MR to quickly setup CC messages binded to Project Logical Editor scripts.

MR is WAY too involved for this.

I have a controller with 32 templates, and I just need to map the buttons across the different templates directly to PLEs.

…. On the other hand….

The Generic Remote windows are just annoyingly small:

And the Value Action menu, is too narrow.

This is actually painful in 2026, I’m actually having anxiety. I have a bunch of PLE work I need to do.

4 Likes

Seconded. It’s just so much easier to map Touch OSC to Generic Remote. I tried Midi Remote and it’s driving me nuts.

1 Like

Glad to know I’m not the only one… I just sort of had this moment of feeling completely baffled, lost.

1 Like

Fully agree. I have tried to use the MIDI Remote feature since its implementation, to be able to use the eight endless rotary controls of my Akai MPD32, which deliver standard NRPN increment/decrement messages : it’s simply impossible, using the graphical interface. Life is short : as you, I no longer have the time to learn the javascript language just for this, and the lack of a clear documentation doesn’t help.

So, I continue to use my two Generic Remote definitions (one for each of my controllers) already set and carefully saved, countless years ago… :face_with_diagonal_mouth:

3 Likes

@Teo @cubic13 do either of you know if there is a .xml file I can edit somewhere to make the Generic Remote boxes bigger?

MR always works in a two component way:
First component assigns the incoming midi messages to a an element of the surface (this can be a visual replica of your midi controller if you like, so it is easier to grasp what in the computer corresponds to what on your hardware).
The second component assigns each surface element to a function in Cubase. It is very easy to do with the mapping assistant:

  1. select the surface element; 2. select the Cubase function; 3. click “Apply mapping”

The first component is the upper list in Generic Remote. The second component is the lower list. So in essence it works just the same. The difference is that instead of just a list of elements (called Controller in Generic Remote) you have a graphic in Midi Remote.

How do you do that when your hardware has multiple template pages with different CC Mappings for the buttons?

Or do I just create one device with 128 buttons on it.

Either way, imo, it’s still too involved. Even just creating the graphics, it’s time not needed to be spent at the moment.

I’m not sure why there isn’t a way to create a non-graphical device and just use Mapping Assistant to create a list of triggers/actions as the replacement for Generic Remote.

Thanks for your help

1 Like

If you like to do that… sure.
But more likely you would create one surface per template and then switch through them when necessary.
grafik

Since this is rather done once and not several times per day, the couple of extra clicks don’t multiply. If you don’t care for aesthetics I bet it takes only a few seconds longer to create the surfaces than the lists.
To me it does not sound like this is a real issue other than you having to get used to the MR editor. And since Steinberg made it clear that they won’t invest any resources into the Generic remote any more I lean myself out of the window by saying this topic will lead to no improvements of GR.

Of course, it is only my opinion and you can knock yourself out continuing this topic. It is your time and energy.

But then… I’d need to set up some commands to switch the surface? or have my templates send SysEx to switch the surfaces? But then at that point… what is the point?

I just need to map my buttons x templates enmasse.

Well, I have 2000 PLE scripts not including hundreds of macros… And I’m in the process of revising them, making some tweaks, creating some new ones, etc…

And so it’s definitely more than several times per day for the days that I am working on this.

It could be that they need to make MIDI Remote better, to not be confined to graphical device emulation, and instead be non-device specific mass control portal.

2 Likes

Nope. It’s annoying as hell. They haven’t bothered about the GUI for a long time, and then abandoned it once it became legacy.

1 Like

TOTALLY. I feel like Midi-Remote was designed more for physical MIDI controller devices, than for touch-based stuff like Lemur, Touch OSC, Open Stage Control, etc.

Just give me a non-device-specific mass control portal like what @awesomeaudio said. Where we can just simply enter corresponding commands. There are many users out there who need this too.

3 Likes

If you need things like SysEX, MR can’t do it. You have to use the API and navigate your way through the confusing reference guide as there’s no manual to the thing.

….. Well I’m definitely not feeling more hopeful for MIDI Remote… Or Generic Remote

1 Like

Apparently it’s not “just a me” issue.

How many PLE/Macro scripts have you written?

FR thread here

MIDI Remote: Create a Non-Graphical Device, that is a control list/MIDI Portal = Generic Remote - Cubase - Steinberg Forums

Hi @awesomeaudio, you could try one of these (using the import script function). I guess you need only the buttons version. It is a rough attempt and will not be as performant as the real Generic Remote.

Generic_Remote Knobs.midiremote (2.0 KB)

Generic_Remote Buttons.midiremote (2.1 KB)

Generic_Remote Custom.midiremote (2.1 KB)

2 Likes

Hi @Jochen_Trappe , thanks for taking the time to respond and post some scripts, I appreciate it, I’ll take a look at those and see what I can come up with.

Thanks again!

1 Like

The removal of the GR would kill off Metagrid. I doubt that would be Steinbergs intention.

My guess is that they emphasize using MR for obvious reasons.