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