Mackie C4 Progress

[RandyHyde]

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.

[beatpete]

Randy:
This is very cool! Let us know how it goes and maybe post a pic or two.
BTW, I've constructed a few TouchOsc templates for Cubase but could never figure out how the Mackie Control Protocol deals with track naming on the display. Can you shed any light on this?
Peter

[grecoaudio]

+1 on the Ethernet control surface interface

[RandyHyde]

Randy:
This is very cool! Let us know how it goes and maybe post a pic or two.
BTW, I've constructed a few TouchOsc templates for Cubase but could never figure out how the Mackie Control Protocol deals with track naming on the display. Can you shed any light on this?
Peter

Oh, you don't want to know about the display....

In theory, it's quite simple. SAC sends a sysex command of the form:

F0 00 00 66 14 12 <ofs> <text> F7

where <ofs> is a value in the range 0..112 (56*2) and <text> is the sequence of ASCII characters to write to the display.

The hard part is figuring out what to do with the text when it arrives.
On the C4, I had to extract the text from a single MCU display and spread it around four separate C4 displays. Figuring out which display to write the data to was the hard part.



Here's the code I use to write to the C4 display:

// writeDisplay:
//
//	Writes a string to one of the Mackie C4's four different displays.
//
//	display: 
//		1..4 specifying the display to change (1 is top display, 4 is bottom).
//
//	offset:
//		zero-based offset into the specified line on the display.
//		Must be in the range 0..111.
//
//	Note that character positions 0..55 are the first line of the display and
// character positions 56..111 are the second line of the display.
	
method mackieC4_t.writeDisplay( display:dword; offset:dword; theString:string );
var
	zLen	:dword;
	c4Buf	:byte[256];
	
begin writeDisplay;

	push( eax );
	push( ecx );
	push( edx );

	if( display in 1..4 ) then
	
		thread.enterCriticalSection( this.midiCS );
		
			if( offset > 2*56 ) then
			
				mov( 2*56, offset );
				
			endif;
			str.length( theString );
			mov( offset, ecx );
			add( 2*56, ecx );
			if( eax > ecx ) then
			
				mov( ecx, eax );
				
			endif;
			mov( eax, zLen );
			
			mov( (type byte display), al );
			add( $2f, al );	
			mov( offset, ecx );
			mov( sysex_c, c4Buf[0] );
			mov( 0,   c4Buf[1] );
			mov( 0,   c4Buf[2] );
			mov( $66, c4Buf[3] );
			mov( $17, c4Buf[4] );
			mov( al,  c4Buf[5] );
			mov( cl,  c4Buf[6] );
			mov( theString, edx );
			for( mov( 0, ecx ); ecx < zLen; inc( ecx )) do
			
				mov( [edx+ecx], al );
				mov( al, c4Buf[ ecx+7 ]);
				
			endfor;
			mov( $f7, c4Buf[ ecx+7] );
			add( 8, ecx );
			this.sendSysexNoCS( c4Buf, ecx );
	
		thread.leaveCriticalSection( this.midiCS );
	
	endif;
	pop( edx );
	pop( ecx );
	pop( eax ); 

end writeDisplay;

[RandyHyde]

Randy:
This is very cool! Let us know how it goes and maybe post a pic or two.
BTW, I've constructed a few TouchOsc templates for Cubase but could never figure out how the Mackie Control Protocol deals with track naming on the display. Can you shed any light on this?
Peter

Attached are the pix.

I'm running the C4 on a Macbook Pro running SAC Remote under Parallels/XP. Not willing to take the chance of running it on my host machine during testing.
Cheers,
Randy Hyde

[RandyHyde]

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.

Just a follow up on testing last night.
The code ran fine (no hangups or any other problems).
Running on SAC Remote v2.8 on a Macbook pro running Windows XP under Parallels (note that the mouse buttons don't work well in this configuration, but I didn't need them to test the C4 code).

Host was my "B" rig, running SAC v2.8 on an i3 motherboard with XP.
Was also using an HP TouchSmart running SACRemote on Win 7.

Overall, the test was good. The knobs weren't quite as responsive as I would have liked (as Bob points out, there is a *tremendous* amount of information sent via MIDI to the Mackie MCU). For the most part, I found that writing all the parameter data to the C4 scribble strips was largely a waste of time because I was almost always looking at the SAC screen.

This morning I went back and ifdef'd out all the display code and put a description of what pressing each VPot button does on the second line of the display (so the display information is completely static, it is not rewritten during the operation of SAC). With this change you have to read the parameter data from the W mixer window, but operation is very snappy and you don't have the coherence problems that exist with the former version that writes to the display.

In a sense, it's a shame that SAC can't support the scribble strips on the C4 very well. Effectively, the C4 becomes a very expensive BCR-2000 that uses scribble strips instead of the labeling tape I've stuck on the Behringer unit (see photo below). However, for the $500 extra that the C4 costs:

1) I get something that doesn't quite look like a kludge (the BCR-2000 with the labeling tape looks fairly gross),

2) I get a unit that doesn't have the "Behringer Badge of Shame" on it, and

3) I don't have to worry as much about Behringer's famous reliability (granted, I've never had any problems with the BCR-2000, but their reputation precedes them).

Probably not worth an extra $500 to most people, but it works for me.

I'll revisit this project when the ethernet interface to control surfaces appears.
Cheers,
Randy Hyde