MuShoo

How to make Protools not flip it's sh*t when you want to make a max patch act as a controller:

Set the MIDI controller in protools to receive 'From Maxmsp 1' and send 'To Maxmsp 1'

Set the Notein to 'To Maxmsp 1' and the Noteout to 'From Maxmsp 1'

Now you can toy with sending fader and pan information and whatnot.

More things I've discovered about the HUI spec:

Any fader messages have to be formated in a very specific manner.

Firstly, any chain of fader messages must be preceded with the MIDI message '47, 64' and end with '47, 0.' This seems to work best if you contain each fader message within these two MIDI messages.

Even more so, every control change message should be preceded by the 'all notes off' message (176, in max).

So, the best way to send a fader message out to ProTools via the HUI spec is: (for fader 1)

$1 is the LSB, and $2 is the MSB. This order does seem to be important.

Anyway, here's an example of a patch which should A) Interface with protools without causing a 'Lost Communication with the HUI' error, and allow you to control the volume of the first fader in Protools.

Firstly, any chain of fader messages must be preceded with the MIDI message '47, 64' and end with '47, 0.'  This seems to work best if you contain each fader message within these two MIDI messages. 

$1 is the LSB, and $2 is the MSB.  This order does seem to be important.

That would be nice if you could post it again but with the max patch attached as a zip file. Actually, all we see is a bunch of letters.

If you have max5, you can copy everything starting at and including '----------begin_max5_patcher----------' and ending with and including '----------end_max5_patcher----------' and paste it directly into a max patch.

If you don't have max 5, I'll try and make an attached version later today.

Here's an attached Max 5 patcher - I doubt you'll be able to open in it max 4.6 - I haven't tried it though. I haven't tested this under max4 at all, no idea if it'd even work.

Here's an attached Max 5 patcher - I doubt you'll be able to open in it max 4.6 - I haven't tried it though.  I haven't tested this under max4 at all, no idea if it'd even work.


Quote: MuShoo wrote on Fri, 22 August 2008 21:54

----------------------------------------------------

> Firstly, any chain of fader messages must be preceded with the 

> MIDI message '47, 64' and end with '47, 0.' This seems to 

> work best if you contain each fader message within these two 

That's because those are partial "fader touch" and "fader untouch" messages, for the first fader only. You should use the touch/untouch messages for the appropriate fader(s) if you want PT automation to behave.

Everything is a CC message and must be preceded by the status byte 176, (CC channel 1). The only reason they are working for you is that running status assumes the last-received status byte. Your first fader message will however be missing its fader touch due to lack of its status byte.

> Even more so, every control change message should be preceded 

> by the 'all notes off' message (176, in max).

That is not "all notes off", it's CC channel 1 status byte as above. You need to brush up on the MIDI spec if you inyend to reverse-engineer the HUI protocol, google "midi spec".

Since I implemented HUI and MotorMix input support in LC Xmu, I get asked about the HUI spec a lot - while I'm reluctant to divulge much to avoid arousing Mackie's lawyers, here is an important hint that takes a while to figure out if you are reverse-engineering by examining the message stream:

The HUI implements a notion of "zones" for buttons, where CC number equals button number in the zone, and zone number is encoded in the CC value. So CC 47 with value of 64 then 0 is a press and release for a button in zone 0 - fader touch in your message above. 65/1 is the same button in zone 1, ie CC 47 value 65/1 is fader touch/untouch for fader 2. CC 48 value 64/0 is a different button in zone 0, etc.

You may also find the publicly available MotorMix developer spec from CM Labs enormously instructive. The "native" protocol seems very very close to the HUI.

Quote: MuShoo wrote on Fri, 22 August 2008 21:54
----------------------------------------------------
> Firstly, any chain of fader messages must be preceded with the 
> MIDI message '47, 64' and end with '47, 0.'  This seems to 
> work best if you contain each fader message within these two 
> MIDI messages. 

That's because those are partial "fader touch" and "fader untouch" messages, for the first fader only. You should use the touch/untouch messages for the appropriate fader(s) if you want PT automation to behave. 

> Even more so, every control change message should be preceded 
> by the 'all notes off' message (176, in max).

You may also find the publicly available MotorMix developer spec from CM Labs enormously instructive. The "native" protocol seems very very close to the HUI.


Ah, interesting. Thanks much. I'd discovered a bit more about how protools wants things, at least. My messages for all my fader moves look like this now:

176, 15, X, 176, 47, 64, 176, 1, $2, 176, 33, $1, 176, 47, 0

I have no idea if this is 'correct' but it does seem to work. This particular one (seems to) say 'Fader X, has been touched, move to position $2.$1, touch off'

I've been reverse engineering from a BCF2000, which I assume was reverse-engineered from a baby hui, so I have no idea if this is how the spec should actually work - I'm just spitting out things similarly to how the BCF does.

Good to know that 176 is a CC message - I must be pretty rusty. I think I thought it must've been all notes off because... I'm not sure. I'd run into a bug early on where if my fader changes were too long, protools would bitch about losing communication with the HUI - I just assumed something wasn't getting the pulse message.

Oddly enough, one of the first things I tried when moving on to fader 2 was to switch the CC 47 to 65/1 instead of 64/0 and protools ended up doing strange things like muting a track or turning off automation. I hooked my BCF up again and noticed the '15, 1' message, and that the CC 47 message was still 64/0 so I kept that the same.

Thanks much for the notes, though. And you're a better man than I if you reverse engineered the entire HUI spec. I got pissed off many a time this weekend.

Ah, interesting.  Thanks much.  I'd discovered a bit more about how protools wants things, at least.  My messages for all my fader moves look like this now:

I have no idea if this is 'correct' but it does seem to work.  This particular one (seems to) say 'Fader X, has been touched, move to position $2.$1, touch off'

Good to know that 176 is a CC message - I must be pretty rusty.  I think I thought it must've been all notes off because... I'm not sure.  I'd run into a bug early on where if my fader changes were too long, protools would bitch about losing communication with the HUI - I just assumed something wasn't getting the pulse message.

Oddly enough, one of the first things I tried when moving on to fader 2 was to switch the CC 47 to 65/1 instead of 64/0 and protools ended up doing strange things like muting a track or turning off automation.  I hooked my BCF up again and noticed the '15, 1' message, and that the CC 47 message was still 64/0 so I kept that the same.

Thanks much for the notes, though.  And you're a better man than I if you reverse engineered the entire HUI spec.  I got pissed off many a time this weekend.


Sorry, I was utterly wrong (I was going from memory). I just took a look at my notes to check and buttons are also twin CC messages.

176 15 (zone) 47 (press = button # + 64, release = button #)

So for fader X where X = 0-7 you do indeed want:

Hardware fader resolution on a HUI is 512 steps, Baby HUI might manage 1024.

Sigh. Reverse-engineering using a BCF can't be much fun.

A button is:
176 15 (zone) 47 (press = button # + 64, release = button #)

Touch: 176 15 X 47 64
Fader pos: 176 X MSB X+32 LSB
Untouch: 176 15 X 47 0

Sigh. Reverse-engineering using a BCF can't be much fun.


"Sigh. Reverse-engineering using a BCF can't be much fun."

No, it really wasn't. :P Nothing is labelled! Haha.

"Hardware fader resolution on a HUI is 512 steps, Baby HUI might manage 1024."

From what I'd read of the specs, (there are some not-very-detailed ones floating around), fader resolution SHOULD be something like 16000 or something. Since it's two controllers, each with 127 steps of precision, I should get (0-127).(0-127). 127 steps for the MSB, and another 127 for the LSB. I'm not sure, because all I ever see the BCF putting out for LSB is 32, 64, 96, and 0. Which is about 1024 steps, I think? It seems silly not to use all 127 possible high-definition steps, though.

My emulated fader is a 16130 range slider, with a [127] to get the MSB, and a [%127] to get the LSB. I have no idea if that's going to work right but it seems to output numbers correctly.

But, I've gotten it to do everything that I needed, namely move faders (I added a randomization element to fader changes - faders don't stay still, they'll wander around the center point you set. It's pretty nifty.) and I can tell Pro Tools to bank/channel up and down.

The only thing I might want to do eventually is a similar random-ish pan function, which looks like it's going to be painful, from what I've seen of the HUI spec: Pan isn't a 'set to X' type modifier. I forget what the actual identifier is, but it's something like "66, 65" for moving the pan to the right, and "66, 1" for moving to the left, and whenever it gets one of those, it notches over accordingly - it's all relative.

Which sucks. Because the idea of the random-ish function I've got for the faders is that you can define a width around the center point for the randomness to occur in - hard to define a width around a point when there is no center point.

I can post the patch if you're interested. It needs some cleanup and commenting, though.

No, it really wasn't. :P  Nothing is labelled!  Haha.

From what I'd read of the specs, (there are some not-very-detailed ones floating around), fader resolution SHOULD be something like 16000 or something.  Since it's two controllers, each with 127 steps of precision, I should get (0-127).(0-127).  127 steps for the MSB, and another 127 for the LSB.  I'm not sure, because all I ever see the BCF putting out for LSB is 32, 64, 96, and 0.  Which is about 1024 steps, I think?  It seems silly not to use all 127 possible high-definition steps, though.

My emulated fader is a 16130 range slider, with a [127] to get the MSB, and a [%127] to get the LSB.  I have no idea if that's going to work right but it seems to output numbers correctly.

But, I've gotten it to do everything that I needed, namely move faders (I added a randomization element to fader changes - faders don't stay still, they'll wander around the center point you set.  It's pretty nifty.) and I can tell Pro Tools to bank/channel up and down.

The only thing I might want to do eventually is a similar random-ish pan function, which looks like it's going to be painful, from what I've seen of the HUI spec:  Pan isn't a 'set to X' type modifier.  I forget what the actual identifier is, but it's something like "66, 65" for moving the pan to the right, and "66, 1" for moving to the left, and whenever it gets one of those, it notches over accordingly - it's all relative.  

Which sucks.  Because the idea of the random-ish function I've got for the faders is that you can define a width around the center point for the randomness to occur in - hard to define a width around a point when there is no center point.

I can post the patch if you're interested.  It needs some cleanup and commenting, though.


Quote: MuShoo wrote on Tue, 26 August 2008 16:49

> From what I'd read of the specs, (there are some 

>not-very-detailed ones floating around), fader resolution 

>SHOULD be something like 16000 or something. Since it's two 

>controllers, each with 127 steps of precision, I should get 

>(0-127).(0-127). 127 steps for the MSB, and another 127 for the 

That's what the protocol can support in theory, but the actual hardware fader only outputs 512 steps. Later-model P&G motorfaders do support 1024 (as per Mackie Control). I'm not aware of any 100mm hardware motorfader supporting higher than 1024 steps.

ProTools may or may not support higher resolution at input, but I believe it interpolates to 24-bit internally for automation anyway, so you may never know.

>I'm not sure, because all I ever see the BCF putting out for 

>LSB is 32, 64, 96, and 0. Which is about 1024 steps, I think?

128 x 4 = 512 steps. I think the BCF faders do support 1024 steps in hardware, but Behringer are probably emulating a HUI as closely as they can.

Quote: MuShoo wrote on Tue, 26 August 2008 16:49
----------------------------------------------------
> From what I'd read of the specs, (there are some 
>not-very-detailed ones floating around), fader resolution 
>SHOULD be something like 16000 or something.  Since it's two 
>controllers, each with 127 steps of precision, I should get 
>(0-127).(0-127). 127 steps for the MSB, and another 127 for the 
>LSB.  

>I'm not sure, because all I ever see the BCF putting out for 
>LSB is 32, 64, 96, and 0. Which is about 1024 steps, I think?

128 x 4 = 512 steps. I think the BCF faders do support 1024 steps in hardware, but Behringer are probably emulating a HUI as closely as they can.


"128 x 4 = 512 steps. I think the BCF faders do support 1024 steps in hardware, but Behringer are probably emulating a HUI as closely as they can."

Heh, I've been up too long. Wee thinking!

I'd honestly be surprised if the BCF supported 1024 steps, it's a nice board for 200 bucks or 150 or whatever I paid for it, but it's pretty damned low-end.

Heh, I've been up too long.  Wee thinking!

I'd honestly be surprised if the BCF supported 1024 steps, it's a nice board for 200 bucks or 150 or whatever I paid for it, but it's pretty damned low-end.


Thanks a lot for the patch. It seems very interesting. I already tried to reverse-engineer an HUI but finally lost patience. I'm quite busy this week but I'll check it as soon as I'll have some time.

I'll try and post a newer version of a demo patch soon.

Mackie do not make the specification for the HUI public.

is there anybody who had more luck into reverse engineering other functions of HUI Control?

Anybody involved into chaining MAX with ProTools?

is there anybody who had more luck into reverse engineering other functions of HUI Control?
Anybody involved into chaining MAX with ProTools?

I was wondering about controlling a particular Pro Tools function via HUI today, and found this thread. True, Mackie is still only releasing the HUI via a licensing program, and it seems they only engage in that with hardware manufacturers.

However, I did find some extensive info from others who had done some reverse-engineering. Check out this stuff if you're interested (both these links were found on an open-source MIDI forum thread, 

http://midibox.org/forums/topic/8534-where-is-the-mackie-hui-protocol-spec

http://www.midibox.org/dokuwiki/doku.php?id=mc_protocol_mappings

http://home.comcast.net/~robbowers11/MCMap.htm

However, I did find some extensive info from others who had done some reverse-engineering. Check out this stuff if you're interested (both these links were found on an open-source MIDI forum thread, http://midibox.org/forums/topic/8534-where-is-the-mackie-hui-protocol-spec ):

Cross-DAW:
http://www.midibox.org/dokuwiki/doku.php?id=mc_protocol_mappings

Digital Performer-specific:
http://home.comcast.net/~robbowers11/MCMap.htm


Ideally we'd be able to get at the EUCON spec at some point - seems like that's a bit more difficult to reverse engineer, though. But oh how I wish I had control over arbitrary plugin parameters...

UUGHHhh... this has got to be the closest I've come to getting Pro Tools to agree with the HUI emulation I'm sending it... alas, being a noob and brand new to this Max/MSP program, I have no idea what to do. I've set up your sketch and assigned the MIDI outputs appropriately, but Pro Tools still doesn't see "To MaxMSP1" and "From MaxMSP 1".

How do I 'activate' these Midi I/O for Pro Tools to see?!

This might be help for you,the hui protocol pdf.

http://forum.cockos.com/showthread.php?t=101328

This might be help for you,the hui protocol pdf.
http://forum.cockos.com/showthread.php?t=101328


I'm assuming there is a small chance anyone might resist this thread, but I am attempting to get transport info (play, stop, record) from Pro Tools, specifically using HUI.

I am able to see that Pro Tools spits out a series of control change commands, but it's difficult to figure out what those messages actually mean. I've attached an image of just a simple play from Pro Tools. I've looking through Theageman docs and anything else I could find, but nothing to explain the below.

My only assumption is that there are so many messages because Pro Tools is also sending the status of various other settings pertaining to playback or transport in general.

Play.png

I'm assuming there is a small chance anyone might resist this thread, but I am attempting to get transport info (play, stop, record) from Pro Tools, specifically using HUI.  

I am able to see that Pro Tools spits out a series of control change commands, but it's difficult to figure out what those messages actually mean.  I've attached an image of just a simple play from Pro Tools.  I've looking through Theageman docs and anything else I could find, but nothing to explain the below.  