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.
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.
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
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.
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.
