My DIY HUI DAW Controller

[bjosephs]

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 ?

In terms of dB, any given distance will be a fraction of a dB near unity and several dB on the low end of range. That’s what I’m referring to.

Did you implement some dead band at top and bottom ?

Nope. Going to -infinity works fine and jitter at the top of scale, where the value would bounce between +9.9 and +10dB, was solved with some rounding up. Basically the value +9.9dB is afforded half the range of other nearby dB values. In practice it’s not noticeable.

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.

I didn’t need this. Probably because I’m using the external reference on my ADC. It will account for fluctuations. The actual read values off the slider are consistently 0 to 1023.

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.

I recall playing with this but dropping it. I don’t think HUI supported “flip” natively. I tried to implement my own and was able to easily have the encoders trim the faders, but going the other way, V pots can only accept incremental values so there’s no way to reposition the faders off them.

Instead I built a pretty decent midi map into the faders and encoders. My DAW can learn CC messages and communicate bidirectionally. So, in midi mode I can, say, have the encoders alter an EQ frequency and the faders the +/- level of the band. It worked better than I thought it would.

Now that you have me thinking abut it I maybe add back in the ability to use the encoders for small fader level moves. I have some extra button space in the master section.

 

[zamproject]

Nope. Going to -infinity works fine and jitter at the top of scale, where the value would bounce between +9.9 and +10dB, was solved with some rounding up. Basically the value +9.9dB is afforded half the range of other nearby dB values. In practice it’s not noticeable.

Dead band also offer a safer hardware handle, to avoid any motor stall condition at full top or bottom if fader servo track/ADC can't send extreme value for any reason (like small voltage drop at the end of Vref wire string)
One mm at top and bottom is enough (98mm effective fader travel)

 

[bjosephs]

Dead band also offer a safer hardware handle, to avoid any motor stall condition at full top or bottom if fader servo track/ADC can't send extreme value for any reason (like small voltage drop at the end of Vref wire string)
One mm at top and bottom is enough (98mm effective fader travel)

Well that is 100% true. Though I will say that when you are only a few bits away from the target value the PID output constants are so low it might be impossible to drive the motor to a damaging level. Assuming the integral term is capped or reset periodically. I’ll put it on the list of things to review/change when I’m back on to software stuff. Thanks.

 

[bjosephs]

Ran into some trouble today. While soldering my signal LEDs I noticed some of the buttons were crooked or at different heights. As noted above I am using mezzanine headers with a controlled space but it seems that with enough (and sometimes not very much) pressure the plastic material that sets the gap distance will slide - not good. After reviewing options and thinking about how to control the gap I decided to canibalize the spacer material from extra headers and stack them up. I don’t like the height that three spacers gets me but 4 may be too much, so I’ll sleep on it.

Also please not that in one of the pictures below the contacts look blackened. It’s just a photo artifact they are still shiny gold.

 

[zamproject]

Though I will say that when you are only a few bits away from the target value the PID output constants are so low it might be impossible to drive the motor to a damaging level.

It's hard to blow a motor for sure, but it can unnecessary stress the belt on long term, and the driver (h-bridge ?) may keep an unrelaxed state that seek unnecessary current consumption.
At soft side on my system I add a script that hardware bypass (via a fet switch which first function is to hold the PID/motor driver when touch is activated) that deactivate the motor after 5 sec if not moved, this save me tens of mA for 16 faders in static position when all PID still to push a little.
The driver wake up instantly on incoming midi message (pitchbend in my use case) or after fader being manually moved and touch cap released.

 

[bjosephs]

At soft side on my system I add a script that hardware bypass (via a fet switch which first function is to hold the PID/motor driver when touch is activated) that deactivate the motor after 5 sec if not moved, this save me tens of mA for 16 faders in static position when all PID still to push a little.

This is a good suggestion and one I’ll look at integrating later. If the midi commanded position hasn’t changed for a few seconds then stop running the PID loop. Makes sense.

 

[bjosephs]

I ended up ripping off the plastic header parts and replacing them with a 3D printed spacer that more reliably sets the button height. I also soldered in the LEDs with some printed standoff supports that keep the LEDs aligned while I wrestle the fader modules in place.

 

[bjosephs]

Ran into a little (big?) problem. For some reason the PCBs don’t seem to be 90 degrees square to the fader or, for some other reason, most of them end up non-parallel to the panel. This causes the LEDs to protrude a bit and it will complicate plans to add a support to the back of the boards. Here’s some pictures. Time to sleep on things again…

 

[bjosephs]

I decided to throw all the channel related stuff together so I can uncover as many problems as possible before solving any. Here are some pictures.

Channel 2’s touch sense is not working well, sometimes ignoring touch and rarely relinquishing control after a touch. Something to work on later. Edit: I tried swapping in a backup module but that one had more problems so I did tiny SMD surgery and replaced the AT42QT1011 chip.

All the encoders work as expected.

I still need to decide on my button colors for the master section, solder up another teensy microcontroller with low profile headers to fit under the encoder, and install said encoder in the master section. That encoder is set up to bank through DAW channels or shuttle the DAW timeline.

 

[zamproject]

Mechanical integration is always fun....

I know the whole seem already designed, so I can just talk from far away without abilities to touch and feel the construction strength.
But from there, having all the button on a solderer sub-board to fader board with cantilever, which fader board only rely on soldered fader pin to be attached to front panel (via only 2 fader screw that may not have that many effective threads ) is asking for trouble.

I'm sure you'll find a solution with spacer or whatever to help support from the back of the enclosure.

I get a completely different constrains for my mechanical integration, but here it is how I handle the button support.
With 3 studs/bolts on longitudinal axis, no bend at all...
By the way good choice for the illuminated button, I made this same (expensive) choice,they look great and are strong.
Almost one decade of use here, so far no issue.
They can be very bright in dark environment, you may or may not implement a dim function (here it's done at soft side, SRIO scan)

 

[bjosephs]

But from there, having all the button on a solderer sub-board to fader board with cantilever, which fader board only rely on soldered fader pin to be attached to front panel (via only 2 fader screw that may not have that many effective threads ) is asking for trouble.

No argument there. The intent was to keep the surface mount soldering sections small, make swapping out a bad fader a little easier, while avoid fasteners though the face.

I'm sure you'll find a solution with spacer or whatever to help support from the back of the enclosure.

The two ideas I have right now are 1) a single stiffening bar running through a clear section in the back of the PCBs (between the third and fourth button) held on with a gentle adhesive tape like the kind used on apartment walls or 2) a pan that occupies all of the available surface area held in place by slim brackets attached to the back of the front panel either with some additional screws or a strong adhesive.

I get a completely different constrains for my mechanical integration, but here it is how I handle the button support.
With 3 studs/bolts on longitudinal axis, no bend at all...

I like it a lot. It looks like you have an overlay to hid the face fasteners. I should have considered that.

 

[zamproject]

The intent was to keep the surface mount soldering sections small, make swapping out a bad fader a little easier, while avoid fasteners though the face.

Yes, that's what i thought looking at how you made it.

It looks like you have an overlay to hid the face fasteners.

Looking for the same en result as you, minimal visible screw (I had a modular console aesthetic to keep), but here I don't use sandwich faces, but insert studs !
https://docs.schaeffer-ag.de/en/elements/studs_standoffs.html

 

[bjosephs]

Ok well the last place where I thought things could go horrible wrong was cramming all the wiring for the scribble strips and jog wheel next to the microcontroller and ribbon cable. I had to make the encoder wires a bit longer to ease handling and routing but shockingly it fits. The wheel I bought seems a bit tall right now - I may print my own…

The last thing is to decide how I want to lay out my master section buttons and solder up the mezzanine PCBs for them.

I’ve been leaning towards the first column being the automation modes. My DAW supports 4 plus “off” so I can either use 5 buttons or have the current selected mode turn auto to off when pressed again. I actually have that implemented

The second column will be encoder functions. They obviously do pan but HUI supports 5 sends. I also have my midi controller functions to turn on/off and a future “flip” (or really “trim”) where the knobs will send fader data for fine tuning.

I end up with a couple extra buttons I think so I need to add some more stuff. Or allocate the two lowest buttons on column 1 and 3 to banking the channels in groups of 8. More sleeping on it.

 

[zamproject]

For some reason the PCBs don’t seem to be 90 degrees square to the fader or, for some other reason, most of them end up non-parallel to the panel

As you probably fit the fader correctly, this may be some tolerances between front fader plane and fader leg spacer alignment (this is long leg version right ?)
You may try to reflow fader pin, all attached to the frontpanel and temporary spacer/sqare for the pcb, to align them in place...

 

[zamproject]

’ve been leaning towards the first column being the automation modes. My DAW supports 4 plus “off” so I can either use 5 buttons or have the current selected mode turn auto to off when pressed again. I actually have that implemented

I implemented only 2 state + on/off, i can not use trim modes as my fader pass audio i can't decorrelate fader position to DAW value, but that's anecdotal for your use case.
The thing is I don't use automation master status mode set from dedicated button, each read/write button sets there own status (by sending global status + specific track n° at the same time).
With 2 button and two leds feedback i can trig all situations.
Push -read- you re in read mod (if automation already written), push again to stop, only involve read button/led
Push -write- you go in touch mode directly, overdub automation line, read (green) and write(red) leds ON, continue to read previous automation and stop writing, if you release the touch fader.
Push -write- a second time, overwrite mode, only red led, green if off, you only write, it continue to write value of the actual fader position touched or not, until you change mode or stop DAW playback.
In any situation , if you push -read- again, you read only, and push a second time you'r off, automation goes off as the two status leds, free hand fader.

The only draw back from this is that you can't read all different status for each fader with all DAW session when you open it.
So I add a call at one of my 16 -user- button that update all read/write buttons/leds according to tracks status in opened DAW session.
This is a single push button recall when I re-open a session, i leave fine with that, compared to the console/peripherial recall it's nothing...

All this to say that whit embedded programmable microcontroller, you can tweak everything, and any button can be more than just on/off for a single function like it is set on usual commercial HUI/MCU remote.
So yes, a signle button which toggle status/fuction might be better, I gess you can adjust that later according to practical usecase an personal workflow.

 

[Dusty Circuit]

Very cool project! Following this with great interest!

I have lots of questions but will keep it short.
I am curious about how the refresh or update timing work, are the faders read on a set intervall or by an int from the cap sensor? Or is the daw polling the controller?

 

[bjosephs]

Very cool project! Following this with great interest!

I have lots of questions but will keep it short.
I am curious about how the refresh or update timing work, are the faders read on a set intervall or by an int from the cap sensor? Or is the daw polling the controller?

The DAW doesn’t poll, it’s a midi based protocol so the controller sends a message with useful data whenever it has something to send. The microntoller in the master section handles the bidirectional USB and it has an I2C bus that connects it to the 8 microcontrollers in the fader modules. It prioritizes incoming midi data but, aside from that, it sends/receives to the modules as fast as the loop will allow. It also has its own buttons, an encoder wheel, and the screens to run, but those are fast.

The fader modules check the inputs as fast as possible. The capacitive sensor is a dedicated IC with a logic output and it is read like button press. If checks the buttons, fader, position, and local encoder, and updates a little data table of user inputs. When the master asks it sends the table. If the table comes back different the master runs though everything relevant and crafts little sysex midi messages to send to the DAW. The reverse happens when a message comes from the DAW: a different table of DAW status is sent to the fader modules with what LEDs should be on and where the fader should be.

In terms of controlled timing that is reserved only for the PID motor loop. That is because the D term relies on rate of change and if I add more code or lots of messages slow things down with the tuning values need to change or a timing calculation needs to be included. I prefer to set a modest control loop time and manage that. Basically an if statement says, “if it hasn’t been more than X mS yet, skip this. But if it has been more than X mS, run the PID”. I don’t recall exactly right now but it’s probably about 10mS.

The only interrupts are pin based for the encoders so they are very responsive to all movement.

It’s the master module that decides to send fader position to the DAW. If I see that the capacitive input is active on a channel it streams the current fader position from that channel to the DAW.

Hopefully I answered your question in there somewhere.

 

[Dusty Circuit]

Thank you for a very detailed reply!