Vote Ability to Rename Mackie Control and HUI devices

Please allow renaming of Mackie Control and Mackie HUI devices. Having generic names which are then numbered when multiple similar devices are connected is not user friendly, and having user friendly names/aliases in this dialog box and when devices are referenced elsewhere would make this much easier for users with complex setups.

I understand that the Generic Remote has been superseded with the new MIDI Remote handling, but I am hoping that Mackie Control and Machine HUI devices will continue to be supported given the amount of hardware in use out there which only supports these protocols, or where these protocols provide the best options for integration.

Called out separately from other requests but worth referring to other requests such as Any way to Rename the Generic Remote name? and the one I had created which included this originally Ability to Rename Note Expression devices.

2 Likes

Mackie is industry standard, works with TONS of devices while MIDI Remote still can’t even do transport in a half decent way.
It would be a huge mistake to retire a working protocol that supports a ton of devices and leave users only with the half-done MIDI Remote.

1 Like

I do hope that with this ‘discontinuation’ comes…

Something better to replace it…
Automatic ‘conversion’ of our setups to the ‘new format’.

I still have hundreds of lines built in the ‘legacy’ remote systems. I’ve gradually begun manually making new scripts for the newer system by adding a few things at a time on an ‘as need basis’, but it’s a PITA to reinvent a wheel that was already working just fine. As a user I’m not really getting much benefit from the ‘extra work’. Just some fancy looking UIs that are kind of in the way if I open them (they do look nice though).

I won’t jump to judge long term though. Steinberg has been solid with legacy support in the past. If the ‘discontinuation’ comes with an automatic process to ‘convert’ our old setups to the new one, I’ll be a happy user :slight_smile:

Having said that…I’m still a little miffed that I can’t easily do HALion in several mainstream hosts anymore without rolling back and forth to/from Sonic 3/HALion 6. I’m frustrated that hosts crash unless I don’t manually remove HSSE3 (which breaks preview in media bay). Some 3rd party hacks exist to kinda get HALion/Sonic 7 working in those hosts, but then existing projects are borked to proportions that require hours of redoing things…or going through all sorts of contorted ‘roll HALion back for this project’, roll it forward again for new projects, etc.

Discontinuing things is fine, if the bridgework is in place to still support our older projects (and it doesn’t require many man hours to make it work again)!

I think it’ll be okay in the long run. Just a little frustrated by the ‘transition’ phase (It might be the fault of other software houses, but we USERS are the ones paying the price).

Please Steinberg, don’t make me go through it all over again when ‘removing’ the SOLID performance of these ‘legacy’ remotes.

Agreed…
My best controller setup uses a good deal from the new remote system, but it ALSO needs virtual connections to legacy remotes. One of which is Universal Mackie Control.

I figure there are plans to get Mackie and Sysex working with the new system as it should. If not, it’ll be a big step backwards. I don’t think Steinberg would do that to us.

Understand that Generic Remote is being deprecated, but I also agree that Mackie and Mackie HUI really do need to be maintained for the long-haul given the amount of hardware out there that rely on these protocols, and therefore should have the option for renaming/friendly names.

Yamaha just launched a new series of digital mixers at NAMM. Those do DAW control only thru Mackie and come with Cubase AI included.
Would be pretty funny to have the included DAW be one (or the only) of those that don’t do Mackie.

Hi,

In my opinion Mackie Control cannot be dropped before or will be covered by the MIDI Remote completely.

2 Likes

Just answering for the MCU part, since for the generic remote, I tend to view the midi ports for each one of them, so that I can recognise what does what.

I think it is pretty straight forward (for Steinberg at least) to create a “generic” script for it, when of course they get to add stuff that’s not yet implemented in the API.

Let’s split it in two parts:

  • Midi input: Nothing to write home about, here. They are just ordinary CCs and notes. The script can receive them and act accordingly.

  • Midi output: MCU usually waits for CCs, notes and Sysex, and lights up leds, moves faders and displays info. Nothing of much trouble here, either.

My script for the Arturia Keylab, (note that by Default Arturia is using MCU for this controller) is already doing this to a degree: It receives CCs/notes made for MCU, processes them, and when needed spits out to the controller responses compatible with MCU (for example display sysexes).

Now, the way I see it, there will be no conflict at all, though I can hardly understand such procedure, EXCEPT IF they get to add functionalities not included in the MCU, thus making these compatible controllers even better!Ideas? Plenty! What I personally would love to see is a great MediaBay integration, and trust me is NOT a hard task.

1 Like