HUI

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)

"47, 64, 176, 0, $1, 176, 32, $2, 47, 0"

$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.

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.

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.

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.

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.

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.

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

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

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

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.

"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.

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.

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.