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?
 

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.

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

After a lot of messing around, I've found that this is nothing to do with two C4's.
 
The issue is with the Pro Channel compressor, when used with a control surface.
 
I can reliably cause an access violation in Cakewalk by either:
  - Switching the pro-channel compressor on/off with the mouse during playback; or
  - Changing any of the compressor settings using the C4
 
How fast I turn the knobs on the C4 does seem to have a bearing on this - i.e. turning the knobs fast makes it crash almost immediately, but even a very slow subtle change using the C4 can make it crash.
 
Switching the compressor on or off almost always results in a crash 1 or 2 seconds later.
 
Pro Channel EQ seems to be ok, but I can't be sure that the compressor is the only pro-channel module affected.
 
So far 3rd party plugins seem to be ok.
 
 

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

azslow3

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

Thanks Alexey.
 
I'm pretty sure I merged your workaround into the version I've got (the EQ fixes are definitely there), but I'll double check against your git repo.
 
There is a chance that it's a separate issue, but is definitely related as the crash doesn't happen when the display updates are disabled.
 
I'm in the office at the moment, but when I get back home I'll try removing the "Type" parameter from within MackieControl.ini and see if that helps at all.
 

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?
 

azslow3
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?

I've checked my branch, and the "Type" workaround is definitely there (MixParam.cpp line 342). My branch is basically all the changes from your dyneq branch, plus my workaround for the Korg NanoKontrol Studio / select button.
 
The crashing issue isn't restricted to the Type parameter though. Changing ANY parameter on the ProChannel compressor (either Channel 76 or S-Type Bus) will cause a crash with an access violation.
 
The weird thing is, that it doesn't happen immediately. I can alter the input gain, and the crash can happen a few seconds later. It also doesn't matter whether I made the parameter change via the C4 or via the GUI with a mouse - if the C4 is displaying that plugin at the time, the crash will happen.
 

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 tried the ProChannel compressor with just the MCU, and it doesn't crash... tried it again with the C4 and it did crash.
 
I'm going to try a few other things, like moving the C4 to the MIDI device that the MCU is currently using just to rule my MIDI hardware out.
 
If the crash still happens, I'm going to assume it's one of two things:
 
1. It's something specific in the C4 implementation or
2. The base class is assuming a reply to a sysex request is a common length/format, whereas in fact the C4 is returning a different length message and it causes an access violation.
 
If I can't attach a debugger, I'll try some logging and/or MIDI port monitoring.
 
Hopefully I can track this issue down.