This is an issue I have with several macros. I create a PLE that works fine in Cubase (15 Pro, on W11 latest versions), I assign a macro in the generic remote to run that PLE. In MG, I assign that macro to a button. WHen I press that button, I do get the expected behavior of the PLE, but I also get unexpected behavior. In one case the pan jumps to the right, in another case a track gets muted, and in another case a track gets soloed! For instance, I have a macro to hide disabled tracks (macro 011). I press the button and the disabled tracks do get hidden, but then a track gets ‘m’ muted.
Hi Brett,
Thanks for the screenshots. We checked the mappings, and Macro 011 sends MIDI channel 10, CC21. The Selected Channel mute control uses the same message on a separate MIDI port. Pan and solo also share messages with nearby macro slots. That makes a second control mapping receiving the macro’s MIDI traffic our leading explanation, although we still need to check your routing.
The MIDI input shown for Generic Remote 4 is correct: Metasystem - Cubase. On the native Windows setup, the MetaGrid Pro Selected Channel surface should use Metasystem - Cubase Sync for both input and output.
Could you check the Selected Channel ports and send a screenshot of the MIDI Remote device list showing its input and output? Please also show the MIDI input assignments for the other Generic Remote devices in Studio Setup—an older mixer mapping could be receiving the same messages.
For a quick isolation test, keep Generic Remote 4 unchanged, temporarily disable only the Selected Channel script in MIDI Remote Manager, and try Macro 011 once in a test project. Then re-enable the script. Does it still hide the disabled tracks, and does the unwanted mute disappear? Steinberg’s instructions for disabling and enabling a script.
If the mute still occurs during that test, please also show the button’s complete macro in MetaGrid Pro so we can check its actions and target.
I was busy today so I will check all this tomorrow.
Why would the macros send MIDI messages? Aren’t these macros specifically for users to program? If not, then what are the macros that do not have any extra midi messages on them?
I actually remember having an issue a long time ago where MG was sending messages to CC for no reason. I had to turn off midi out somewhere, I forgot. Not sure if that is the same problem.
Thanks.
Well, not sure what I did, but it is now working properly. At first, there was no Commands for some reason, so I added it. I went into generic remote 4 (where my macro is) and i changed it to not Metasystem then back to Metasystem Cubase then pressed okay. It then worked fine, no surprising behaviors anymore on any macro. It was acting strange for 2 weeks but now it’s okay!
Here’s all my screen shots anyway.
BTW, what is the Metasystem Midi loop used for? I use Metasystem Sync and Metasystem Cubase, but not Metasystem Midi.
Thanks 
Oh, and why does macro have several functions?
Hi Brett,
Glad the unexpected behavior has stopped. Your new screenshots show Commands on Metasystem - Cubase, Selected Channel on Metasystem - Cubase Sync, and Generic Remote 4 receiving from Metasystem - Cubase. We can’t tell which of the changes restored the setup, but there’s no need to disturb it while it’s working.
MetaGrid Pro sends a MIDI CC to trigger a Generic Remote macro slot. Cubase receives that trigger and runs the action assigned to the slot—in your example, Macro 011 runs your “Hide Disabled Tracks” PLE. In the Generic Remote window, the upper table defines the MIDI trigger and the lower table shows its assigned Cubase action. The other numbered Macro rows are separate slots; pressing Macro 011 does not run all of them.
Metasystem - MIDI is the general-purpose port for MIDI notes and CC from objects such as faders and pads. Your PLE macro uses Metasystem - Cubase, and the current Selected Channel surface uses Metasystem - Cubase Sync, so the general MIDI port isn’t needed for those two functions. It can still be useful if you send MIDI to instrument tracks or use the older Metasystem3 Generic Remote setup.
If you meant that a single Cubase macro contains several actions, that’s a different kind of macro—send us a screenshot of that macro and we’ll explain its sequence.
Hi, I am on my second computer and the unwanted behavior is back. Pressing my MG buttons works, but it will Mute and Solo tracks, which are not part of the commands. I did try what worked last time, I changed Generic 4 to another input and then back to MG and it does not help this time. I am also having unwanted behavior on another command that causes the Pan to go all ‘Right’.
THe screenshots from before are the same as they are now on my 2nd computer.
I did remove Selected Channel and the bad behavior was still present.
THanks.
Hi Brett,
Thanks for testing this on your second computer. The fact that the unwanted behavior continues after removing Selected Channel is important—it means we need to look beyond that surface.
The intended PLE action still runs, but the same button press also changes mute, solo or pan. A second mapping receiving the same MIDI trigger remains a possibility, but we haven’t confirmed where that happens.
Could you send us the following from the second computer:
- The MIDI input assignments for all Generic Remote devices in Studio Setup.
- The current MIDI Remote device list and port assignments.
- The complete MetaGrid Pro macro for one affected button, ideally Macro 011.
For a focused test in a small test project, please note the current input assignments, then temporarily set the MIDI inputs of the other Generic Remote devices to “Not Connected,” leaving Generic Remote 4 unchanged. With Selected Channel still removed, try Macro 011 once. Does it still run the PLE and also mute a track? Afterwards, restore the input assignments.
Please also let us know whether the unwanted change affects the selected track or always the same particular track. That distinction will help us trace which mapping is responding.
Thanks for sticking with this—we’ll use these results to narrow it down.
1 Like
Okay, well, when I launch Cubase, the Commands surface is not present, although it is in the scripts, just not activated. I then added it, I have to do this almost every time I launch Cubase. I was still having problems running any custom MG macros, so I went to Generic Remote changed the input to nothing then back to Metasystem Cubase and then my macros worked, and with no extra commands. I guess some sought of reset needed to be done to overwrite the default? Also, not sure why Cubase has problems recognizing the commands surface at first. Here are a bunch of screen shots, including showing no commands, and then after I added commands.
MG.zip (558.1 KB)
Hi Brett,
Thanks for the screenshots—we can now see a specific conflict.
Generic Remote 3, which contains the older Metasystem 3 mixer controls, is receiving from Metasystem – Cubase, the same input used by your macros in Generic Remote 4. Its pan, mute and solo controls overlap the MIDI messages used by the macro slots. For example, Macro 011 and the older mute control both use channel 10, CC21.
That also explains why removing the newer Selected Channel surface wouldn’t remove this particular conflict—the older mapping remains active in Generic Remote 3.
Please try this in a small test project:
- In Studio Setup → Generic Remote 3, set MIDI Input to Not Connected, then click Apply.
- Leave Generic Remote 4 on Metasystem – Cubase and keep your current Selected Channel surface unchanged.
- Test Macro 011 and the other affected buttons.
- If they work correctly, restart Cubase and test again.
There’s no need to delete or reimport any mappings. Please let us know whether this stops the unwanted mute, solo and pan changes, including after restarting.
The missing Commands surface is a separate issue. Could you also send us your installed Commands JavaScript file, and confirm whether MetaServer is already running before you launch Cubase? Your screenshots show the correct ports once you add the surface, so we’d like to check why it isn’t appearing automatically.
Thanks again—these screenshots have helped narrow this down considerably.
Hi, can I just leave generic remote 3 midi to ‘Not Connected’? Will this affect anything since I am using the midi remote? Can I do this for generic remote 1 and 2? I will try your test later, but I think this is the problem.
Attached is my Midi Remote scripts. I do have MG server launched before Cubase, if it is not working, sometimes I do shut it down and relaunch with Cubase open already. ANd I usually still have to add commands.
MIDI Remote.zip (4.3 MB)
Hi Brett,
Yes—you can leave Generic Remote 3’s MIDI input set to Not Connected if you’re using the newer Selected Channel MIDI Remote surface instead of the older Metasystem 3 controls. This disables the older mapping without deleting it. Any buttons still relying on that older mapping would stop working, but the newer Selected Channel surface should continue working independently.
Please leave Generic Remote 4 connected, as that is what receives your custom macro triggers.
I wouldn’t disconnect Generic Remote 1 and 2 at the same time. They contain older command mappings, and some of your existing buttons may still depend on them. Having the newer Commands surface installed doesn’t by itself tell us whether every button has switched to that route.
For now, disconnect only Generic Remote 3, test the affected macros, then restart Cubase and repeat. That will give us a clear result without changing several things at once.
Thanks for attaching the MIDI Remote files and confirming that MetaServer starts before Cubase. We’ll inspect the Commands script separately to investigate why you still have to add its surface manually.
1 Like