CbB/Sonar crashing with Mackie C4's when controlling ProChannel Compressor [Solved]

I've just added another Mackie C4 to my setup, so it now has:
 
1 x Mackie MCU
1 x Mackie XT
2 X Mackie C4
 
The setup appears to work in that I can control two separate sets of plugins on each C4 - but it crashes when changing values.
 
Is more than one C4 supported?
 

mettelus
There have been reports of hardware with identical IDs (2 identical MIDI controllers) being only seen as one and I forget offhand if there was a workaround for this. Are you seeing 2 separate C4s in CbB preferences or only one?

IIRC, Bob Bone had a thread about this several months ago.

I'm using the older MIDI based C4, so there's definitely two listed.
 
However, you may be on the right track....
 
I've only just started looking into this, but looking at the Cakewalk Mackie Surface SDK code, each Mackie device registers itself as it is loaded, and gets added to a list of devices in a common structure. The way the MackieControl.dll knows which unit is which within this list is by serial number. The SYSEX query to retrieve the serial number is (at least in the code) common to all units - i.e. the same sysex message for MCU,XT,C4.
 
My current theory is that the C4 has a different sysex query, meaning that the C4 ignores this query and the MackieControl.dll never gets the serial number back, and the two C4's end up with indentical blank serial numbers.
 
I've not got access to the C4's sysex commands, so there's no way to quickly check if my theory is correct, but I can probably prove my theory by giving each C4 a random serial number to start with.
 
[Update] - It's definitely not the serial number, this is coming back fine from both devices and they're different. Changes on the 1st C4 are no problem at all. Making any changes on the 2nd C4 causes a crash shortly afterwards (i.e. 1 to 2 seconds later).

msmcleod
The issue is with the Pro Channel compressor, when used with a control surface.

Sorry that I have not replied you early...
 
Yes, that is known issue the Compressor "Type" parameter name (so just the string "Type"). On any surfaces which display parameter names.
 
You can check: http://www.azslow.com/index.php/topic,341.0.html for a workaround (that is GitHub branch).
 
 

It can be you hit yet another bug in the Compressor, but note that ProChannel general workaround and Compressor "Type" workaround are different. Can it be you have applied one change but not another?
 

That will not help much... but I have checked right now with AZ Controller and CbB (so the same procedure from Sonar perspective, just different in the plug-in part), all parameters of both types Compressors (except type parameter itself for Track compressor, I guess my own problem in the code) are working correctly. And nothing is crashing on changes/switches. That means it can work (well, AZ Controller is using "optimized" approach when looking for changes, MackieControl is more "brute force")
 
I do not have C4 nor any emulator for it. Can you check that it is also crashing with just MCU when switched into Compressor mode, (just for consistency) with my original mod? If yes, I probably can find the problem.

I've tracked down the issue.
 
The short story is that the "Type" workaround is never called on the C4 for a default ProChannel setup, and it's down to the following:
 
Selecting "EQ" from the C4 always brings up the 1st ProChannel plugin regardless of whether it's a type of EQ or not. So for a default ProChannel setup, pressing "EQ" always brings up the Track Compressor.
 
However, scrolling through the list of plugins does only show other EQ plugins.
 
A similar thing happens with dynamics, in that the "Dynamics" button always brings up the 2nd ProChannel plugin regardless of its type, but scrolling through any other plugins in the list only shows Dynamics plugins. For a default ProChannel setup, pressing "Dynamics" always brings up the EQ.
 
The Type workaround checks to see if it's the "Type" parameter, but also if filter type is "Dynamics" - however on the C4, you have to either select "Plugin" or "EQ" to get to the Track Compressor if it's the first ProChannel plugin. So the filter type is never dynamics for a default ProChannel setup, and the workaround code never gets called.
 
So half of the fix would be to sort out the EQ & Dynamics buttons and make sure they're checking the ProChannel plugin type before selecting it. This would ensure the type workaround gets called... however if you navigate to the Track Compressor using the "Plugin" button, the workaround code still wont get called.
 
A safer fix (the 2nd half of the fix) might be to set a flag somewhere to say the current plugin is actually the Track Compressor (maybe by checking it's name - as it has to send this to the plugin anyhow, or it's VST identifier if that's available), and check this flag in the Type workaround instead of the filter type.
 
For the moment though, removing "Type" from MackieControl.ini stops the crash from happening.
 

I've got a fix - just tidying it up and doing a bit more testing before I commit.
 
The EQ / Dynamics button issue is to do with the host name changing from "SONAR" to "Cakewalk". This meant that the flexible ProChannel flag was always false, and hence it didn't "look" for the correct class of plugin. Adding in another clause for "Cakewalk" fixes this.
 
I've also improved the "Type" workaround by setting a "current plugin is track compressor" flag when it retrieves the plugin information. This is passed down during the binding to the MixParam class and is checked instead of the plugin filter type. This makes the workaround safe when using the "Plugin" button as well as the "Dynamics" button.
 
I'll let you know once it's committed to GitHub and point you to the location so you can merge the changes in to your branch.