I was just thinking how cool it would be to have Metagrid as a Device we could add + like I do with Eucon, to save all the Macros and Scene to link functions . The Scene are ok, but I ran out ages ago so now its setting up Keyboard short cuts and using Macros , I find the Macros very long winded..
also I heard generic remote maybe going and the though of using MidiRemote and having to create everything twice could be a nightmare
Andy
That’s a great thought — and you’re not wrong.
Having MetaGrid appear inside Cubase like a native device (similar to EuCon), where macros, scene links and mappings live at the DAW level, would absolutely streamline complex setups. It would reduce dependency on long macro chains and remove some of the keyboard-shortcut gymnastics.
But here’s the straight reality:
EuCon-level integration exists because it’s built on deep DAW-side APIs. MetaGrid operates externally — at the command and MIDI layer. Turning it into a Cubase-native device isn’t a small feature request — it’s essentially building a full Cubase integration layer from the ground up.
That said, your frustration is valid — especially when scenes start running out and macros become layered and hard to maintain. That’s usually a sign the workflow architecture needs restructuring rather than adding more macros on top.
On the Generic Remote → MIDI Remote concern:
Yes, Generic Remote is legacy. MIDI Remote is the future.
The key thing is this: you shouldn’t be building everything twice.
The clean long-term structure looks like this:
• MIDI Remote → parameter mapping and bidirectional controls
• MetaGrid → workflow logic, layout, navigation, command orchestration
If those roles are separated properly, they complement each other rather than duplicate work.
Long term, the real opportunity isn’t “MetaGrid as a EuCon clone.”
It’s tighter interoperability — potentially generating or syncing with MIDI Remote structures so you don’t have to rebuild logic in two places.
That’s the strategic direction that makes sense — deeper integration without turning MetaGrid into a hardware driver project.
If you’d like, tell me how you’re currently structuring your scenes and macros — there’s usually a cleaner way to organize things that reduces macro sprawl dramatically.
One of my problems with the midi remote (for me anyway) , is it sometimes loses its devices, I work from a MBP so in the studio I’m hooked up to a large rig via TB4 , then when I’m finished pull the TB4 and just work on my lap without any Midi devices connected, Midi Remote doesn’t always like that , I’m actually a beta tester for Steinberg, I have been bringing this up.
The clean long-term structure looks like this:
• MIDI Remote → parameter mapping and bidirectional controls
• MetaGrid → workflow logic, layout, navigation, command orchestration
Ok , I’ll look into this asap , as the little amount of time I have spent setting up Midi Remote for a couple of hardware units I have, was first creating all the GUIs in Midi Remote then linking them to my HW , before then telling Midi Remote what they would Control in Cubase.
I think the only reason I’m running out of Scene is I have very deep dive in invisibility agent set up via PLE which I love , but it does take a lot of th Scene . Here my main MGP Grids
If you hold the articulation , you get a ADD function so you can hit String/Leg then Hold the Brass/Leg and say add , you then just see Brass and String Leg. I love ir
Depending on how complex your Generic Remotes are, I may have a utility to convert them to MIDI Remotes. DM me.
