RandyHyde
01-02-2012, 03:28 PM
Hi All,
For the past couple of weeks I've been working on a program that translates Mackie MCU midi transmissions from SAC to a form that is compatible with the Mackie C4.
For those who don't know about it, the Mackie C4 control surface is a set of 32 knobs (vpots) with ring LEDs and four 2-line scribble strips. It's basically four copies of the vpots and scribble strips at the top of the Mackie MCU.
My goal with this was to do as I'd done with the Behringer BCR-2000 (which also has 32 knobs) and use it to control most of the parameters on the wide mixer view. In addition to supporting the knobs, I wanted to support the scribble strips and ring LEDs (the BCR-2000 has no scribble strips and I don't support the ring LEDs on the BCR-2000, though I might revisit that issue now that I've written the C4 code).
A few minutes ago I finally got the C4 code functional. Subject to a few limitations imposed upon me by SAC, I use 15 knobs to control the parametric EQ (5 channels of Q, Frq, and gain), hi cut, low cut, Aux1..Aux6 level, attenuator level, gate attack/release/floor/threshold, and compressor attack/release/ratio/threshold.
Quite frankly, this project was a *lot* more work than I anticipated (about 6,000 lines of code). The problem was picking off the display information that SAC writes to a single Mackie MCU display and distributing that string data across four displays. Unfortunately, SAC writes portions of the display at (seemingly) random times without a good indication of the type of data being written. So I wrote a huge hack to heuristically determine where each string should be written. The heuristics consist of looking at the last six characters of the second line of the display (which doesn't always work because SAC sometimes writes the display mode to this location *after* it's written the associated data elsewhere on the display), parsing each string to see if it's a valid value to write given the current mode, and then looking for "enable signal LED" MIDI messages which seem to precede most mode changes.
The heuristics are perfect. In particular, level values in dB (e.g., attenuator, Aux Send levels, and thresholds) look all the same. So on a rare occasion it is possible for one level value to be written in a display location where it doesn't belong.
Another problem is that any changes made in SAC aren't automatically reflected back onto the appropriate C4 display. The problem is that SAC will only update the display with a given parameter if that parameter is currently displayed on the Mackie MCU's single display. That's rarely the case when using the C4's four separate displays.
I tried to automatically force SAC to update all the displays on a regular basis (by sending MIDI commands to switch between the various display modes). However, this creates too many MIDI messages and SAC (or somebody) starts throwing away messages, making things even worse.
I did program a single button to update all the displays on the C4. That works well as long as SAC isn't currently transmitting data to the C4 display.
Despite the issues, the C4 control surface is a big improvement over the BCR-2000 code I'd written a while back. Seeing all the parameters on the displays, along with labels describing each button, is a big help. I've only played around with the C4 using SAC Remote (not live). I'm going to drag the C4 to a show with me this evening and try it out at a non-critical time and see how it works. The BCR-2000 was a *big* improvement for adjusting wide-mixer parameters; I'm expecting good things from the C4, too.
Will be interesting to see how SAC v2.9's changes to the MIDI templates will affect my heuristics.
Cheers,
Randy Hyde
P.S. I was hoping to write a single program to control a C4, MCU, and 3 XT units. Sadly, because of MIDI bandwidth issues, that will not be possible. Hopefully Bob will come up with something good for the ethernet control surface interface that will allow me to write that code in the future. In the meantime, I'm stuck running each Mackie control surface in a separate instance of SAC.
For the past couple of weeks I've been working on a program that translates Mackie MCU midi transmissions from SAC to a form that is compatible with the Mackie C4.
For those who don't know about it, the Mackie C4 control surface is a set of 32 knobs (vpots) with ring LEDs and four 2-line scribble strips. It's basically four copies of the vpots and scribble strips at the top of the Mackie MCU.
My goal with this was to do as I'd done with the Behringer BCR-2000 (which also has 32 knobs) and use it to control most of the parameters on the wide mixer view. In addition to supporting the knobs, I wanted to support the scribble strips and ring LEDs (the BCR-2000 has no scribble strips and I don't support the ring LEDs on the BCR-2000, though I might revisit that issue now that I've written the C4 code).
A few minutes ago I finally got the C4 code functional. Subject to a few limitations imposed upon me by SAC, I use 15 knobs to control the parametric EQ (5 channels of Q, Frq, and gain), hi cut, low cut, Aux1..Aux6 level, attenuator level, gate attack/release/floor/threshold, and compressor attack/release/ratio/threshold.
Quite frankly, this project was a *lot* more work than I anticipated (about 6,000 lines of code). The problem was picking off the display information that SAC writes to a single Mackie MCU display and distributing that string data across four displays. Unfortunately, SAC writes portions of the display at (seemingly) random times without a good indication of the type of data being written. So I wrote a huge hack to heuristically determine where each string should be written. The heuristics consist of looking at the last six characters of the second line of the display (which doesn't always work because SAC sometimes writes the display mode to this location *after* it's written the associated data elsewhere on the display), parsing each string to see if it's a valid value to write given the current mode, and then looking for "enable signal LED" MIDI messages which seem to precede most mode changes.
The heuristics are perfect. In particular, level values in dB (e.g., attenuator, Aux Send levels, and thresholds) look all the same. So on a rare occasion it is possible for one level value to be written in a display location where it doesn't belong.
Another problem is that any changes made in SAC aren't automatically reflected back onto the appropriate C4 display. The problem is that SAC will only update the display with a given parameter if that parameter is currently displayed on the Mackie MCU's single display. That's rarely the case when using the C4's four separate displays.
I tried to automatically force SAC to update all the displays on a regular basis (by sending MIDI commands to switch between the various display modes). However, this creates too many MIDI messages and SAC (or somebody) starts throwing away messages, making things even worse.
I did program a single button to update all the displays on the C4. That works well as long as SAC isn't currently transmitting data to the C4 display.
Despite the issues, the C4 control surface is a big improvement over the BCR-2000 code I'd written a while back. Seeing all the parameters on the displays, along with labels describing each button, is a big help. I've only played around with the C4 using SAC Remote (not live). I'm going to drag the C4 to a show with me this evening and try it out at a non-critical time and see how it works. The BCR-2000 was a *big* improvement for adjusting wide-mixer parameters; I'm expecting good things from the C4, too.
Will be interesting to see how SAC v2.9's changes to the MIDI templates will affect my heuristics.
Cheers,
Randy Hyde
P.S. I was hoping to write a single program to control a C4, MCU, and 3 XT units. Sadly, because of MIDI bandwidth issues, that will not be possible. Hopefully Bob will come up with something good for the ethernet control surface interface that will allow me to write that code in the future. In the meantime, I'm stuck running each Mackie control surface in a separate instance of SAC.