My DIY HUI DAW Controller

[bjosephs]

AKA the silliest project I've ever undertaken.

Still not complete, though nearing an end, I started this project in 2016 according to my files. I was enamored with control surfaces in the early 2000s when my recording/production journey started but the high cost and often excessive size prevented me for just buying one. Sometime around 2013 as part of my engineering degree I started to dabble in Arduino programming and after graduation, at some point early in 2016 I stumbled on this thread post that linked to someones painstaking reverse engineering of the protocol. I spent a week's worth of sleepless night drafting my first attempt at a one way implementation to collect status from a session on my computer. It worked well enough.

Over the next few years I picked the project up for maybe 100 hours at a time experimenting with various considerations like PID control of the faders, motor driver circuits that don't whine, what kind of encoders I would use, what type of displays. Oh, and how to process all the user inputs, displays, and USB data reliably - something that ended up with my current implementation which uses 8 atmega chips on an I2C bus managing "modules" and communicating with a 9th microcontroller that handles USB and the scribble displays. I spiraled in that state for a long time but some unexpected time off early this year prompted me to lock in some choices and try to finally bring this to a close. In the time since I began I had purchased many parts. The faders I'm using are now NRND and the encoder cables are obsolete. I bought NOS LED displays because the ones I had my eye on 5 years ago had quadrupled in price.

In comparison, the cost and capability of control surfaces has improved substantially. Surely when done I'll have spent 3 times as much and gotten maybe 80% of the functionality. But I have learned a staggering amount and enjoyed many fantastic "ah ha" moments.

In the next few posts I'll put some pictures of various parts/states of the project and, hopefully, before long I'll have the whole thing done. But I'll link one cool video here as a preview.

 

[totoxraymond]

Nice one!

I've been following the same path as you did I can tell that there's nothing better than using my own custom controller in my daily job.

I used the same switches! Are these alps faders. How do they feel? Are they silent enough? I used Bourns faders, they're nit bad, but i wish i could get my hands on some tkd...

Keep on going!

 

[bjosephs]

I used the same switches! Are these alps faders. How do they feel? Are they silent enough? I used Bourns faders, they're nit bad, but i wish i could get my hands on some tkd...

Keep on going!

Ah yes, the switches. Another part that doubled in price while I procrastinated. They are great though. The faders are Alps "RS" series. They feel great and are very quiet when I keep the PID control values tuned low. They make some noise when the PID is tuned for maximum response. The only criticism I have is that they do have about bit too much side to side play.

​

 

[bjosephs]

I'm not sure where to start so I guess I'lll describe the fader modules.

The whole system needed 8 analog inputs for the fader reading, 16 PC interrupts for the encoders to work smoothly, and 16 PWM pins for the motor drivers. It just made sense to put a single Atmega 328 (the same chip at the heart of a standard arduino uno) on each channel to manage that stuff.

I flashed them as arduinos and the code reads the fader position, runs a PID loop, and drives the motor PWM at 31.26kHz while monitoring everything else. The encoder knob is on the PC interrupt pins for fast response. I left TX/RX open and put a header on the back for future updates. The touch pin on the fader is tied to an AT42QT1011 IC that senses capacitive changes. It's the smallest part I've ever installed and I'm glad I started to move in the direction of SMT on my last few projects.

The other pins were for buttons and LEDS but I still managed to come up a couple short so I'm using WS2811 LED drivers when can be driven like shift registers off a single pin for three LEDs each. I needed 5 LEDs for buttons so at the last moment I added a 6th for "signal". I had the code to implement meters but HUI meters aren't very useful with the DAW meters already on screen. But having little white light pulsing to the music helps me find the fader I want.

Because the modules are held to the panel through the fader body I needed very tall buttons... Which don't exist so I bought some stackable headers and put my buttons on a mezzanine PCB. After lot of testing and deliberation I decided that the module would be rigid enough held in place only by the fader screws. I was wrong and the moment of force created when pressing the buttons does cause deflection. So once assembled I have a task to find a way to support the boards a bit more. I have a few ideas.

 

[ccaudle]

I decided that the module would be rigid enough held in place only by the fader screws.

In my head I can hear a mechanical engineer I used to work with explaining why that is a bad idea.
The two traditional ways would be mounting points on the corner of the PCB that also connect to the faceplate, or mounting points in the corner of the PCB that have stand-offs mounted with a solid tray underneath all the fader cards.
You could still put a tray underneath, but without anyplace for stand-offs on the PCB you would have to use something non-conductive under the PCBs to support them against the tray (assuming the tray was metal).

 

[bjosephs]

In my head I can hear a mechanical engineer I used to work with explaining why that is a bad idea.
The two traditional ways would be mounting points on the corner of the PCB that also connect to the faceplate, or mounting points in the corner of the PCB that have stand-offs mounted with a solid tray underneath all the fader cards.
You could still put a tray underneath, but without anyplace for stand-offs on the PCB you would have to use something non-conductive under the PCBs to support them against the tray (assuming the tray was metal).

Unfortunately, I am a mechanical engineer.

I did test the configuration and it felt rigid enough because the buttons only require 1.6N of force to click. But then I mounted them to the real panel and it just wasn’t the same. I have room at the top and bottom edges of the PCB and a spot near the middle that I can install some sort of stiffener. I have a couple ideas but I can retrofit them in later.

 

[inkster]

I've talked myself off that ledge several times...I even acquired 40+ GML faders(which are really well made) but eventually sold most of them off to other experimenters as I don't have the time nor could I justify the effort but I am always interested in viewing such a project at a safe distance. Keep up the good work!

 

[Rob Flinn]

Did you ever look at the ucapps.de site ? They have everything to make DAW controllers as open source including rotary controllers, motor faders, analog and digital ins & outs. I have long procrastinated about using their motor faders controller for my console.

 

[totoxraymond]

Did you ever look at the ucapps.de site ? They have everything to make DAW controllers as open source including rotary controllers, motor faders, analog and digital ins & outs. I have long procrastinated about using their motor faders controller for my console.

My controller is based on the awesome MIDIbox project and i highly recommend it.

BUT you have to be aware that it is NOT compatible with HUI protocol which deviates quite a lot from MIDI standards.
You can have some sort of control over HUI with some clevercinfiguration. Iwas able to get faders and switches working, as welle as lcds. But not the LED feedback.

It's ok for me because i don't use Pro Tools at home.

 

[bjosephs]

I did way back at the start. But I tend to have this obsession with the details and avoid prepackaged stuff even when it makes practical or financial sense. I want to see how far I can take things on my own. It’s not a good trait most of the time.

Did you ever look at the ucapps.de site ? They have everything to make DAW controllers as open source including rotary controllers, motor faders, analog and digital ins & outs. I have long procrastinated about using their motor faders controller for my console.

 

[bjosephs]

I made some progress today. The screens are mounted. The scheme here is that the screens are DIP socketed on the PCB and the PCB is mounted to a 3D printed spacer that is attached to the back of the panel without fasteners using some very strong double stick tape. I will need to dress the header cable carefully around a mounting hole for the master section PCB.

 

[bjosephs]

And another dry fit of some channel parts. For whatever reason the buttons feel pretty rigid without support under the board but I still have some ideas.

 

[SIXTYNINER]

My controller is based on the awesome MIDIbox project and i highly recommend it.

BUT you have to be aware that it is NOT compatible with HUI protocol which deviates quite a lot from MIDI standards.
You can have some sort of control over HUI with some clevercinfiguration. Iwas able to get faders and switches working, as welle as lcds. But not the LED feedback.

It's ok for me because i don't use Pro Tools at home.

MidiBox has thrown wide open the doors of a crazy cool universe ,
really a pity that for a while there hasn't been the considerable projects movement/development that there used to be...
specially for controllers,
of which those who use soft synths often talk about ,
complaining that they cannot find controllers with sufficient features for their needs.
: (

I made some progress today. The screens are mounted. The scheme here is that the screens are DIP socketed on the PCB and the PCB is mounted to a 3D printed spacer that is attached to the back of the panel without fasteners using some very strong double stick tape. I will need to dress the header cable carefully around a mounting hole for the master section PCB.

Very cool ,
and even more so if it can be used to handle audio faders and mute switches as well,
to be used as automation for analog consoles,
without causing devastation to the bank account.
; )

 

[zamproject]

really a pity that for a while there hasn't been the considerable projects movement/development that there used to be...

I'm using midibox since long time now as brain for my fader automation, and I still don't see what major improvement can be done, everything is possible with this platform.
But you'r right there is always room for improvement, I especially think about core, STM32 still fine I suppose, but -ready to go- options for smaller dev/embeded board would have been cool.

BUT you have to be aware that it is NOT compatible with HUI protocol which deviates quite a lot from MIDI standards.

IIRC I was able to completely tweak MIOS for HUI compatibilities when developing my automation, but I stop and focus on MCU/mackie because of host side limitation.
Despite double CC (in a non official NRPN way) you are limited to 9 bit/512 value IIRC, the first CC (MSB) only swing 4 values (0-31-63-95).
I need at least 10bit fader read/write accuracy, in practice I run my fader at 11bit without jitter (12bit ADDA over 14bit PB stream) which result in a 1/20 mm accuracy for 100mm fader

drives the motor PWM at 31.26kHz

Your video seem good regarding parasitic noise of PWM driver, how it is for slow moves ? like fader bottom to top in 10sec fade in
At my side I rapidly stop the PWM path as I was not able to manage correctly the horrible printer sound...also as I intended to integrate the faders in a console (fader pass audio too), digital crosstalk and motor EMI with a PWM driver was not sustainable.
I finally go for a full analog PID motor driver.

Cool project, keep going !

 

[bjosephs]

IIRC I was able to completely tweak MIOS for HUI compatibilities when developing my automation, but I stop and focus on MCU/mackie because of host side limitation.

I did tests with Mackie/MCU but I got annoyed when pressing controller buttons would cause midi notes to play if I had my routing incorrect. I like that HUI is all SysEx.

Despite double CC (in a non official NRPN way) you are limited to 9 bit/512 value IIRC, the first CC (MSB) only swing 4 values (0-31-63-95).
I need at least 10bit fader read/write accuracy, in practice I run my fader at 11bit without jitter (12bit ADDA over 14bit PB stream) which result in a 1/20 mm accuracy for 100mm fader

HUI uses 10 bits but breaks it into two messages. The host shifts and appends them together, the same happens at the controller. So two 7-bit values are sufficient. Maybe there are other barriers I’m not aware of for you.

Your video seem good regarding parasitic noise of PWM driver, how it is for slow moves ? like fader bottom to top in 10sec fade in
At my side I rapidly stop the PWM path as I was not able to manage correctly the horrible printer sound...also as I intended to integrate the faders in a console (fader pass audio too), digital crosstalk and motor EMI with a PWM driver was not sustainable.
I finally go for a full analog PID motor driver.

Motor noise is inaudible at any speed. *Fader* noise is dominated by tuning parameters and the tradeoff between responsiveness and audibility. Fast moves make a slicing noise which is compounded by multiples faders moving at the same time. So, banking channel groups is the loudest. Following ramps and fade-outs is not noticeable but the fader often doesn’t come to rest at the right spot. As such you get a jump in value when touching the cap. I plan to tune more later but using PID for motors is a bit of a bad spot since PID assumes a linear system but real motors are not… they have inertia, backlash, etc. but you can get close with effort and modest expectations.

Some of my most recent software changes were to have the master microcontroller send PID tuning values over I2C at startup. Since that is the one connected to the host computer by USB it’s been easy enough have the IDE open for tweaks while testing. But I allow myself no more software work until the thing is built because I get distracted.

 

[ccaudle]

the fader often doesn’t come to rest at the right spot.

I think that indicates it needs a higher I value.

PID assumes a linear system but real motors are not…

But that can be modeled as a linear system with perturbing error term. PID is used for motor control in robotics all the time, it works fine when you get it tuned.

 

[bjosephs]

I think that indicates it needs a higher I value.

Increases the Integral constant also increases the risk of oscillation/instability and contributes to a windup problem that needs managing. I found parameters that provided really good resolution to finding position but they weren’t pleasant to listen to when tracking slow automation ramps. I experimented with differently tuning for different distances. I also found that, for whatever reason, braking was better in one direction than the other. At some point I’ll return to that part of the science project but real-world systems never get to perfect.

But that can be modeled as a linear system with perturbing error term. PID is used for motor control in robotics all the time, it works fine when you get it tuned.

Yes with higher complexity, possibly some auto tuning support, and a different set of ideal outcomes depending on application. In robotics we hit walls on what the trade offs can yield too.

 

[zamproject]

HUI uses 10 bits but breaks it into two messages. The host shifts and appends them together, the same happens at the controller. So two 7-bit values are sufficient. Maybe there are other barriers I’m not aware of for you.

Now in HUI mode my DAW only send MSB 0-127(7bit) steps and LSB is 4 steps (in 7bit format...) value 0-31-63-95 only
it end with 128x4 possible value 512steps, 9 bit

I quote myself from 2017...never try with other DAW

I found parameters that provided really good resolution to finding new positions but they weren’t pleasant to listen to when tracking slow automation ramps

Did you check and monitor ADC from servo track ? as voltage ref for noise or variation, dedicated regulator is a good thing as motor instant current call can bend the rail, and shift the servo ref if supply are shared somehow.
You don't need that many mV drop to read false value from servo, @10bit 1 step is 5mV (for 5V ref)

I also found that, for whatever reason, braking was better in one direction than the other

That may be the a limitation of those ALPS faders, I evaluated them in the past (they had a version with audio+servo)
I ended up with TKD fader, quality and mechanical design is far better (as the price...)
But for a DAW controller only those ALPS should be fine, it's a physical feed back only that can tolerate some inaccuracy.
You don't care for some millimetres miss target as far as the DAW volume is right.

As such you get a jump in value when touching the cap

If you can't fix this mechanically by tweaking the PID for accuracy that assure you a reposition tolerance below bit depth, you may add a comparison routine at soft side to not send new position value before x% change from previous value.

 

[bjosephs]

I quote myself from 2017...never try with other DAW

Apologies, HUI is 9 bit. My ADC is 10 but only 9 are used on either end.

Did you check and monitor ADC from servo track ?

I didn’t take the option of a dedicated regulator but I am using a lot of filtering and the external reference function of the atmega 328. I’m also averaging some number of samples over time (20-50, I don’t recall right now). I did have to add some code to quantize up at the second to highest possible position (something like +9.9dB in the DAW) because rounding of that value resulted in jitter.

You don't care for some millimetres miss target as far as the DAW volume is right.

A few millimeters is pretty big jump at the bottom end of the scale. I’m not sure it matters much in practice.

If you can't fix this mechanically by tweaking the PID for accuracy that assure you a reposition tolerance below bit depth, you may add a comparison routine at soft side to not send new position value before x% change from previous value.

I tried this at some point but what happens is that small movements that are intentional can end up being ignored. Another tradeoff. I also played with having to slide below the previous known value before reading but that isn’t great in all circumstances either.

 

[zamproject]

A few millimeters is pretty big jump at the bottom end of the scale. I’m not sure it matters much in practice.

Should not, but you may check. I say few mm but thinking less, at 9bit a step is 1/5mm
What is the offset monitored from DAW (midi) value VS actual ADC value (midi converted) when fader is (miss)repositioned ?

Did you implement some dead band at top and bottom ?

If not already, you probably need a scale map, because servo and ADC will probably never see 0.000V at bottom on 5.000V at top, if it's the values you expect to send 0x0000 and 0xFFFF, which can also be a reason for offset between DAW midi value and ADC feed back.
Also it's a very convenient way to scale and custom the fader travel/law, some DAW have strange curve which you don't care from virtual fader and may or may not be scaled differently when sending CC or pitchbend to external world, but became problematic with a remote at your fingertips.
e.g. my DAW top is +6, mid pos is -4, 10dB for half travel and 100+ for the bottom half, pushing a manual and instinctive fade-in with more or less constant speed on a 100mm fader result in a wrong fade-in perception.

IIRC there is some DAW/controller that offer a flip to go in relative mode.
Whatever the fader position is, it flip mid travel, and you have +/- xdB from there.
Could be a nice feature, I was not able to implement it, as my fader pass audio I need an absolute and precise tracking between DAW value and fader real attenuation.