Control Surface Emulator
I’m trying to use Pro Tools automation data to control lighting software. To this end, I’m writing a patch that will emulate a Command 8 or another Pro Tools-compatible control surface. I have no trouble receiving the automation data in Max/MSP, but Pro Tools displays an error message every 5 seconds because it does not detect an actual control surface. I need to have my patch give Pro Tools the "secret handshake" usually given by the control surface. After scouring the forums, I’ve found a couple examples of patches that generate the other side of the handshake, the Host side, but nothing that emulates the control surface side. In short, I want my patch to generate a Host Connection Query sysex message, and once it has received a Host Connection Response, to then generate a Host Connection Confirmation sysex message.
If anyone has suggestions on how to come up with these sysex messages, or alternative ways of hijacking Pro Tools automation data, please let me know. Any help will be much appreciated.
Thanks in advance,
Digi don’t document the protocols they use for their control surface support (?), so short of hooking up an actual Command 8 and attempting to reverse-engineer the handshaking from there (urgh), you’ll need to look at using a more well-known protocol.
I’d suggest going with the old Mackie HUI protocol, which doesn’t need a handshake, just a single-note ping at 1sec intervals that you echo back to the host. This isn’t a published protocol either, but you can hook up any cheap HUI-emulating device to figure it out, like the Behringer BCF2000.
Ben Lacker schrieb:
> If anyone has suggestions on how to come up with these sysex
> messages, or alternative ways of hijacking Pro Tools automation data,
> please let me know. Any help will be much appreciated.
I wouldn’t bother with the protocol for Protools, just let Protools talk
to your controller, get the controller data into Max, and pass it
unchanged back to Protools. Just a question of flow of information…
Eventually tell Protools that your IAC bus is the one the control
surface is attached to, and pass it in both directions on to the
John, thank you for your quick reply. When I set Pro Tools to use the HUI protocol, I can see the single-note ping (note C-2, velocity 0) at intervals of 800ms. However, my attempts to echo the ping back to the host using Max are unsuccessful: Pro Tools still complains about not being able to communicate with the HUI.
However, when I set Pro Tools to use the Command 8 protocol, I see a similar single-note ping (note C-2, but here with velocity 127) at intervals of 500ms. When I echo this note back to the host using Max, Pro Tools stops complaining, and everything appears to work smoothly. However, echoing this note back also causes Pro Tools to generate two additional pings every 500ms: one on C#-2 with velocity 76, the other on C#-2 with velocity 12. These new pings puzzle me, as does the fact that got the ping to work with the Command 8 protocol but not the HUI protocol.
Please let me know if you have any more ideas.
Many thanks for your help!
Hmm, a value difference of 64. The extra notes are quite possibly ProTools telling the Command 8 to flash an LED somewhere. Is anything soloed or record enabled or waiting or ready or such? Does it match the current tempo? Rude solo indicator?
John Pitcairn skrev:
> Hmm, a value difference of 64. The extra notes are quite possibly ProTools telling the Command 8 to flash an LED somewhere. Is anything soloed or record enabled or waiting or ready or such? Does it match the current tempo? Rude solo indicator?
IIRC the protools communication is filled with direct control over
flashing LEDs on the controllers. I did a full hack once, but
unfortunately passed all patches over to the client, as part of the deal.
After rebooting, the extra pings are no longer present. Perhaps I had accidentally record-enabled a track or something yesterday.
Also, I was able to borrow a Command 8 and confirm that the single-note ping (C-2, velocity 127) is indeed how it shakes hands with ProTools.
Pro Tools outputs the volume data in an interesting way: for track n, each new value is sent out on three separate controllers such that the controller number % 8 = n. Within that limitation, however, I don’t see a pattern as to which controller Pro Tools chooses. I have no problem using this data, I’m just curious as to why the protocol is set up that way.
Anyways, thanks again to everyone for your help!
Thanks to all your help, I’ve now got Pro Tools volume data coming into Max. The problem is that Pro Tools is only sending the volume data for eight tracks, and I want to use around 100 tracks. Even if I could set up Pro Tools to communicate with four different Command 8 emulators, I would still be transmitting data for only 32 tracks. (I am currently having trouble getting Pro Tools to communicate with even two Command 8 emulators; when I try, I receive the following error message: "You have selected a MIDI controller that is not compatible with Command 8. Please deselect this device or remove Command 8 from your selection". Furthermore, I am limited by the fact that "to Max/MSP 1" and "to Max/MSP 2" are the only two MIDI ports available)
Does anyone know how to access the automation data for a large number of Pro Tools tracks? One idea I’ve had is to send bank-switch commands from Max to quickly cycle through all the channels and poll their volume data. For my purposes a high polling rate is not very important. If that does not work, perhaps I can use Max to emulate an ethernet controller, since they offer a greater number of channels.
Thank you all again. All your help is greatly appreciated.
I am very interested in this project…..can i contact you for additional info? i would love to build up my own emulations….
well…please, maybe i am not so skilled but with such very few informations i have difficulty to build one myself…anybody would like to share at least some portion of the working patch to emulate the Command 8? Or give some brief tutorial? i can reward with good italian olive oil :)