I use my own Maschine Controller Editor Template for the Maschine MK3.
A MIDI Remove Script won’t work because you have to go to MIDI Mode on the Maschine, and what template is selected may or may not be what your Script is mapped against.
no its not… half assed junk…
yeah its fine for a few keyboard controllers and pads… but no good for customizing a mackie which is should concentrate on with nuendo
half assed just like everything else humans make
If they keep progressing it, it’ll be good. “If”, of course being the key word here.
It needs a lot more work before we can do MCU style mappings though, such as being able to list the inserts on the selected track, have multiple pages of parameters - that kind of thing. I find this whole 8 quick parameter limit without paging to be really poor I must say.
However, let’s sing it’s praises for what it does well - It’s clear most time has gone into the interface and making it simple for people- I was really impressed with that and my controller being pre-mapped on startup was most welcome.
I just wish there was some kind of roadmap so we know where they’re heading, and how risky it is to stick with generic remotes, and piggy backing on MCU remotes in the interim - i.e. When do these get phased out? And do they need to be phased out for the MIDI Remote to improve?
1 Like
I´ve been trying to keep away from scripting directly since in my experience, new updates to software sometimes renders them obsolete… and then starts the scripting process again. But I will definitively check your script, thank you.
That about the watermark, is more like an emergent sign on the screen when you press something… I know that if I leave other monitor, or the lower part of the interface with the Midi Remote… I can see there what I am doing… but it is cumbersome and too much screen realstate.
About the problem with the controller jummping at startup… darn! that was driving me mad… sometimes it didn´t auto remap quickly enough… What I did goes along with your question:
MAIN PAGE: (I have another that is the main mackie mode… to mix… but I barely use it, so I made it page 2.)
So the main page, Page 1: (I only controll one Track at a time, and that is what works for me, is faster to produce)
- The channel selection for the faders is the default, FADER 1 to Channel 1, Fader 2 to channel 2… but, I modify their functioning. (check the picture)
The fader 1 is The level for selected track (So yes,
FAder 2 to 8 are assigned to FOCUS quick controlls.
FAder 9 (Master) is assigne to AI Knob at JMouse pointer.
Knobs buttons are assigned to some macros and basic track funcions.
Knob 1 is for Pan of selected track.
Knob 2 and 3 and 4 are for Quick controlls SELECTED TRACK (for which I create a preset for most my instruments and tracks)
Low Cut, High Cut and Gain… This is very cool.
The other 4 Knobs are for my SENDs 1 --4
The transport, I combine basic main functions with Macros I made and I now Do use the transport in the Icon. The wheel is very cool, I can move horizontally in timeline, vertically changing trackas and to controll the main Volume in the Controll Room. (“how cool is that?” Dom Sigalas)
CAVEAT: This controller likes just the JUMP Mode in Mapping Configuration.
so theres that! I hope it helps you.
(this setup for me is great and I am getting very used to. It will be awesome when the darn LEDs gets fixed -I will check your script, thanks!)
1 Like
There are a few issues with MIDI Remote:
-
Most controllers jump parameters, which means unless you have motorized faders and/or endless encoders that stuff is impractical. It just creates work as you jump parameters/faders when moving across banks. No bwnefit over MCU/HUI. Actually worse with some controllers!
-
Ironically, setting up a Launchkey 49 MK3 as HUI in Studio One 5.5 results in Soft Pickup for both the Faders and Knobs. Even though half the transport controls don’t work in Studio One, this is still more useful than what Cubase provides via the MIDI Remote Script, because it means you can mix and adjust parameters with the controller without creating tons of extra work for yourself. Better workflow and productivity.
-
There are controllers like the Oxygen Pro series that provide far superior on-device controls to any of the controllers that Cubase ships with MIDI Remote support for (out of the box), and they continue to be superior using Mackie Control Emulation because the preset editors for those devices are fantastic at accommodating power users (e.g. allowing you to map Keyboard shortcuts as well as Notes and MIDI CCs). All of that, without having to play UI designer in your DAW.
AFAIC, the MIDI Remote System - thus far - does nothing but save you 2 minutes of initial setup time with a controller. And maybe 15 minutes of tweaking the stock DAW mapping/preset to suit your fancy.
The controllers it ships with support for are simply not good enough to even merit them having wasted the time to create a script for them… and those that are, are either unsupportable (due to how the controller implements things - i.e. no support for Shift States), or don’t have scripts written for them… And it is barely worth doing the work yourself, due to how good the stock DAW Presets and Preset Editor are for those devices.
My Oxygen Pro with MCU Emulation is still far superior in terms of “DAW Integration” to my Launchkey 49 MK3. It is not worth foregoign the better Key Bed, Pads, DAW Controls, Overall Build Quality, and superior layout efficiency of the Oxygen Pro for the Launchkey 49 MK3 simply because the latter has a stock MIDI Remote Script in Cubase.
And it is hardly worth wasting time creating a MIDI Remote Script for the Oxygen Pro. The Stock DAW Preset for that device is already superior to the MIDI Remote Script Cubase Supplies for both the Launchkey and KeyLab Essential Devices. With a few personal tweaks, it blows them away.
The best thing about the Launchkey 49 MK3 is that it has soft pickup for pots and faders in Studio One. That’s the only reason why I’m keeping it. MIDI Remote is literally ignorable, practically speaking. Many controllers that use Mackie Control/HUI still give a better user experience than any of the controllers Steinberg ships Cubase with scripts for.
I feel like this entire system is, thus far (from what we’re seeing), a waste of development time. The only controllers it is “great” for are older controllers and others that don’t ship with MCU/HUI Emulation/Support. For those, it can breath life back into them, or make them viable for use to control the DAW. For the vast majority of MIDI Controllers, I don’t see how MIDI Remote can be considered a replacement - much less an upgrade - over MCU/HUI emulation.
It simply delivers nothing of worth that the others do not, while serving no other purpose than to promote fragmenting that market segment.
1 Like
For my own use case I do agree, once you get past the ‘prettiness’ of it there’s many aspects lacking
However, for people that want basic mappings it’s without doubt much much easier for them. Just look around the forum and videos that people have put up - it’s arguably helped the majority.
It’s the minority of users who are left feeling disappointed. And while I hate paying for a feature that you have to wait for improvements on, it’s the only choice right now. Trouble is, we don’t know when the old remote options will be removed and we have no idea what the plan is for MCU support, or more flexible encoder acceleration options.
My biggest fear is how bolted on this approach has been, was expecting something new and a fresh take. But the implementation and API feels like stepping back a decade, not helped at all by using an old revision of JS.
I’m weighing up the possibility of waiting several years for this to be completed, or just using another DAW. I’d be amazed if they removed generic remote/mcu remote options overnight - but who knows now the warning message appears on those panels?
Multiple plugins were dropped without warning in C12, VST2 being struck off. It doesn’t leave you with much confidence. Moreso, I don’t even believe we will ever be able to recreate MCU style operation with the MIDI API (i.e. where you can target specific plugins on a track, have pages of parameters etc.)
1 Like
Not being able recreate a driver for 20 year old midi device is hilarious. People should be able do make a driver for a Oculus Quest today.
Now would be a good time to read some further/new input from @Jochen_Trappe - just saying…
It saves you 2 minutes of initial device setup. Once you set up the device, which is pretty easy with MCU or HUI, the setup persists in the application.
It does look nice but, functionally, it is a downgrade for many controllers.
I think it can save hours vs the old generic remote. Particularly if you’re creating many pages of mappings, as the on-screen reference serves as a great guide.
Also you can learn by clicking on-screen parameters. With the generic remote it was all there, but you needed to spend quite some time menu diving to appreciate what can be done.
Not everyone could get their head around that system.
1 Like
The favt that most of the stuff is implemented as emulation of keystrokes, instead of being directly connected to the remote, is a huge drawback.
You can’t even have some decent zoom or jog without a ton of scripting.
Too much work for something useful.
1 Like
Yup, that’s a very big annoyance - the other annoyance with keystroke emulations is that you need to ensure that the application is in focus and you’ve got the correct section selected.
I can sometimes be focused on a plugin or external window and that breaks the mappings on my hardware that is set to trigger a key command, which is very annoying when you have to move the mouse and click on the main window first - kinda defeats the point. 
1 Like
Lol. He’s actually talking about MIDI Remote, not the hardware.
Hardware has decent Zoom and Jog without all of that, by simply assigning the Jog Wheel to the proper MCU/HUI Function. Doesn’t matter what part of the application you’re in, it just works.
Also, things like Quantize, Open Mixer, Open Channel Editor, Undo, and Save really don’t require any thought as to what is selected. These are all global application functions. They work the same whether or not you have a plug-in window open or not, or in focus.
You use the hardware the exact same way you’d use the [typing] keyboard connected to your computer. I don’t see what the issue with this is. No matter what device you’re using, you always must be conscious of what has focus within your software [when using relatively generic navigation or editing functions like zooming, scrolling, Undo and Copy/Paste]. This is something anyone learned when they learn how to use a computer at the most basic level. No one actually thinks about this when using a computer… Well, almost no one 
Additionally, some controllers allow you to switch presets from DAW to Plug-in with one button click, so this is not an issue.
It might take “hours” to do this in the Cubase MIDI Remote Editor, but it absolutely does not take “hours” to do this on any of the controllers I own.
It takes 2 minutes or less to set up a controller with MCU/HUI emulation in Cubase. It took me less than 10 minutes to modify the stock preset (to add shortcuts to free slots, etc.) and less than 3 minutes to assign the QC MIDI CCs to the Plug-in Preset that I can switch to in one button press for Quick Control editing.
And, as I’ve stated… One of these supported controllers functions in a far superior manner using stock HUI support in Studio One, to the point that any savings in “setup” time are completely blown away by the fact that that practical function of the controller is sacrificed to enable that.
I might delete the script and test it in Cubase to see if it works as well as it does in Studio One. That being said, if I were trailing DAWs and had that controller, I’d probably choose Studio One over Cubase based on how usable the controller is there vs. in Cubase. My Oxygen Pro works better in Studio One as well, so it just feels like Cubase is not as good as other DAWs at accommodating these devices, and the MIDI Remote system simply isn’t good enough.
Not every producer wants to be an ad hoc software developer, either.
Not with direct binds, this only occurs with keystroke emulations - of which there’s too many.
If you’ve ever used MCU you should know this - I could be using an internet browser and still controlling Cubase. Going from that protocol to the MIDI Remote means I have to be careful of what is in focus.
Which is the prime objective of the MIDI Remote, as discussed, it’s a whole lot easier (Not better!) than the generic remote screen. The API is for developers and those wanting deeper control.
And yes, all these functions discussed should be in the MIDI remote and it’s seriously lacking compared to what we could do before - the concept looks good - it’s just unfinished, and we’ve paid for it!
There’s no roadmap or information to suggest what comes next and whether the issues many of us raise are being addressed. I fear we could be waiting years, been waiting since late 2020 when the MIDI Remote was leaked and wish they done a public beta back then. I find this bolt-on approach less than adequate and already out-dated.
But I hate bashing Steinberg, so think it’s only fair to praise what is there at a base level and appreciate that it DOES help a huge section of users who only want transport controls, mute/solo/arm, mixer/pan levels, 8 quick controls and AI knob support.
You’ve only got to look at some of the mappings that have been created for the BCR & Maschine devices for example. I’ve never seen people so active in sharing MIDI Remote setups on here before, so it’s a good thing (imo).
The MIDI Remote has allowed me to have my motorized faders on the Icon Platform M+ for quick controls, EQ, sends etc all with names going to the display, in a custom setup.
Yes it required scripting and yes there’s also some features still lacking (open/close/bypass plugins), but it the MIDI Remote does add a lot to my workflow in a way that I was not able to get previously.
So I would also say there’s also lots to gain for people that don’t just want basic stuff, but true it require some hours for the setup.
I just hope Steinberg will develop and add missing features in the near future.
4 Likes
… so great. Love this feature!
Had anyone tried to use NI Komplete Kontrol M32 lately?
1 Like
That sounds interesting! Would you mind sharing your translator preset you are using ?
Though I don’t have a C4 I could send the values to “MCU Displays” in Lemur…
Thanks a lot!
Then it’s not Amazing , it’s lacking and not as good as the Generic remote unless your a programmer . You’ve said yourself .
it’s a gimmic at the moment and unless developers pick up and release UNIVERSAL scripts for this scriptors paradise then we are left with a broken turd in Cubase
It’s not all that hard to create some universal scripts as you can include one js file which contains the global variables for mapping vals.
Meaning that a script can be standard (8,16,32 parameters etc) and a supporting file could be where the end user enter their hardware (cc) values and types to suit.
Trouble is dealing with all the feedback and complaints that people have. And what would be the universal options that people want - I’m guessing the main advantages for API driven scripts are screen feedback and dual purpose knobs (CW/CCW) such as for jog control… But you are somewhat forced to go through the API to get this right for each hardware so ‘universal’ goes out the window.
Be nice if we had a depository where we can upload scripts and download within Cubase MIDI Remote directly and perhaps upvote on them. Yes there’s a tag on this forum but many users don’t know how or where to find them.
I’ve thought about doing an index and app that downloads and copies the script files where needed, but it’s very hard to moderate and ensure that the “best” scripts sit at the top and encourage users to go back and vote on what works for them…
Steinberg users just don’t seem interested in community sharing - look at what’s possible with HALion yet there’s barely any content out there.
It’s a little annoying as the tools are pretty much all there, yet it’s very cumbersome and feels antiquated already to me. The MIDI Remote within the main app is very good for basic mapping tasks though… I think most third parties would probably just go this route and get basic transport, volume, pan and Focus quick controls mapped - because that is super easy now, and no API/JS knowledge required.
1 Like