feat: Add a Mackie MCU Pro script variant

[bjoluc]

For anyone wanting to try this out, the compiled draft script is available here (only accessible when you are logged in to GitHub).

[bjoluc]

Hey @blissdrums, thanks a lot! :pray: I'm mostly interested if everything is working correctly (= as described in the readme). And I'm keen to find out what is causing the weird scribble strip issue you are experiencing. I don't have any explanation at hand, other than multiple scripts (/script instances) or a traditional Mackie Control device running at the same time? :confused:

[bjoluc]

I did double check that the MCU control surface in Cubase was set to "not connected" as you mention in the documentation, so as not to lose my F1-F8 mappings..

Then you should be good, I guess. I can hardly imagine other scripts being the problem. However, I recently had one user reporting that the script was running twice within one Cubase instance, until he restarted Cubase :thinking:

[bjoluc]

Thanks, I got the video :+1: How weird that it's showing dots :exploding_head: Oh, doesn't the MCU Pro have a dot mode for displaying levels in the lower row? Something might have activated that.

[Support-AT]

Ok, I just tested the Mackie script and am seeing the same with the display. I made a quick video..

That looks quite glitchy, it seems like there's a break in comms or something else is sending data to your MCU port to me? Double check you're running in Mackie Control mode, if you're not sure how to do this: Hold down select buttons on channel 1 and 2 when powering on, and you should get the choice of Mackie, HUI or Logic. - Pick Mackie, of course.

Are you connected via a direct USB cable, or are you running via a MIDI interface?

(I'm skijumptoes on the forums by the way, this is an old work account I had on github).

[JDubs73]

I am using Mackie Control mode, and am connected via a direct USB cable. I've tried a few different ports with the same result. One other thing I noticed.. on one specific project template, there is a bank of 8 channels that shows up consistently on the display when I bank backwards.. it stays on the display until I click a select button, at which time it disappears. Very strange. Thanks

[Support-AT]

there is a bank of 8 channels that shows up consistently on the display when I bank backwards.. it stays on the display until I click a select button, at which time it disappears. Very strange. Thanks

Yeah really is strange. I've got the older MCU (Darker one) and it works fine so the implementation is good. It just looks like something else is sending on that port due to how it glitches in your video.

You've got no virtual ports or additional routing going on outside of Cubase?

And you've checked no other MIDI remotes are sending on that port, nor any of the MIDI Remotes within Studio Setup?

@bjoluc mentioned that the script double loaded for someone too - View all the scripts that are loaded with that button at the top left of the MIDI Remote interface to check:

[JDubs73]

Double checked that there are no other Midi remotes using that port, and that there are no virtual ports either. I had V-Control ports that were used for an old app using Reaper from a few years ago.. I made sure all of those are disabled in Cubase. I also checked the top left button for loaded scripts, and it is showing the new Mackie script as active and my two other scripts as inactive (one for Faderport, one for BCR2000). So, I see no double scripts.

I totally understand what you are saying about something else trying to utilize the midi port, but I just can't seem to find anything that would be conflicting...

The other strange thing, is when I use the "built-in" Mackie Control under remote devices with my MCU Pro, the track names show up with no issues whatsoever... it is only when I use this script that they disappear.

It's good to know that you have the original MCU and I have the newer Pro version. We do have different hardware. so maybe there is something in there only affecting my setup.

One more thing to add, I do have after market displays in my MCU and extender. The ones that Mackie makes are notorious for dying after a couple of years (dimming). I have replaced mine a couple of times. The after market ones are much better made and don't burn out for years. I have no idea if there could be something different with a refresh rate or something, but as I mentioned.. the native Mackie Control remote device displays track names with zero issues.

I don't want to link anything here, but if you google "LUX PMVA LED Display Upgrade" you can find them and more info on Reverb...

I have another recording computer with Cubase on it in my office, where I do composing away from my studio. I think I will try to connect the MCU Pro to that machine tonight after work and see if I get a different result. Thanks

[JDubs73]

Ok, I had some time so I just connected the MCU Pro to my composing PC (completely different hardware and software installation).

I am getting the exact same result on the other machine. Built in Mackie Control, track names display with no problems, If I use the script, they disappear.

So, that tells me that there is something in the script not gelling with my particular MCU Pro.. I don't think it is related to interference, if you will...

I wish we had another person who could test with a Mackie MCU Pro and see if they are having the same results that I am.. hmm

I have a lot of money invested in the MCU and extender, but I want this to work so badly that I would be willing to but an X Touch, if necessary... hopefully we can figure it out. Thanks

[Support-AT]

I am getting the exact same result on the other machine. Built in Mackie Control, track names display with no problems, If I use the script, they disappear.

Do you also get that glitchy behaviour on your other machine too? And the dotted characters issue?

I had a look around online and I wonder if it's related to the signal LED message that is in the original XTouch implementation of this script that is causing it?

https://forum.ableton.com/viewtopic.php?t=183176

On the MCUs of course, we get a single 'Signal' LED whereas the X-Touch has a signal meter as standard. Perhaps the MCU Pro unit that you have gets confused when seeing a message in that domain, whereas the older MCU that I have doesn't?

It could be that on the MCU Pro the correct method would be to you only send the meter value when the meter viewable on the MCU display?

Personally I never use the metering as it loses a character for each track - so disabling the metering option for MCU via a true/false variable in the script may be the easiest way to test this theory?

See what @bjoluc thinks, I guess. :)

[JDubs73]

Yep, same exact dotted characters, and same glitch (only when banking).

I like your logic, I could see where something like that could cause an issue... as you say, the MCU Pro does not have meters on the channels like the X Touch.

And I was looking online last night and do believe that there were some different settings available in the original MCU related to display that I'm not seeing on the newer version. A Shift + Name/Value button that would show some sort of horizontal meter in the display.. however, it looks like it may have been specific to Logic Pro, not Cubase.

[Support-AT]

And I was looking online last night and do believe that there were some different settings available in the original MCU related to display that I'm not seeing on the newer version. A Shift + Name/Value button that would show some sort of horizontal meter in the display.. however, it looks like it may have been specific to Logic Pro, not Cubase.

Yeah the standard Cubase mapping has SHIFT and SMPTE/BEATS button that would normally turn the meters on/off, I get the feeling that the dots are what controls that meter and it's always being sent to the display but has nowhere to go so is going into each track.

I'm fairly sure that this is the issue the more I think about it, and easy to test if you remove the metering processchange function from triggering, by commenting out that entire block (/ and /), saving the .js file and then reloading the script in Cubase:

If you're comfortable doing this and it works, hopefully it will help @bjoluc to try and get it fixed properly?

[JDubs73]

THAT WAS IT!!!!

Oh man, this is so awesome. You were 100% correct. The track names are showing up now and are solid! Thank you so much for helping with this, to both of you! I'm not a developer, but am in IT, so I have a basic knowledge of coding (extremely basic). You have both just increased my mixing workflow so much it's not even funny.. I have been waiting for Steinberg to do something about this for years and it has just fallen on deaf ears, but thanks to the new Midi remote capability and smart people like you, it now is a reality!

I will try to test with my Extender at some point this week and let you know how it goes. In the meantime, if there is anything I can help with testing this for your release going forward, do not hesitate to ask.. I owe you both big time!

[JDubs73]

I couldn't wait.. :) I went ahead and pulled my Extender out of the closet and got it all wired up... and it is working perfectly too!

I am in DAW heaven right now.. you are both awesome!

Thanks!!

[u-man74]

Hi to all you guys :) ,

I will jump in here and demystify some of the topics regarding MCU and Level Metering. I will share my experience with the Mackie C4 Pro,

1. The Level Metering: My experience with Cubase is, i never did get "native" Level Metering working with my C4. Martin Jirsak wrote his own script to get Level Metering for a SINGLE channel and it performed very poor and not much responsive. This has much to do, because it is not done with "native" Level Metering and therefore needs way to much midi, to have something that is really responsive. "Native" Level metering is calculated internally by MCU devices and once activated, it need only Aftertouch CC for a single channel and this includes "printing" to displays too. This Aftertouch CC needs to be bound to the Peak Level meters only, because everything else is calculated internally by the device. This way, you dont need any Sysex to send to the displays and the reason, why it works way, way better than doing it by your own. Level Metering is a realtime process and it has to be processed as fast as possible. If you can not make "native" Level Metering working, then it is better to not doing it at all, IMHO. I can show you examples of other DAWs, with 32 Channels Level Metering, that looks nice and responsive and it doesnt matter if vertical or horizontal metering is used. If there is interest in Level Metering, i can provide even more info and maybe we can solve this problem all together.

2. The dots bug: I experience exact this behaviour, if too much midi is incoming at the same time. The midi messages will be cut off in half and then possibly resulting in this "dot" problem. A C4 has four displays, that needs to be fed via a Midi cable, therefore extra caution is needed to not exceed the midi-limits. Mind you, a single display does need two sysex messages, if you want to use both lines of it (one for top and one for bottom). You can not fully utilize both rows, with a single sysex or at least it is not recommended by documentation. For a C4 it means eight sysex messages for all four displays and that is a lot in terms of midi, if you build a page for example. The second thing what could cause this dot bug is, what i already wrote about "native" Level metering get to work. I am very sure it has to do with the Sysex-Header and it would perfectly explain, why it is working with the older MCU and does not work with the MCU Pro (the silver metal model). Each MCU device has its own Sysex header and this header includes a device id. If we assume now, that Steinberg wrote the implentation at a time, where only the older model existed AND did not do proper updates after the release of the newer MCU Pro models, then this would explain easily why it works for one model and not for the other. The "native" Level Metering needs a Sysex WITH a header send out by the DAW to activate it and to tell which mode is used (horizontal, vertical, single channel, multi channel (global)). Since the header includes a device ID, it could be the reason why it does not work on some MCU models.

If you want proper documentation on midi-implementation of the MCU, you need to get the "Logic7 Dedicated Control Surface Info" manual/PDF. Apple removed the midi-implementation of the MCU on any newer Logic manual versions. Mind you, it is the only manual to get the midi-implementation of the MCU, but it is very much complete if you ask me. The downside is, you need to be very familiar with the midi-standard and how it works, to understand that manual. Java scripting will not help you much here :D :) .

3. The "bad dimming" displays: This is a stupid rumour. The only thing bad from Mackie, are their power adapters that where delivered with the MCU devices. I bought many devices very, very cheap because of this. Once you use your own power adapter the display will start shining again in full glory. This way i have send a C4 to Martin Jirsak, so that he does not work in the blind. Also there are no differences regarding the software side of the many different MCU models. The only difference are the faders, which are superior in the MCU Pro devices and the firmware that controls them. For the C4, which has no faders, this means all C4 models (being black or silver) behave the same software wise. The only difference in software for the complete MCU family, is the device ID in the Sysex header, thats it.

If you are interested in this, i will gladly provide more help and info. My interest in solving this, is very high ;) .

[JDubs73]

Hi U-man,

Thank you for your input. I have no personal experience with the C4 Pro... I don't believe this script really has anything to do with that particular device, but I could be wrong.

I can say that after Support-AT provided his commenting out suggestion in the script, all of my displays are now working perfectly. I am seeing no dotted lines here now.

I am not going to debate what you said about the display dimming, other than to say that I had to replace two backlights in mine (Full Compass sells them) and the third time my displays were slowly dimming (at exactly the same rate) over time, I replaced them with the LUX PMVA LED Displays I mentioned and they have been bright and clear for the last couple of years with no dimming whatsoever. Maybe the new ones are not susceptible to the power supply issue that you mention, I'm not sure.

At any rate, with this new script and the edit that I made yesterday, my MCU Pro and Extender are finally working the way that I need them to.. When I had to stop and autobank to find the selected track it always took me out of my creative flow... for me, this new script is a total game changer.

[u-man74]

Hi U-man,

Thank you for your input. I have no personal experience with the C4 Pro... I don't believe this script really has anything to do with that particular device, but I could be wrong.

The C4 has many things in common with the MCU and is normally used as a extension device to the MCU, just like the extenders. Sadly Steinberg did not support it, but with the midi remote and scripting, you can get much out of it, even more then the MCU can, especially for parameters. Many things in this script here, can be used on the C4 too. Here and there it needs some changes, but this should not be a problem.

I can say that after Support-AT provided his commenting out suggestion in the script, all of my displays are now working perfectly. I am seeing no dotted lines here now.

So it has to do with the Level Metering i guess. Did it worked for you previously, if you just used the MCU protocol?

I am not going to debate what you said about the display dimming, other than to say that I had to replace two backlights in mine (Full Compass sells them) and the third time my displays were slowly dimming (at exactly the same rate) over time, I replaced them with the LUX PMVA LED Displays I mentioned and they have been bright and clear for the last couple of years with no dimming whatsoever. Maybe the new ones are not susceptible to the power supply issue that you mention, I'm not sure.

I just know that LUX PMVA LED Displays are very expensive (150 euros) and for a C4 i would need four of them. So it is cheaper to buy the whole new/used device, then to spend that on four displays. I "repaired" three C4 devices with dimmed displays, just by buying a new power adapter (20 euros). I let people decide, if that is a option for them. IMHO i would think twice before spending so much money for a display. They are excellent, no doubt, but waaaaay to expensive.

At any rate, with this new script and the edit that I made yesterday, my MCU Pro and Extender are finally working the way that I need them to.. When I had to stop and autobank to find the selected track it always took me out of my creative flow... for me, this new script is a total game changer.

That is nice to hear and i hope you will still looking in here, for further contributions.

[JDubs73]

The C4 has many things in common with the MCU and is normally used as a extension device to the MCU, just like the extenders. Sadly Steinberg did not support it, but with the midi remote and scripting, you can get much out of it, even more then the MCU can, especially for parameters. Many things in this script here, can be used on the C4 too. Here and there it needs some changes, but this should not be a problem.

I've seen these in pictures and always thought they would be a cool addition to the MCU family,, Cool to know that there are parts of this script that apply to the C4.

So it has to do with the Level Metering i guess. Did it worked for you previously, if you just used the MCU protocol?

Yeah, it worked fine previously with the built in Mackie control device setup in Cubase, no display issues there, only with the script. I never suspected that the issue was hardware related, because of that..

I just know that LUX PMVA LED Displays are very expensive (150 euros) and for a C4 i would need four of them. So it is cheaper to buy the whole new/used device, then to spend that on four displays. I "repaired" three C4 devices with dimmed displays, just by buying a new power adapter (20 euros). I let people decide, if that is a option for them. IMHO i would think twice before spending so much money for a display. They are excellent, no doubt, but waaaaay to expensive.

This is true, they are expensive. At the time I had two other displays completely die out (and I mean to the point where you couldn't read the text from my chair.) They cost me 100 bucks a pop to replace, So I was already down 200 bucks, and knew that the same thing would happen within a couple of years.. I was dreading the hassle.

I did a lot of reading on forums and found many other people with the same complaints, and at the time did not see a single person bring up the power supply issue. It would have saved me money for sure.. But, in my shoes at the time, I figured $175 for a panel that I should never need to replace again (yes, that is their guarantee) it just seemed like a no-brainer at the time. I bought one for the main MCU.. loved it, and a few months later bought a second one. Honestly, the new screens are so much brighter and have way better contrast.. easier on the eyes over long periods of time,

But having to buy 4 of them? Yeah, I totally see your point.

[bjoluc]

Thanks for jumping in @Support-AT, and thanks for all your efforts, both! @u-man74 Thanks for the input!

If you want proper documentation on midi-implementation of the MCU, you need to get the "Logic7 Dedicated Control Surface Info" manual/PDF.

I used this logic control manual for the MIDI mapping in this project and found that most of it applies to the MCU too, luckily.

The "native" Level Metering needs a Sysex WITH a header send out by the DAW to activate it and to tell which mode is used (horizontal, vertical, single channel, multi channel (global)).

And there we go, I completely forgot about the meter mode messages in the manual (page 118 of the one I linked above) after noticing I didn't need them for the X-Touches. I'll include the meter mode messages in the script of course ("Shift + SMPTE/Beats" – although I think "Shift + Display" would make more sense, but let's keep the list of deviations from the Cubase stock mapping short).

@Support-AT @JDubs73 I think we should have "Shift + SMPTE/Beats" switch between "no metering", "vertical metering", and "horizontal metering". Or should "vertical vs horizontal" be a config option? Also, am I right that the Cubase stock mapping only uses vertical metering?

My interest in solving this, is very high

@u-man74 Are you saying you're an MCU Pro user too? :partying_face:

[Support-AT]

I think we should have "Shift + SMPTE/Beats" switch between "no metering", "vertical metering", and "horizontal metering". Or should "vertical vs horizontal" be a config option? Also, am I right that the Cubase stock mapping only uses vertical metering?

Oh that'd be be nice to have a horizontal option yes - I don't really like the default Cubase vertical one as that takes up a character and it's off to the right, whereas horizontal would be directly above the fader/pot which is easier on the eye.

For me, toggling through those 3 modes on the button would be nicest, rather than something to change in the config file.

Curious where you'd put the horizontal option, would it occupy the first or second row?

[bjoluc]

Curious where you'd put the horizontal option, would it occupy the first or second row?

I can only say "Hey Mackie, use horizontal metering mode". Given the wonderful video @JDubs73 sent us at the peril of his young GitHub life, I suspect it will always be the second row. Which is a bit annoying w.r.t. track names. Put track names in the first row in that case?

[JDubs73]

I think we should have "Shift + SMPTE/Beats" switch between "no metering", "vertical metering", and "horizontal metering". Or should "vertical vs horizontal" be a config option? Also, am I right that the Cubase stock mapping only uses vertical metering?

I personally don't use the metering on the MCU Pro. As you mention, the vertical one in the standard MCU in Cubase is tiny, and takes up the last character in the track name, which I don't really like. I haven't found a horizontal meter with the stock mapping.

Personally, I would not want to lose the track names on the display for a meter, as these particular meters don't really tell me much, other than there is signal on the track.. they are just so small. That reminds me, one thing I noticed last night.. on the MCU pro there are these little "signal" leds on each channel.. they light up when there is something recorded on the track, which is kinda nice, I guess. They don't light up with the new script, only the stock mapping.

I really don't miss them though, with your script following the track selection, the big bright SELECT light tells me exactly where I am (so I'm not looking for where the signals are) and I have my metering up in Cubase anyway.

Given the wonderful video @JDubs73 sent us at the peril of his young GitHub life,

I'm like a baby bird popping it's Github head out for the first time :D

[Support-AT]

on the MCU pro there are these little "signal" leds on each channel.. they light up when there is something recorded on the track, which is kinda nice, I guess. They don't light up with the new script, only the stock mapping.

They work fine for me, maybe the code which you commented out as a quickfix removed it? I haven't adjusted mine as didn't get the glitching. Edit: Actually I'm not so sure, as just had a quick try and no signal light either - I was using Reaper the other night so may have been mistaken with that.

I'm sure @bjoluc will have it sorted! :)

[bjoluc]

Hey baby bird, if you click on a commit and select the "Checks" tab, there's an "Articats" drop-down menu where you can download the generated "scripts" archive for that commit. I added commit 4db21a1 which should solve the initial lower-row dots issue. Can you verify that's the case?

popping it's Github head out for the first time

Immediately being snacked by GitHub's hungry classification AI, so hungry the support cannot even provide non-generic reasons :facepalm:

[u-man74]

Hi bjoluc :) ,

I used this logic control manual for the MIDI mapping in this project and found that most of it applies to the MCU too, luckily.

Yes, that is the right manual and it is not most of it, it is ALL of it :D .

And there we go, I completely forgot about the meter mode messages in the manual (page 118 of the one I linked above) after noticing I didn't need them for the X-Touches. I'll include the meter mode messages in the script of course ("Shift + SMPTE/Beats" – although I think "Shift + Display" would make more sense, but let's keep the list of deviations from the Cubase stock mapping short).

It would be great to make it work (at least for me). Mind you, that it needs Peak Levels bound to Aftertouch CC. It will not work just by making the two button presses, if you only use your script alone.

@Support-AT @JDubs73 I think we should have "Shift + SMPTE/Beats" switch between "no metering", "vertical metering", and "horizontal metering". Or should "vertical vs horizontal" be a config option? Also, am I right that the Cubase stock mapping only uses vertical metering?

I would prefer switching, but you are the master :) and yes, Cubase has only vertical mode.

@u-man74 Are you saying you're an MCU Pro user too? 🥳

Sadly no, but i needed to learn the MCU in and out to reverse engineer it, so that i could use Bome MTP to translate it to my C4. This was the only way for me, to make some use of the C4 and Cubase. The third row of V-Pots on the C4 for example, behave the same like the ones on a MCU (minus the push functions). Thats why i am interested in your script ;) Level Metering is one of the things we could not get to work properly, since the "native" mode could not be activated.

Curious where you'd put the horizontal option, would it occupy the first or second row?

Its always the bottom line of the display

Put track names in the first row in that case?

That would be a option. I can wait until you can make it work. I have no signal LEDs on my C4, but i have four displays and plenty of space to show the Level Meters :D .

on the MCU pro there are these little "signal" leds on each channel.. they light up when there is something recorded on the track, which is kinda nice, I guess. They don't light up with the new script, only the stock mapping.

They work fine for me, maybe the code which you commented out as a quickfix removed it? I haven't adjusted mine as didn't get the glitching.

I'm sure @bjoluc will have it sorted! :)

AFAIK the signal LEDs on a MCU can not be controlled with a midi message. I guess they are a part of the Level Metering. I still think that the device IDs are the problem here and why it works on black MCU and not on the silver MCU. The manual is refering to the black one for sure, because the silver one did not exist at that time.

The sysex header and device ID is F0 00 00 66 10 for MCU (black model) The sysex header and device ID is F0 00 00 66 11 for MCU Xtender (black model) The sysex header and device ID is F0 00 00 66 14 for MCU Pro (silver model)

For a C4 it is F0 00 00 66 17 (for black and silver models i guess, but i could be wrong here). Maybe there are more device IDs, but i dont know more :) . You need more testers :D .

[Support-AT]

@JDubs73 Incase you can't find the new script with the fix, direct link is here.

[bjoluc]

Yes, that is the right manual and it is not most of it, it is ALL of it :D .

Well, it might be up to the X-Touch firmware only implementing a subset of MCU features, but I wasn't able to get the handshake logic from the manual to work. I noticed Cubase doesn't do it either though, so I figured it would not apply to MCU.

The sysex header and device ID is F0 00 00 66 14 for MCU Pro (silver model)

Interesting. How do you know?

I still think that the device IDs are the problem here and why it works on black MCU and not on the silver MCU.

So far I didn't send any meter mode messages via SysEx, so I don't think the device IDs can be an issue with the current script? The scribble strip display works on both MCU versions and uses the 10/11 model IDs.

[JDubs73]

Hey baby bird, if you click on a commit and select the "Checks" tab, there's an "Articats" drop-down menu where you can download the generated "scripts" archive for that commit. I added commit 4db21a1 which should solve the initial lower-row dots issue. Can you verify that's the case?

I just tested this and the lower-row dots issue came back on this new revision. Thanks

[u-man74]

Well, it might be up to the X-Touch firmware only implementing a subset of MCU features, but I wasn't able to get the handshake logic from the manual to work. I noticed Cubase doesn't do it either though, so I figured it would not apply to MCU.

I could not get the handshake working too, but i think Ron Garrison did with his C4 script. Might worth looking into it: https://forums.steinberg.net/t/mackie-c4-remote-script-v-1-03/782281 I think Steinberg was very lazy here, since they did not support the C4, there was only the Xtender left and a Xtender is the same like a MCU just with less buttons and jogwheel. Cubase does not need to distuingish between the two devices. I mean if you add a Xtender to your setup, you just add another MCU in the studio setup. They probably just put everything needed for a Xtender into the MCU component.

The sysex header and device ID is F0 00 00 66 14 for MCU Pro (silver model)

Interesting. How do you know?

I did extensive research and its also what Cubase is sending out with MCU enabled for my case.

I still think that the device IDs are the problem here and why it works on black MCU and not on the silver MCU.

So far I didn't send any meter mode messages via SysEx, so I don't think the device IDs can be an issue with the current script? The scribble strip display works on both MCU versions and uses the 10/11 model IDs.

I agree with the scribble strip display thing. This makes me really wonder why it is working. It does not work for sure on my C4, there i need to change that or i have nothing on my displays.

[bjoluc]

I agree with the scribble strip display thing. This makes me really wonder why it is working. It does not work for sure on my C4, there i need to change that or i have nothing on my displays.

Sorry, I was wrong about the IDs this project uses – it's 14 and 15 (extender) already. I remember having monitored the MIDI output at one point – I think that's where I got the IDs from. One more difference to the Logic Control docs :stuck_out_tongue: Forget the 10/11 IDs then. This also means IDs are not the problem. I'll keep investigating :)

[bjoluc]

I looked at Cubase's stock MC MIDI output again. It sends

F0 00 00 66 14 21 01 F7 // Set vertical meter mode
F0 00 00 66 14 20 00 01 F7 // Disable LCD metering for channel 1
F0 00 00 66 14 20 01 01 F7 // Disable LCD metering for channel 2
...
F0 00 00 66 14 20 07 01 F7 // Disable LCD metering for channel 8

at the end of initialization.

The draft from my last commit sends exactly the same messages, but omits the vertical meter mode. I'll include that one too to check if it makes a difference. @JDubs73 Can you try the script from my next commit (down below in the conversation)?

[u-man74]

Sorry, I was wrong about the IDs this project uses – it's 14 and 15 (extender) already. I remember having monitored the MIDI output at one point – I think that's where I got the IDs from. One more difference to the Logic Control docs 😛 Forget the 10/11 IDs then. This also means IDs are not the problem. I'll keep investigating :)

The Logic Control is the black MCU, so that is exactly why you should not ignore the 10/11 IDs. It would explain why skyjumptoes dont have the dot problem, because it ignores the 14/15 ID´s your script is sending. Also keep in mind, that just only sending "F0 00 00 66 14 21 01 F7" (Set vertical meter mode) will not work. In fact, it explain why we see only dots. You engage Level Metering, which expects incoming Aftertouch CC bound to Peak Levels. I assume you did not do that and therefore nothing happens, except seeing the dots. The Steinberg MCU will send out those Aftertouch CC, as soon as you enable Level Metering, but your script does not do that i guess. Please monitor Steinberg MCU again and you will see Aftertouch CC incoming (a lot of it), starting with "D0" followed by 00 to 07 (channel) and the value 00 to FF. Refer to page 118 of your manual.

[JDubs73]

Yep, I am away from the house today but will try it out later this afternoon and let you know. Thanks

[bjoluc]

The Logic Control is the black MCU

Sorry for being bold. I think the black MCU has a Logic Control mode and a Mackie Control mode, so I guess there are some subtle differences between the two of them.

so that is exactly why you should not ignore the 10/11 IDs

Cubase's stock implementation doesn't use these IDs though and metering still works for all the fine folks here. If Cubase does it, shouldn't we be able to do it too?

You engage Level Metering, which expects incoming Aftertouch CC bound to Peak Levels.

Right, that's what the script does and what drives the signal LEDs on the black MCU / meter LEDs on the X-Touch :upside_down_face:

[Support-AT]

Right, that's what the script does and what drives the signal LEDs on the black MCU / meter LEDs on the X-Touch 🙃

Just tried your latest commit, and signal light is working good for me ye olde MCU. :) (i've got one of the original emagic Logic control units here too, very old firmware, and that works fine too!).

There's no metering option in this commit is there? i.e. I shouldn't be testing shift+beats or anything.

[bjoluc]

There's no metering option in this commit is there? i.e. I shouldn't be testing shift+beats or anything.

You name it, but let's add one! It might also be interesting for comparing the two MCU variants :nerd_face:

[bjoluc]

@Support-AT This should do the trick :crossed_fingers:

[Support-AT]

@Support-AT This should do the trick 🤞

Well, it shows something... :) Not quite a meter though, it's those same dots that @JDubs73 had originally on line 2, and a smaller square that travels up and down where you'd expect the edge of the meter to be.

Is it a simple toggle on and off too?

If so when you toggle it off it doesn't reset back to the normal display unless you bank up and back down to get the screen to redraw.

[JDubs73]

I feel so validated ;)

[bjoluc]

Not quite a meter though, it's those same dots that @JDubs73 had originally on line 2, and a smaller square that travels up and down where you'd expect the edge of the meter to be.

Hah, I seem to have activated the peak meter. Cubase sends a different value here which – according to the Logic Control docs – would only activate the peak meter. Peak and level might be swapped in the MCU protocol. Any changes with the next commit?

[u-man74]

Sorry for being bold. I think the black MCU has a Logic Control mode and a Mackie Control mode, so I guess there are some subtle differences between the two of them.

What you are refering to here, are the different "emulation" modes you can use with the MCU i guess. I do not think these modes have any influence on the midi-implentation of MCU. This is stored in the firmware and with version 2.0 and higher, you even have three modes to choose from: Mackie, Hui and Logic. Maybe the only thing that changes here, I guess, is that the buttons are just sending different midi-note on/off messages, to match up those protocols.

Cubase's stock implementation doesn't use these IDs though and metering still works for all the fine folks here. If Cubase does it, shouldn't we be able to do it too?

Thats something that makes me wonder. On the other side, we dont know what the Steinberg MCU component does internally. I suggest you might do a test, where you print something to the display, using the different device ID´s. Something like "Black model" on top line for ID´s 10/11 and "Silver model" on bottom line of display for ID´s 14/15. If it is true what you say, we should see text on both lines for all models. So we can sort out this.

[bjoluc]

Is it a simple toggle on and off too?

It toggles between "no metering", vertical, and horizontal mode – in that order.

If so when you toggle it off it doesn't reset back to the normal display unless you bank up and back down to get the screen to redraw.

Hem, I might need to redraw the display then after deactivating the meters. I'll check if Cubase does that too natively.

[Support-AT]

Any changes with the next commit?

Ahhh... Now we're cooking! :)

1. Vertical meter is spot on, really nice and fluid actually - Not used it for a while but seems better than the original MCU one to me?
2. Horizontal one works good other than asterisks appearing as the last character randomly .
3. Disabling - as before, doesn't reset line 2 view so you have to go to next bank and back to get track names.

It'd be really nice if somehow line 1 could show track names when in Pan mode and metering is horizontal, I don't know how tricky that would be to implement though? Otherwise there's no way of seeing track names and horiz meters. :(

Feel a bit jealous of the X-Touch LED metering right now. hehe.

[bjoluc]

It'd be really nice if somehow line 1 could show track names when in Pan mode and metering is horizontal, I don't know how tricky that would be to implement though? Otherwise there's no way of seeing track names and horiz meters. :(

Right, I thought about that one. I'm tempted to do it regardless of the encoder assignment though – any objections?

Horizontal one works good other than asterisks appearing as the last character randomly .

Could it be a clip sign? :confused:

Feel a bit jealous of the X-Touch LED metering right now. hehe.

Well, you would need to get the cheaper device with more features for that :zany_face: :see_no_evil:

[Support-AT]

Right, I thought about that one. I'm tempted to do it regardless of the encoder assignment though – any objections?

Hmm, how hard would it to put it in the hands of the user if we shift+flip to pick if Line 1 and 2 are swapped globally perhaps? Just thinking that makes sense as a button combination and gives us some nice custom control.

Could it be a clip sign? 😕

That's what I hoped, but it wasn't that.
It looks as though the display needs a wipe before the horizontal mode is first rendered, as i'm not sure the horizontal meter reaches that last character, so it's a hang-up from the previous (vertical) mode perhaps?

Well, you would need to get the cheaper device with more features for that 🤪 🙈

...Let's not mention the colour screens and smaller form factor, right? lol :)

[bjoluc]

Hmm, how hard would it to put it in the hands of the user if we shift+flip to pick if Line 1 and 2 are swapped globally perhaps?

Great idea! Shift + Name/Value?

so it's a hang-up from the previous (vertical) mode perhaps?

Oh, for sure.

[Support-AT]

Great idea! Shift + Name/Value?

D'oh! Of course! That'd be even better on that combination. :) Maybe Shift+Flip could call Dua Lipa on speed dial to come over and drop some vocals for me?

[bjoluc]

Maybe Shift+Flip could call Dua Lipa on speed dial to come over and drop some vocals for me?

I'm afraid, we'll have to get her consent first. I'd suggest Shift + Redo anyway and spare you the pun.

[u-man74]

Does not the manual mention that you need a delay of 600 ms before you can print something new. "While the LCD switches between horizontal and vertical metering modes, it ignores LCD messages. You should delay LCD messages for at least 600 ms after sending an LCD metering mode change message."

[bjoluc]

Flipping the rows is possible now with "Shift + Display Name/Value" (10c6b83) :tada: @Support-AT @JDubs73 You should be able to use this to update the displays after using meter mode to get rid of any remaining meter characters (for the time being). Can you check whether the Logic Control manual is right about updates not being respected if sent less than 600 ms after the meter mode has been changed? This might also be the culprit with the initial glitchy behavior on the MCU Pro...

[JDubs73]

Ok guys, I just got home. Which one(s) would you like me to test? Sounds like a lot has happened today! Just this most recent one? Thanks