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′
----------begin_max5_patcher---------- 466.3oc0U9saCBBEF+Z8ofv0tF.+61c64XoYgprN1TrQnYcqou6SvZWamVoM straf3gi3G+76bXsqCbV4JlDBd.7DvwYsqiiIjNfy1mcfEzUo4ToIMXASJoy YPul0TrUJSbLItMFOyDob1a2EG1FbAUk9JWL+4JVpp4CRvnIHOfueyDYRnG. mLAAlt8cdoTnDzBlY6drhSya2MwxBtHmoLZhrW5R9Wlzwj58bWtkKUsIia0S ESxDJphWJNPSQZwDfLSnsC6TTyFo9bAqIcHDLUuxFWW8fmkPTv9nlN+hgRVd sP.8fx.KPIxLEEpGInaLJI8AkYTwbn2kBm9bXntfB5DPA62vgf+B+0s0oTPe mIJULsWAf6.LQIV.lXCXtO9RcK9WE2BWnzlE8z0DQZ7T+s5lNwCSG+nlZI7n PGzUuKRWkKg9V3JZZkDR9O2C4DdBtnKvPFFL3DCXBhtTvfOGv3aQ4RWUMFQA y4hiuV2bvzwODaxxkUos6c6U1feNaYLohKLWStWR5BH.dWRuxyxXl0aOLE7r Ek0haqH54mn0ZJvBMcjvu0ZR2gcODzilBFUMouNb3+cIiOmrxOMdZR2GbX+D Zb0DwBMcjvOOMU+vF2uA1VIuU. -----------end_max5_patcher-----------
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)
"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.
----------begin_max5_patcher---------- 1711.3oc4Zs0aaaCE94jeEbFav.qddjTW8dqWPwBZCP.R6SKECxVzwZUVTPh tMYE8+93M4HmPIw3nH6sAzJERQQeNe7b6iTe6zSFMmdCobD32.+A3jS91omb hrKQGmnaexn0Q2rHMpTNrQKnqWSxXilndFibCS1OaEArLJlTTBVQJHfUQkfH PQT10D.cI.gC.+r75K.npWNMIirftISNCXcmIwx4iN+u9EmsiLOhsXUR10+Y AYASIttX3T3DfCxSbC4iksbmBAeR+RKoYrrn0D478xhjnzpoKay5jrTBSpRn ZCuL4ukCGIlssiktgUM3pdyKHkbXHhkPypKTHGkPIkFn9B3ShW56mdp3xDKA 5xzDNZNx.p.aAUbBjvAFqtIk.jKrFpXT22UIQsqjNgH0ug+tJo9sTSD61bhZ 3iFs8QagWejC+U1CTIi7UNF7.qOoo0TCfEdV2fEZl7lKtBxdrVP3GiEDpIXZ YJMhKXep+PkxEQoD.T51AmBPFAHOK.Hn71rY6K.4ejBPLvbvRSfB1BPwQdyA O0a+.kGUbGbSfxbdD1QSdN.mWzfACxBrw+IhMGqdTKX7bVb8x.tfB6FWTWc2 a+n9wjIQj9Vcq+wFnInInMnwAVycZ+CBebfMMUdzYY.QERWTP+.klVBFeIgs IeLfO3MS.WSALJX7Ejhjbd0SQokiAQYwhWICb9Yu4Lvq4ZUAMMkWe0zqxtJ6 kww7xq98Od1D.GJIIegCpfkEz0fqF8Vwsyit47Ku.ftZjbl34wiECQ7y7A51 mNVLWmsDTRWKKSishVx+ibQF+RPLMaLCDkmShJpDRgVHkcsnKZKkvxMyU8n9 4R4KvfwmkkugAdC4KIKHkSmNcrwR+PNFrY7awlQarnC13EJuE5eXq8CoJKBA Cex090jUDG34.dR4CVFM4z0Vhcj2NEO64NHdcc.fNpBJQ9CD.tiexXaIkfba iThpRIeHrFtdnIkfCkAUc8l8jw0FB8yyyFulTVZL5eaUfq7fcTvUvvD6G0BO k8.R1Hh5sEQ3yllN8VcntsCrarvWY5DB6Uv.M0alGJLvHhrM7KirVK8idG41 RkkDudEhHm3DwkW852hgPH3BZASPjW2M6tXQF5CeGCvlb8cU0.3XGiRcVZ4+ 6S630IwIIYKolBmh5doSUIiaXuxir0UtNXpikd7Hji0D0eFhIfLflsUqrduK 7779eRPgYcCF95D0ANG1nBu7if279KAWdaFaUMW8GWvhc5Fus6k0SGar2ZwQ NFBIfgVXEG5cnhIzSlxMUJkv2N5ZBXIsXcDiI4ePKDTR.KTjUDDJxKnLAgGa qtpsp98bUwWmcbsiu9Jwv6YqnUAEq0z3MoTvxMYKjtYWSx37DYjR.cSA38W9 pxIfutJIkHIjEy4CFSpMny4CXpw0.CTuZi3fqdWuloKv0ux59fRb.p1Qk6W9 PexeGrJ5KDAc3a4THVlb8lBRLG6YbTOhIA8ETNjyoVH7BFmmFc67nEedLmZM 3tWdNgSnOZtXYhBVG8Y9Kv.aDTtyzGehX9MuR48vUJ2tOeDrxoA4ipXL+7tR 0iX96Hj7xsQP3XXd9s+fo3vVPzsxdENLDc627O7Y1jZ61VUT5sf0COja439n 257HOPwQttb23IhCuvnx60sxqyTDn1WlvC01P2umoiZm0fFwDGKvjJ6hA4vt 57XK5UrIixHIYFQFWKPF8NP6OHtJNVrCzOCaRedzmAHiTxvsdZ6Uba0VOvC6 QktePRSQZbCjAZ3+6GwBNV9hSth2.oaHdtuqQHCZAjMSeT7t+GJJTKYkvVfI G+YkZPu+0FRGgvsd5eypWDhSvg04ouCo7SMhI9caInwDWu+khIM9U5DXwYdh Qvd3qzYu9dajCQxu3de8WRoUz+tJcIml4hpefpOrFvcxaLojkjIIlUaPh3i0 Fzpj3XRVcBc73H4TN3uc6wLtDXsLgrPltmf+bKShy9taYBMr3D9HUlP1HSng Sl7rAmvCq8TnMxj2vJSPKV6tmf2oLU8MDo+XC8CLzRk1PeJ161RctANgthOA IQiAQGCFTcD4nTRmYBkT1ZHzRIap8RMcp+gysSK8tUgBjqWtX3SVUrI+DZXi mfrI+DZXyYJN8IKVwejNuNhinPvZxq11tsaKOLt1Jtr0fnJX3SQU7B8qoJ5V dyPpZYQFZgq6i1GpoUI.F3Buf1XXOrEdEXSgWRNJGeBU3vt54.spNmANvz8V ZZPpbPCrTEZsTMfEp5XEymglNlX+n6Vpb8FXox0JoxYfkJq3Z39ThLva78S+ G91VeVB -----------end_max5_patcher-----------
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.
This post seems to contain a broken pasted patch. This can happen if you don’t copy the entire "———-begin_max5_patcher———-" or "———–end_max5_patcher———–" for each and every patch you paste; perhaps you missed a preceding or trailing "-" when you copied the patch? Please notify the Cycling 74 web team if you think it is a bug.
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  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.
"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.
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?
I would like to cooperate
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 ):
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?!