d8b Forum

Hey I was making some tests to try to make d8bridge work with audio capabilites enabled on the console, ( check the posts here http://www.d8bforum.com/phpBB3/viewtopic.php?f=6&t=634&start=70 ) and I think It's possible to make It work, I didn't have purchased d8bridge yet, but in theory it could work if d8bridge can work with the original d8b firmware and would be easy to switch between MCU and d8b mode, and all the audio section would work normally regardless in which mode is the console working, up to now I connected 2 physical serial ports and a virtual port via Javascript, but I will try to make it work in a faster language like C++, and preferably cross-platform like python or Java, what do you think about this?

semms no one interested? anyway I will update my results here , yesterday I was able to translate the Javascript code to a C program that tuns on console mode, Then I could boot the d8b normally with audio working, and then with a command I changed the normal d8bconsole<--->mackieCPU communication behavior to d8bconsole<--->virtualCOMPort , where in theory, virtualCOMPort could be connected to DBridge, also, There another Command where In theory it could communicate to a MIDI Port: d8bconsole<---translation to MCU or HUI-->MIDI Port , now It only translate the Channel 2 REC/RDY button for testing purposes (in theory this way could make d8b work without d8bridge), and I was able to send that command to my DAW via MIDI, also, it detects a key combination to change between modes, (CTL+ALT+SHIFT on the d8b ) and its working now,

The Serial Port Library Used, in theory is cross-platform, and the MIDI library is windows-only, but I only need to find a cross-platform library to make it work on other OS,

I only need to read the translations from a file and map all the d8b buttons, and It would work cool,

I will share the code if someone interested....

any comments about this?? someone interested?

I'm interested, and I wrote a nice response a moment ago, but it got blown away somehow during posting. I'll try to respond more thoroughly later.

I too, would be greatly intrested. If I am understanding all this correctly I could use the D8B to control a DAW without D8Bridge. Might it also be possible to rewrite the OS to allow the use of a different motherboard and different video cards, maybe even enable usb and cd-rom support, maybe for the HDR as well? I think your work so far is awesome.

Have a Blessed day,
Mike W.

Old School wrote:I too, would be greatly intrested. If I am understanding all this correctly I could use the D8B to control a DAW without D8Bridge. Might it also be possible to rewrite the OS to allow the use of a different motherboard and different video cards, maybe even enable usb and cd-rom support, maybe for the HDR as well? I think your work so far is awesome.

Have a Blessed day,
Mike W.

I think you missunderstood what I'm doing, basicly Im doing nearly the same Marc did years ago, but the difference that the Mackie OS boot normally, so you will need the Mackie CPU and the OS (with d8bridge you didn't need to boot the OS, but audio capabilities were lost) and in theory the audio part of the d8b would work well, and what you said with "rewriting the OS" I think that would not work, or maybe someone could hack the OS to support booting from a virtual machine, that would be great,

yesterday I copied the "leds.txt" and "switch.txt" from the mackie OS disk, and made my program to read a "modified version" of them, adding at the end of the lines, a "translation" to MCU code, so when the files get imported to an array, It could detect a button press and if a translation found, send the MIDI message to the MIDI port, that way in theory could make the buttons work (only need to research how MCU and Extenders work and the differences in the MIDI messages sent) then I would need to make the faders work, I think the program will have to send the feedback info to the leds in the d8b,

I just want to make sure I understand what you're doing. Please tell me if I've got it right, or if I don't, where I misunderstand.

You will be installing a computer host inline in the serial interface between the d8b CPU and the d8b control surface. This will, in a sense, behave like an inline serial switch operated by some host software. In the native d8b position, the host software serial switch will allow the comms to flow between the d8b CPU and the d8b control surface as if they were directly connected with a normal d8b serial cable.

At the user's discretion, that d8b CPU - to - d8b control surface serial connection can be interrupted and intercepted by the computer host software, and instead of passing serial traffic between the d8b CPU and the d8b control surface the host will intercept the d8b control surface serial comms and will translate them to MCU MIDI destined either for MIDI I/O ports on the host or for virtual ports on the host to integrate with DAW software also on the host.

Is that about right? Or are you doing something different than that? If this is your engineering trajectory, I suppose I don't need to tell you that there are some DAW/d8b switchover issues that may not be sufficiently served by an inline serial switch and a serial/MCU translator alone. You'll need a mechanism to load and unload DAW system state to the d8b control surface whenever switching between the native d8b comms and the DAW comms. When switching back to the d8b you'll want to load back in the console state in whatever d8b layer you were working in. If you've considered this kind of thing, that's cool; I just thought I'd mention it. In the way of a suggestion, if you were to continually track the native d8b serial comms inside the host software while in native d8b mode (i.e., maintaining the latest d8b system state in your software), you could keep a copy of the last known d8b system state in your software when switching back to a d8b layer from DAW mode. Same thing for the DAW state; just keep sniffing DAW MCU traffic while in d8b mode and when you switch over you can grab the last known DAW system state from memory.

I've got kind of a philisophical forum question for you. I honestly don't mean to be moderating here but I wanted to share this thought. If the work you are doing is intended to contribute to the D8Bridge initiative, either by developmental assistance, critique, troubleshooting, new requirements, etc., those seem like good reasons for posting on the D8Bridge forum. But if the work you are doing is intended to serve some other function, for example, building an alternative to D8Bridge, would it make sense to work with Peter to open a new 'd8b alternative DAW controllers' forum on this site? Don't get me wrong. I think it's great that you're exploring some DAW controller ideas here using the d8b, and I completely understand your motivation; we've all been waiting a long time for D8Bridge support. But the kernel subject of your work seems so far to be oriented toward an alternative to D8Bridge. Does a new forum corner for alternative d8b DAW controllers make sense? Like I said, it's just a thought to consider.

Keep up the good work!

bitSync wrote:I just want to make sure I understand what you're doing. Please tell me if I've got it right, or if I don't, where I misunderstand.

You will be installing a computer host inline in the serial interface between the d8b CPU and the d8b control surface. This will, in a sense, behave like an inline serial switch operated by some host software. In the native d8b position, the host software serial switch will allow the comms to flow between the d8b CPU and the d8b control surface as if they were directly connected with a normal d8b serial cable.

At the user's discretion, that d8b CPU - to - d8b control surface serial connection can be interrupted and intercepted by the computer host software, and instead of passing serial traffic between the d8b CPU and the d8b control surface the host will intercept the d8b control surface serial comms and will translate them to MCU MIDI destined either for MIDI I/O ports on the host or for virtual ports on the host to integrate with DAW software also on the host.

that would be "the hard way", the easiest way would be instead of translating to MCU MIDI (because I would need to understand all the MCU protocol, thing that Marc already did) connecting through a virtual serial port to D8Bridge and let the software make the translations (tha would imply that my program would simulate the d8bridge firmware loading sequence ) that assuming that d8bridge could work well with the original mackie firmware loaded into the d8bcontrol surface,

bitSync wrote:Is that about right? Or are you doing something different than that? If this is your engineering trajectory, I suppose I don't need to tell you that there are some DAW/d8b switchover issues that may not be sufficiently served by an inline serial switch and a serial/MCU translator alone. You'll need a mechanism to load and unload DAW system state to the d8b control surface whenever switching between the native d8b comms and the DAW comms. When switching back to the d8b you'll want to load back in the console state in whatever d8b layer you were working in. If you've considered this kind of thing, that's cool; I just thought I'd mention it. In the way of a suggestion, if you were to continually track the native d8b serial comms inside the host software while in native d8b mode (i.e., maintaining the latest d8b system state in your software), you could keep a copy of the last known d8b system state in your software when switching back to a d8b layer from DAW mode. Same thing for the DAW state; just keep sniffing DAW MCU traffic while in d8b mode and when you switch over you can grab the last known DAW system state from memory.

Yeah I already thought that would be necessary, to keep reading all ports(including "unconnected" ports) to update statuses and to save both stauses in something like "status" map, such as that when I change to "DAW" mode, the surface would update to the last saved status before changing to "d8b normal" mode (example: if i move chan 1 fader to 0db while on DAW mode, my program would save that in the DAWModeMap, and if I change to "d8b" mode and move the same fader to -10db, my program would save that in the "d8bModeMap", and when i return to DAW mode, my program will recall the last DAWModeMap states and send the command to the surface to move the chan1 fader to 0db)

bitSync wrote:I've got kind of a philisophical forum question for you. I honestly don't mean to be moderating here but I wanted to share this thought. If the work you are doing is intended to contribute to the D8Bridge initiative, either by developmental assistance, critique, troubleshooting, new requirements, etc., those seem like good reasons for posting on the D8Bridge forum. But if the work you are doing is intended to serve some other function, for example, building an alternative to D8Bridge, would it make sense to work with Peter to open a new 'd8b alternative DAW controllers' forum on this site? Don't get me wrong. I think it's great that you're exploring some DAW controller ideas here using the d8b, and I completely understand your motivation; we've all been waiting a long time for D8Bridge support. But the kernel subject of your work seems so far to be oriented toward an alternative to D8Bridge. Does a new forum corner for alternative d8b DAW controllers make sense? Like I said, it's just a thought to consider.

Keep up the good work!

well, I first wanted to make d8bridge work without loosing the audio part of the d8b, that would make this project still related to d8bridge,although I still don't know If this could be done,I still haven't purchased d8bridge cause I was waiting the next version, but I saw suddenly no one of the developers replied in months, and I saw someone posted that would be better if Marc release the code if he would not make any upgrades anymore, so the community could improve the code, that's how I started researching about it, and making some tests and releasing the results(and also the code/cables used) so the community could improve it , then maybe now this is not the right place to post this, I respect Marc's work and and his Software seems awesome, I don't intend to make my program a "competitor" , I don't want money from this ( maybe a d8bridge copy for "researching" purposes ) just want to share my knowledge to other people, maybe I should post to another formu, I don't know hehe,


P.S. sorry for my bad english again

elperroromel wrote:that would be "the hard way", the easiest way would be instead of translating to MCU MIDI (because I would need to understand all the MCU protocol, thing that Marc already did) connecting through a virtual serial port to D8Bridge and let the software make the translations (tha would imply that my program would simulate the d8bridge firmware loading sequence ) that assuming that d8bridge could work well with the original mackie firmware loaded into the d8bcontrol surface

I think the code would have to accommodate 2 serial connections: d8b CPU <--> Application and Application <--> d8b control surface. Right? Something like this is what's in my brain...



Maybe I'm still not getting it...

I suppose the translator above could be expanded from MCU alone to MCU / HUI / Logic Control.

Well, Marc's software does more than just translate between native serial I/O and MCU; the D8Bridge application initializes the console in a rather substantial way. I don't know exactly how you would get around that without some tweaks to the D8Bridge code. I think the way I described what I thought you we planning (the way I misunderstood it) would be the hard way only in that you'd have to recode the translator, presuming of course that Marc wasn't putting his D8Bridge code under GNU public license agreement. Ultimately, you'd still have the DAW controller software residing on the same host the DAW software is running on, plus one more serial cable to close the d8b CPU to d8b control surface loop.

elperroromel wrote:Yeah I already thought that would be necessary, to keep reading all ports(including "unconnected" ports) to update statuses and to save both stauses in something like "status" map, such as that when I change to "DAW" mode, the surface would update to the last saved status before changing to "d8b normal" mode (example: if i move chan 1 fader to 0db while on DAW mode, my program would save that in the DAWModeMap, and if I change to "d8b" mode and move the same fader to -10db, my program would save that in the "d8bModeMap", and when i return to DAW mode, my program will recall the last DAWModeMap states and send the command to the surface to move the chan1 fader to 0db)

Yep. That would be the way to do it.

elperroromel wrote:well, I first wanted to make d8bridge work without loosing the audio part of the d8b, that would make this project still related to d8bridge,although I still don't know If this could be done,I still haven't purchased d8bridge cause I was waiting the next version, but I saw suddenly no one of the developers replied in months, and I saw someone posted that would be better if Marc release the code if he would not make any upgrades anymore, so the community could improve the code, that's how I started researching about it, and making some tests and releasing the results(and also the code/cables used) so the community could improve it , then maybe now this is not the right place to post this, I respect Marc's work and and his Software seems awesome, I don't intend to make my program a "competitor" , I don't want money from this ( maybe a d8bridge copy for "researching" purposes ) just want to share my knowledge to other people, maybe I should post to another formu, I don't know hehe,

Well, I guess my question stemmed from my own ignorance about what it was you were trying to accomplish. From what you describe, it sounds like this is still the right place for you to post. I think you may be at somewhat of a disadvantage not actually having the software. There are various D8Bridge behaviors you will not be aware of without direct observation. But you shouldn't let that slow you down. You are doing very interesting stuff and if it ultimately serves the d8b DAW controller concept, I'm a fan.

elperroromel wrote:P.S. sorry for my bad english again

No worries, your English is just fine.

I think you may be on to something about the Mackie firmware load staying put after D8Bridge initialization. Honestly, I don't know much about it, but I presume that firmware has a lot to do with the various serial data values produced and recognized by the surface controls and indicators, and those values don't change between d8b native comms and D8Bridge comms; the serial values are still the same. Hmmm...

bitSync wrote:
I think the code would have to accommodate 2 serial connections: d8b CPU <--> Application and Application <--> d8b control surface. Right? Something like this is what's in my brain...

yes the "hard way" is something like that, the easy way the would be d8bridge instead the translator,(I think the hard way would take a lot more time to code, and the easy way would work just like d8bridge does , plus you wil have sound and the normal d8b functions, all that assuming I could "emulate" the surface comms while d8bridge loads, and if d8bridge could work with the original firmware(doesn't matter if it loses some functionalities))

bitSync wrote:Maybe I'm still not getting it...

I suppose the translator above could be expanded from MCU alone to MCU / HUI / Logic Control.

that could work as long as there was a MCU/HUI/Logic direct translation, otherwise it would be needed more efforts to translate from one to another based on rules, most of the buttons and faders maybe could have direct translations, the problem would be to manage the lcd messages or vu meters or feedbacks (like controlling the knobs leds while turning)

bitSync wrote:Well, Marc's software does more than just translate between native serial I/O and MCU; the D8Bridge application initializes the console in a rather substantial way. I don't know exactly how you would get around that without some tweaks to the D8Bridge code. I think the way I described what I thought you we planning (the way I misunderstood it) would be the hard way only in that you'd have to recode the translator, presuming of course that Marc wasn't putting his D8Bridge code under GNU public license agreement. Ultimately, you'd still have the DAW controller software residing on the same host the DAW software is running on, plus one more serial cable to close the d8b CPU to d8b control surface loop.

well maybe if someone could test if d8bridge works with the original firmware (I think it wasn't severely modified, maybe just would lose some functionalities) it would be great, otherwise, to make the program work "the easy way" it would be necessary to send the corresponding firmware on each Mode change (and waiting the corresponding time, although I think It would be still faster than rebooting the mackie CPU)

with "the easy" way you would still need to buy d8bridge to make it work, and the disadvantage of the hard way is that it would take more time to code the translations (and reverse engineer the non-documented behaviors)

bitSync wrote:I think you may be on to something about the Mackie firmware load staying put after D8Bridge initialization. Honestly, I don't know much about it, but I presume that firmware has a lot to do with the various serial data values produced and recognized by the surface controls and indicators, and those values don't change between d8b native comms and D8Bridge comms; the serial values are still the same. Hmmm...

maybe if you could compare the original firmware with the d8bridge firmware or maybe the only difference is the message in the desk LCD