d8b Select Button / Sonar X2

[bitSync]

Cakewalk DID change something in the MCU implimentation on X2, I don't know if this was addressed with X2a, as the focus of the "A" update was mostly Touch screen functionality along with many little improvements. There is much chatter on the Cakewalk forums about MCU issues. I'm wondering if something in the Touchscreen functionality altered the MCU functionality somehow? When you added the other Control surface back in and the original message disapeared, do you still have to reconfigure the D8Bridge everytime you start?

@Axeman098,

Thank you for your interest in this topic. I have submitted a bug report for Sonar X2a requesting that Cakewalk do a thorough inspection of the mackiecontrol.dll behavior and fix any and all issues in X2b. We'll see...

After adding the TranzPort back in, the VFD message to "Please intialize your DAW" is still there. And yes, every time I boot Sonar X2a I go in and reconfigure track Vpots 1, 9, and 17 so my D8Bridge is correctly mapped. That in itself is not a big deal, a little annoying. The non-functionality of the SELECT buttons is a pain. There are a couple other things that aren't working also. I'm working my way up to some serious diagnostics, but I have discovered that D8Bridge is sending Sonar a MIDI message when the SELECT button is depressed, and Sonar X2a is responding with a message to extinguish the formerly lighted SELECT LED, another message to illuminate the newly selected track's SELECT LED, and is sending SysEx messages to the VFD to momentarily name the newly selected track and then to restore the track list to the VFD a couple seconds later. Nice. Except that Sonar X2a itself is not acting upon the SELECT message it receives to select the new track. So it looks like all the MCU interface stuff is happening OK, but Sonar is not acting on the message within the application, i.e., actually selecting the track. SELECT worked fine for with D8Bridge v1.1 and Sonar Producer 8.5.3 x64.

I heard from FBB on the X1/X2 forum that his real deal Mackie MCU SELECT functions properly in X2a, which causes me to think maybe something's going on or not going on with the initialization between Sonar X2a and D8Bridge. I still have a lot of diagnostics to do, but that's my current best theory. It's not too difficult to build a comprehensive MIDI Implementation of the MCU for things like button presses, LED illuminations, etc. And the VFD messaging, channel meter mode messaging, etc. appears to be largely a holdover from the Logic Control SysEx protocol from 2002. The tricky bit (since the MCU Mackie Control protocol spec is not freely published by Mackie) is knowing the proper MCU startup and initialization sequence. Logic Control had (still has?) a verification algorithm at startup, a formula for Emagic Logic to execute to convince Logic Control that it was actually talking to Emagic Logic (or something that knew exactly how to talk like Emagic Logic). That initialization information just isn't freely available for the Mackie Control protocol.

I am now living in MIDI-OX land and am working on a strategy to collect enough MCU forensics to give Marc and Cakewalk whatever they need to get this D8Bridge/X2 interface bulletproof. As far as the D8Bridge SELECT button implementation goes, right now it looks to me like D8Bridge is doing exactly what it's supposed to. Sonar X2a appears to only be handling the mechanics of the MCU SELECT protocol (LEDs and VFD messages) without actually acting on it inside the application.

Stay tuned for more...

[Axeman098]

VERY cool! Nice to see you've done your homework on the issue. I'll be VERY interested to know what else you find. I have noticed a LOT of folks referencing 8.5.3 to X2.....but uhm, where did I miss mention of the Track Select Button behavior in X1? Has anyone determined if this was also an issue on X1??? I would think determining "where" in the Versioning timeline this presented itself would also aid in nailing it down and fixing it... I haven't taken the D8Bridge plunge yet, but I am VERY close to ordering. I really want to see or hear from Marc himself what the deal is with an updated version. It feels like the push for the newer Ethernet and Mac solutions has waned a bit, and I'd like to see where development is going before spending the $. There are a LOT of newer control surface solutions coming out all the time, and some are downright awesome. I would LOVE to use my D8B Audio I/O in future updates, and this is really the area I want to see more on, before commiting to the D8Bridge investment. I like where it's going, but there really hasn't been much "visible" progress in the last few months, at least not displayed here. I am very interested in some of the ideas and options Marc indicated he was working on for the next update, but info has been sparse recently.

[bitSync]

...but uhm, where did I miss mention of the Track Select Button behavior in X1? Has anyone determined if this was also an issue on X1???

I actually skipped over X1, a, b, c, and d. There was so much angst on the Sonar boards about X1 that, although I purchased the license, I never installed it. So my experience goes directly from 8.5.3 x64 straight to X2 x64.

[Axeman098]

I used X1a-d with few if any issues. I think after the first update, most of the stability issues were ironed out. I never had a big problem with it at least....

I went and re-read your post a few times, so you're saying it looks like D8Bridge is doing what it is supposed to, but Sonar X2 isn't??? If that's the case, good luck getting Cakewalk to fix it. I'm curious if an actual Mackie MCU has the same button issue?? If I'm understanding what you're saying correctly, then it should.....and that might cause them to work on it a bit more...

[bitSync]

...so you're saying it looks like D8Bridge is doing what it is supposed to, but Sonar X2 isn't??? If that's the case, good luck getting Cakewalk to fix it. I'm curious if an actual Mackie MCU has the same button issue?? If I'm understanding what you're saying correctly, then it should...

As far as the actual SELECT message MIDI exchange goes, I think D8Bridge is doing what it is supposed to, and Sonar X2a appears to also be doing what it is supposed to, strictly from an MCU MIDI interface perspective. I say this without any real confidence because the actual Mackie Control protocol is unavailable to the general public. The Logic Control protocol, however, is available and it appears to share much (but not all) in common with the Mackie Control protocol. When a SELECT button is depressed on the d8b, the seemingly correct 0x90 button press message goes to Sonar X2a and Sonar X2a sends a 0x90 message to extinguish the currently lighted SELECT LED and illuminate the newly selected SELECT LED, then Sonar X2a sends the 0x90 button release message when the user's finger lets the button up. All of the appropriate VFD (LCD in MCU-speak) SysEx strings are written to the display as expected. The messages go across and the correct SELECT button LEDs extinguish and illuminate (so Sonar X2a has kept track of the previously selected track so as to extinguish its LED). What doesn't happen is Sonar X2a doesn't select the selected track inside the application; there is no change in the GUI. Also, selections made in the Sonar X2a GUI by mouse click do not send any MCU LED MIDI messages to D8Bridge; the track selections are made with the mouse in the Sonar X2a GUI but D8Bridge never hears about it. So, the mechanics of the message sending from D8Brige to Sonar X2a and the LED response from Sonar X2a to D8Bridge look reasonable, but Sonar X2a is not acting on the communications, and Sonar X2a is not informing D8Bridge of selections made by mouse inside the GUI.

What I don't know about is how well the Sonar X2a and D8Bridge initialization is complying with the MCU interface spec. If the initialization is screwed up, yes, maybe the SELECT messages going back and forth look OK but perhaps Sonar X2a is incorrectly initialized with D8Bridge which may adversely affect subsequent behavior. This is my current working theory; I won't be able to substantiate or refute it until I have an MCU and a couple XTs at my disposal to sniff. I suspect some initialization problems since Sonar X2a is trying to intialize with 1 MCU (SysEx Model ID == 0x14) and 2 XT (SysEx Model ID == 0x15) surfaces and D8Bridge seemingly ignores that and is acknowledging with 3 MCU surfaces (SysEx Model ID == 0x14).

Here's the wiggity whack part - a real deal MCU with Sonar X2a interoperates correctly with respect to the SELECT button functionality. I confirmed this with two Sonar X2a / MCU users on the Sonar X1/X2 forum. So, the D8Bridge interface with Sonar X2a is somehow different than the MCU interface with Sonar X2a.

I think Cakewalk is looking at Sonar's mackiecontrol.dll right now in support of the next build because they've had some complaints about the new ProChannel operation with the MCU (I got a recent notification about an MCU problem report I filed), but I don't think they'll find a problem with the MCU SELECT button implementation; if the SELECT button functionality works with an actual MCU, what is there to fix?

[bitSync]

I'm finally closing the loop on my SELECT button issue with D8Bridge v1.1 x32 and SONAR. The short story is that there is no issue, the problem was totally user error (and confusing SONAR MackieControl.dll GUI). I learned this last night. It just took about 3 years to get that figured out (with the kind assistance of azslow3 on the SONAR Forum). Seemingly, when I upgraded to SONAR X2 (I'm now on SONAR Platinum Manchester), unbeknownst to me a little check box in SONAR's MackieControl.dll GUI got unchecked and I never noticed it. Not for 3 years. The check box is labeled "Select highlights track" (Why would I want to select a "highlights track"? What is a "highlights track"?). The option, of course, means "Use normal SELECT button behavior". I'm not sure why anyone would want to disable a normal operating feature between an MCU surface and the host DAW software, but in the MackieControl.dll one has to explicitly check this box to enable normal default behavior of the MCU SELECT button, otherwise it won't work.

I'm trying (not very hard) to figure out why my MIDI capture shows the expected MIDI messages going back and forth yet the SELECT button functionality not working, and all I can figure is that the internal MIDI ports that were being monitored (loopBe30 virtual MIDI ports) by MIDI-Ox were somehow between the SONAR executable image and the MackieControl.dll and between the MackieControl.dll and D8Bridge such that the virtual MIDI ports saw the MIDI from the D8Bridge MCU emulation but MackieControl.dll prevented them from passing to the SONAR executable, and the MCU MIDI from SONAR was visible on the virtual MIDI ports but MackieControl.dll prevented them from passing to the D8Bridge translator, all because the MackieControl.dll "Select highlights track" option was turned off. Or something to that effect.

Anyways, D8Bridge v1.1 x32 does work (x64 does not and likely never will - don't use it!) as expected for the control surface SELECT button, finally. Wrong forum, but ProBox also handles the SELECT button function properly. This is what you might call a long time coming happy ending, so to speak...

[goonkalonkyn]

I'm finally closing the loop on my SELECT button issue with D8Bridge v1.1 x32 and SONAR. The short story is that there is no issue, the problem was totally user error (and confusing SONAR MackieControl.dll GUI). I learned this last night. It just took about 3 years to get that figured out (with the kind assistance of azslow3 on the SONAR Forum). Seemingly, when I upgraded to SONAR X2 (I'm now on SONAR Platinum Manchester), unbeknownst to me a little check box in SONAR's MackieControl.dll GUI got unchecked and I never noticed it. Not for 3 years. The check box is labeled "Select highlights track" (Why would I want to select a "highlights track"? What is a "highlights track"?). The option, of course, means "Use normal SELECT button behavior". I'm not sure why anyone would want to disable a normal operating feature between an MCU surface and the host DAW software, but in the MackieControl.dll one has to explicitly check this box to enable normal default behavior of the MCU SELECT button, otherwise it won't work.

I'm trying (not very hard) to figure out why my MIDI capture shows the expected MIDI messages going back and forth yet the SELECT button functionality not working, and all I can figure is that the internal MIDI ports that were being monitored (loopBe30 virtual MIDI ports) by MIDI-Ox were somehow between the SONAR executable image and the MackieControl.dll and between the MackieControl.dll and D8Bridge such that the virtual MIDI ports saw the MIDI from the D8Bridge MCU emulation but MackieControl.dll prevented them from passing to the SONAR executable, and the MCU MIDI from SONAR was visible on the virtual MIDI ports but MackieControl.dll prevented them from passing to the D8Bridge translator, all because the MackieControl.dll "Select highlights track" option was turned off. Or something to that effect.

Anyways, D8Bridge v1.1 x32 does work (x64 does not and likely never will - don't use it!) as expected for the control surface SELECT button, finally. Wrong forum, but ProBox also handles the SELECT button function properly. This is what you might call a long time coming happy ending, so to speak...

could you sell a copy of your software to me?

[bitSync]

could you sell a copy of your software to me?

I'll give it to you. There's no EULA. And the original author has abandoned the project anyway. I'll send you a PM.

You will have to fabricate a purpose built DB25 to DB9 cable to interface the d8b console data port to your DAW, usually by way of a serial to USB adapter. We've got the pinout around here somewhere. If you or a friend are handy with a soldering iron you'll do just fine.

Also, there are certain precautions and things you need to be aware of in using D8Bridge v1.1, but once you know what they are and what to look for it's a fairly solid MCU emulator.

There's also the ProBox, a hardware/firmware translator that sits between your d8b console and your DAW. Find munkustrap on this board if you're interested in getting some more info about that.

[goonkalonkyn]

could you sell a copy of your software to me?

I'll give it to you. There's no EULA. And the original author has abandoned the project anyway. I'll send you a PM.

You will have to fabricate a purpose built DB25 to DB9 cable to interface the d8b console data port to your DAW, usually by way of a serial to USB adapter. We've got the pinout around here somewhere. If you or a friend are handy with a soldering iron you'll do just fine.

Also, there are certain precautions and things you need to be aware of in using D8Bridge v1.1, but once you know what they are and what to look for it's a fairly solid MCU emulator.

There's also the ProBox, a hardware/firmware translator that sits between your d8b console and your DAW. Find munkustrap on this board if you're interested in getting some more info about that.

thx. my main interest in the software is the fader/led "stress test". I've also acquired the ProBox some time ago and I'm very pleased.
thank you very much for your willingness to offer your software.

[sofiabovinoclaudia]

I just want to ask That's with Cubase 7, yes? this page