Automation feedback on Digidesign 003 Factory

Installation & Configuration Linux
#1

First of all, hello everybody and thanks for being there ! And especially to Damien Z., Robin, and Takashi S. for getting a driver together.

I have just been given a digidesign 003 Factory, the one with a control surface. I have my audio inputs and outputs running through jack (couldn’t get pipewire to deal with it, although it may be simply a matter of settings… …haven’t found solid documentation on pipewire yet), and the sound is great by my ears.

With the 003 in midi mode, I can associate controllers in Ardour (Ctrl - middle click). In edit → preferences → plugins → control surfaces → generic midi, the incoming and outgoing midi are with the 003. Motorized and Enable Feedback are set.

My question concerns getting fader motorization to work, so I guess it has more to do with the device or the driver than with Ardour. Indeed, I can record automation of a track’s gain/fader from the device, and play it back (shows in qmidiroute).

I have connected all of the Ardour midi out ports to each of the 003 in ports. The 003 ignores the messages, but seems to make them available on its midi ports as the leds blink.

I have tried starting jack with midi driver raw or seq, using none + a2jbridge I don’t even receive midi in Ardour (the only a2jbridge posts in qjackctl are the defaults).

Is there a non official standard for this type of command, can we get the information from the device itself through midi, or would getting this to work involve spying on the communication between protools and the device (I only have linux, not anything with protools).

Am I right to think that the messages should be translated somehow, put them into system exclusive messages perhaps ?

(I’ve looked for more than an hour but so far all I have is: F0 13H … F7, perhaps an Event List Request somewhere inside ? 13H = Digidesign Inc. ID)

If anybody knows how to get the Digi 003 in midi mode to accept
automation feedback as it is, I would be most grateful. Alternatively, I would not take any help in figuring out how to get this working badly. Finally, if this required work on the driver, and not just some midi hack, I would be willing to do testing. (I don’t write C, and know little about device drivers, so I don’t think I would be much help actually developing.)

Cheers,
LiS

#2

I am not entirely sure, since I never had access to that device and I think @zamaudio only has the Rack version… I think the device uses AVID’s HUI protocol, which isn’t directly supported by Ardour.

I don’t know if it can be used using the *Mackie (MCU) interface. Might be worth a try.

#3

Hi, thanks for attempting this. Robin is correct, I only have used the Rack and Rack+, not the one with the control surface. I am guessing there might be some proprietary firewire commands involved to make the faders move, but I’m not sure. Did you check the user manual for controlling the surface via MIDI? Maybe indeed there is some MIDI Sysex command you can use to control the faders, and it should be documented if there is. Good luck.

#4

Thanks for your leads.

Athough no mackie setting was usable, trying mackie (mackie-control) led to a discovery: with the 003 not in midi-mode, the fader motors can be commanded with simple CC messages: b0 XY ZZ (ZZ = level 1-127, Y = Controler/Fader 0-7, X = 0-7, possibly fine level)

I checked what was coming out of the unit in this non-mode, and all of the buttons that could interact with Pro Tools are sending midi. (But different midi codes from those sent in midi-mode).

On the other hand, sending the CC messages to the 003 in midi-mode causes it to leave midi-mode for a second, move the fader, then re-enter midi-mode and move the fader back. (I suspect it is actually in non-mode when the fader moves, but it can be kept there by sending at least one movement message per second. )

The down side on just staying in non-mode is that the input will need to be translated, assigning a fader to a track in ardour results in unpredictable behaviour, even when being careful that the “touch fader” signal is not included. This appears to be because of the format of the messages not being understood:

B0 YY XX, Where XX is HI (dictates the overall level), YY is LOW (adds an octet of detail, with the codes: 03 0b 13 1b 23 2b 33 3b). The LOW octet precedes the HIGH.

Looking into HUI I found theageman’s reverse-engineering notes on another machine ( https://stash.reaper.fm/12332/HUI.pdf ). Getting to such a degree of control would indeed be impressive ! (setting levels of pots, setting diodes, even printing things to the display)

Inspired, I scripted firing every possible 3 hex code at the machine, getting only one led to flicker as an added result. Before setting up a perl program to go further, are there codes that I should blacklist, perhaps update firmware and such ? Are there already good utilities for scanning all the midi codes of a device ?

Am I correct in thinking that the road for non-mode would involve implementing a control surface protocole for ardour, or should the translating be taken care of by a stand-alone filter ? (with a qmidiroute configuration, for example)

Midi-mode appears to have less precision on the faders (and touching without movement cycles them in a range of 5 below the current value, weird. No touch message), less controls, and be more difficult to give feedback to.

The pots do send 0-127 rather than just “up” and “down”, but I am not sure that is a feature. (they have infinite turn… )

The only manual I could find is the “003 Familly Setup Guide”, not very technical at all, and about half is about ProTools. Not any other documentation to speak of, only a handful of forum posts that don’t ask my questions.

Most of what I am gathering information from is writen about other devices.

So far, I have yet to get a response from a sysex message. I figured out to remove the H (which just meant hex) and try F0 13 … F7, even the idea that “f7” aims at all devID/subID, but nothing is answered ( 06 01 / 06 02 ask for the device to identify itself, for example ).

To further complicate the workflow, I am using amidi to inject midi, and when jack and ardour are running it cannot acces the raw midi device anymore. Is there a simple way to avoid that ?

At this point I think working on non-mode is the best direction to take.

As always, any insight is welcome, and pointers to usefull references could help this to take form.

Best,
LiT

#5

There’s no need for wild shots in the dark.

The Mackie and HUI protocols are fully specified and docs are available online. They are fairly similar (Mackie Control Protocol is a “refinement” of HUI in most ways).

We have just chosen not to support HUI for a variety of reasons, but anyone could write a control surface module (in C++) that did so, basing it on the current Mackie support that we have.

1 Like