Converting a D8B to a full fledged DAW Controller (w/o MIDI)

[High C Double G]

[Axeman098]

http://www.youtube.com/watch?v=5nKHwY9ijj0

Yes that's me on Drums Make some noise indeed!

[High C Double G]

Hey Axeman,

You're playing lefty on a right hand kit. It reminds me of someone... I can't quite place it... hmmm...

[Marc Girard]

If you don't mind guys, please stick with the main subject.

Now, got a good question for you all!

For those of you using PCs, are you guys mainly running Windows 7 x64? Is there many folks who runs on 32bit still? (XP, Win7, Vista). We might have to release two versions of of software if so.

MG

PS: The MIDI bug is sorted out, so it seems!

[Petersueco]

I'm still on Win XP pro. And I'm not planning to change any soon BTW.

[neto117]

I'm Running Win7 64bit.

[Rutah]

Im on Vista 64 but would change to 7 64 with this as incentive! Ohh I need it to work with Cubase 6

[Zorba the Geek]

Hello Marc and Frank,

Congratulations on the great success of your d8b reverse-engineering and the modern day revision/update work. I am very much looking forward to the day that I can send you some cash to get access to all your hard work. It is a great way to extend the life of this board. I tried the old midi-mapping method and was not very happy with the results. (I wrote the main Midi-mapping posts in the database thread a long time ago, and as mentioned I had trouble with the center position mismatch for panning and resetting of unity gain values etc...).

I think your approach of presenting the d8b to your DAW of choice as 3 MCU's is genius and is definitely the right way to go. This is what most people have been begging for in many of the control surface discussions I have seen on many audio forums. As for the idea of a d8b/DAW serial switching box, I say leave that for later, if at all, as using the d8b's automation and DSP are not the main goal in a modern studio setup in my opinion. Modern day plugins, even freeware varieties, are often much better and more powerful and cheaper than the d8b versions (possibly with the exception of the Massenburg EQ). The desire to keep using the d8b's DSP and automation is actually a step backwards I believe. Modern DAW automation is much more powerful and tightly integrated to your particular DAW. Having to switch between DAW and d8b automation/DSP is not a good work-flow and duplicates too many functions. As bitSync mentioned in a previous post, having the DAW as the keeper of all project and console automation information is the way to go.

The d8b not passing any audio is not really a major concern either, as modern converters and DAW interfaces are sonically superior, and can be had for reasonable money (Lynx Aurora converters, RME interfaces etc) and setting up your I/O in relation to the DAW is preferable for session recall and outboard integration. Given that the d8b would not pass audio in this scenario, the d8b clock function would not be a problem, as whatever converter/interface you use should take over this master clock role. I realize that for people using the d8b as their primary audio interface this is not good news, however for those users they can simply continue using the d8b in its current form, if that is the way they prefer to work. For those seeing the DAW as the central hub of their studios, this 3xMCU approach for the d8b is revolutionary.

As I see it, most DAW-centric modern studio setups work this way.
Mic preamps/Line-inputs/Outboard processing to AD/DA Converters to DAW ->
Grouping, bussing, automation, plug-in processing, control surface functions via d8b/MCU protocol to control the DAW ->
Back out via DA conversion for mixing (and possibly more rounds of AD/DA for hybrid/outboard processing purposes) ->
Final mix-down via in-the-box mix-down or outboard processing to two-track stereo mix and back into DAW.

With this approach, the greater fader resolution you have achieved (minus the rounding errors, thank you!!) is a great positive for DAW control, and if you can get the jog-wheel happening smoothly, that would be awesome. As for mapping the other buttons in the Master section, what is your plan here Marc? Casey mentioned an approach that would make these buttons user assignable by setting up a generic remote within your DAW, thus allowing for individual workflow choices. Is that possible with your software?? If not, is the master section unavailable other than for the obvious transport controls? I thought I'd just ask to see what is possible in regards to mapping the buttons that are not obviously mapped according to the MCU spec.

Another quick question/suggestion Marc and Frank. The original d8b firmware allowed for the use of HUI control (for transport/jog-wheel scrubbing etc) in addition to MIDI mapping simultaneously for the mapping of other control surface functions. Is it possible to maintain/import the HUI implementation for transport/jog-wheel control, alongside the new 3xMCU functions you are building into your software. I always found the HUI transport protocol smooth and accurate, and better than the MIDI-mapping of individual transport control messages. This may be impossible, however I thought I would put it out there, as it may make it easier, by simply importing a pre-existing chunk of code that works well, alongside your new MCU functionality. This may of course be impossible or not an effective strategy, as I have no idea about such coding, but I thought I'd put it out there.

PS I am on Windows 7 x64, using Cubase and Nuendo as my DAWs.

Congratulations again on your great work. It is very impressive.

Kind regards,
George

[phatbeatstudio]

I need help setting up my D8B HUI to protools 9 I cant find any info at all help please

[High C Double G]

I need help setting up my D8B HUI to protools 9 I cant find any info at all help please

Hey Phat,

You should start a new thread for this...

Marc,
I am sorry that is my bad on the youtube Monty Python thing - it is the way my brain works. I didn't mean it to side rail the thread, although it did.
Answer... XP just like Peter S.

I will behave myself I promise.

Michael