SONAR and MCU Track SELECT Function [Answered]

I'm on my second MCU emulation for the Mackie d8b console, the first being the now abandoned BluAudio D8Bridge v1.1 MCU interpreter and more recently the ProBox MCU interpreter.  The idea is simple enough - take the native RS232 serial comms that normally passed between the Mackie d8b console and it's CPU and translate the various button presses, fader moves, LEDs, etc., to the equivalent MCU MIDI-speak for the DAW, and vice versa.  The D8Bridge did it in software running inside the DAW.  The ProBox does it in an external firmware box that sits between the DAW and the d8b console.  For the most part, both of these solutions do what they are supposed to and pretty well at that, with one exception, and that is the behavior of the control surface SELECT button in SONAR.
 
I thought I had gotten solid confirmation from some MCU using forumites that for their real deal MCUs the SELECT button did exactly what you'd think it should, select the track and reflect that selection in the SONAR GUI (and vice versa from within SONAR).  But looking back through some forum posts on the subject it looks as though not everyone has had flawless performance from this MCU SELECT button functionality.  Also, there are reports from users of other DAWs that this SELECT functionality works as expected for both D8Bridge and ProBox.
 
If you are using an MCU or some other type of MCU emulator, could you please report on your experience with MCU SELECT functionality in SONAR using your control surface?  Thanks!

azslow3
Can you check that your solution is sending correct MIDI when you use Select buttons? They should be on Channel 1, Notes 24, 25, 26 and so on.
 
The simplest way to check is temporarily change Macke Control plug-in input in Control Surfaces preferences of Sonar to something else and record Omni MIDI track pressing these buttons.

Some time ago I was on a quest to solve this problem and did a MIDI-Ox sniff on the D8Bridge v1.1 comms.  Granted it's not the newer ProBox comms but the behavior is identical.  Here's a snippet.
 
(Edited to fix bizarre font formatting in [code][/code] section.)
 
; Channel 1 SELECT (Channel 2 was previously selected)
TIMESTAMP IN PORT    STATUS DATA1 DATA2 CHAN NOTE EVENT              
002BE72B  01. --     90     18    7F    1    C 1  Note On     ;SEND (90 = Switch Pressed/Released, 18 = SELECT Ch. 1, 7F = Pressed)
002BE74B  02. --     F0 Buffer:   28 Bytes   System Exclusive    
SYSX: F0 00 00 66 14 12 00 20 54 72 61 64 6B 20 41 4A 20 22   ;RECV VFD String...
SYSX: 54 72 61 64 6B 20 41 22 20 F7
002BE74B  02. --     90     18    7F    1    C 1  Note On     ;RECV (90 = LED Status, 18 = SELECT Ch. 1, 7F = On)
002BE74B  02. --     90     19    00    1    C# 1 Note Off    ;RECV (90 = LED Status, 19 = SELECT Ch. 2, 7F = Off)
002BE79B  01. --     90     18    00    1    C 1  Note Off    ;SEND (90 = Switch Pressed/Released, 18 = SELECT Ch. 1, 00 = Released)
002BED27  02. --     F0 Buffer:   28 Bytes   System Exclusive    
SYSX: F0 00 00 66 14 12 00 54 72 61 64 6B 41 20 54 72 61 64   ;RECV VFD String...
SYSX: 6B 42 20 54 72 61 64 6B 44 F7

; Channel 2 SELECT (Channel 1 was previously selected)
TIMESTAMP IN  PORT   STATUS DATA1 DATA2 CHAN NOTE EVENT              
002CFB4D  01. --     90     19    7F    1    C# 1 Note On     ;SEND (90 = Switch Pressed/Released, 19 = SELECT Ch. 2, 7F = Pressed)
002CFB44  02. --     F0 Buffer:   28 Bytes   System Exclusive    
SYSX: F0 00 00 66 14 12 00 20 54 72 61 64 6B 20 42 4A 20 22   ;RECV VFD String...
SYSX: 54 72 61 64 6B 20 42 22 20 F7
002CFB44  02. --     90     18    00    1    C 1  Note Off    ;RECV (90 = LED Status, 18 = SELECT Ch. 1, 00 = Off)
002CFB44  02. --     90     19    7F    1    C# 1 Note On     ;RECV (90 = LED Status, 19 = SELECT Ch. 2, 7F = On)
002CFBEB  01. --     90     19    00    1    C# 1 Note Off    ;SEND (90 = Switch Pressed/Released, 19 = SELECT Ch. 2, 00 = Released)
002D0120  02. --     F0 Buffer:   28 Bytes   System Exclusive    
SYSX: F0 00 00 66 14 12 00 54 72 61 64 6B 41 20 54 72 61 64   ;RECV VFD String...
SYSX: 6B 42 20 54 72 61 64 6B 44 F7
 
So it looks as though what's being sent is consistent with the Logic Control specification.  Everything else in the interface that should be translating (fader moves, channel LED ladders, MUTE, SOLO, etc.) appears to behave as it should.
 
I'd also be interested in hearing from folks with different control surfaces what their experience is with the SELECT button functionality.
 
I have Studio One and Reaper licenses I seldom use but I may try out the d8b/ProBox MCU emulation on them and see if I get different SELECT button results on different DAWs.
 
Some old posts on the subject -
http://forum.cakewalk.com/X2-MCU-Users-and-X2-d8bD8Bridge-Users-SELECT-Button-Behavior-m2783208.aspx
http://forum.cakewalk.com/Mackie-Control-problems-m1077909.aspx?high=mcu+select+button
http://forum.cakewalk.com/New-to-Mackie-MCU-and-sonar-m1569864.aspx?high=mcu+select+button
 
Weren't Cake going to spend some time scrubbing this MCU control surface processing?  Thanks for your interest.
 

azslow3
Taking old posts into account...
 
Have you set "Select highlights track" checkbox in the "Options" section of MackieControl plug-in? Without this option set, while the Track is selected for future operations from the surface, it is not focused in Sonar (it does not try to ask Sonar to focus it).
 
2 notes:
1) Select button "focus" track, so you see Track Inspector for it and it's name is highlighted in the track/console view. But that does not "select" the content of this track (recognized by highlighted strip number box in the track view). "Select focused track" operation (different button) can select wrong track under some conditions, that is Sonar bug (with track view window focused for keyboard, current "focused" track is keyboard/mouse internal. The effect is near the same as with MCU with "Select highlights track" unset, keyboard simply ignore focus changes in Sonar which are produces by Control Surfaces and use what it think was the last one focused with keyboard or mouse).
2) these buttons do not work with Buses (by design).
 
PS. Everyone can "scrub MCU control surface processing", it is Open Source now. There are not many users (at least known) who can understand/compile/fix that staff, but I am one of them

So you're referring to this post? -
 
http://forum.cakewalk.com/Open-sourcing-control-surface-SDK-and-code-for-the-VStudio-700-and-Mackie-surfaces-m2898815-p2.aspx
 
I was wondering if that was still happening but I just saw you had a recent post to the thread.  Maybe there's hope!
 

azslow3
Have you set "Select highlights track" checkbox in the "Options" section of MackieControl plug-in? Without this option set, while the Track is selected for future operations from the surface, it is not focused in Sonar (it does not try to ask Sonar to focus it).

 
I somehow overlooked this in the MCU DLL.  I am anxious to get back to SONAR later today and check it out.  Thank you very much!

I am glad I could help
 
I have only started my Control Surfaces journey at 2013. These days I have more experience. I have separate thread about my "moded" version of MackieControl, with ProChannel EQ/Compressor fix. There I have also mentioned that questions or future improvements suggestions are welcome.