[prmoustache]

Unless the faders are motorized, which I believe are expensive, I don't see how you can make that thing work reliably without some nasty surprises.

What happens if you change the levels through software and your faders do not move?

I would just have used rotary encoders.

[i_am_proteus]

There are elegant ways for handling actuator/software mismatch for actuators with finite travel, like pots and faders.

Most schemes involve scaling the available fader travel to the "available" software travel.

Ex: Fader at 40%, software at 60%. Fader motion "up" between 40-100 moves software "up" between 60-100. Fader motion "down" between 40-0 moves software "down" between 60-0.

There are various other schemes, including multiple regimes and nonlinearity. Programmable synthesizers have dealt with this for many years. See pp13-14 of this manual for an example: https://www.davesmithinstruments.com/wp-content/uploads/2015...

[Goz3rr]

What happens when software is at 0%, your slider is at 100% and you want to raise the volume?

[i_am_proteus]

You must move your slider down, and then up. It becomes reasonably intuitive with a small amount of practice :)

[actionfromafar]

Could have feedback with a LED ramp next to slider, showing the discrepancy...

[usrusr]

Down then up wouldn't be too bad, but up then down could very much be, in certain situations.

[squarefoot]

I would put a safety routine to let the software update only when the hardware is within a certain amount from the actual value, also giving visual feedback of the difference, so that the user could align hardware position to software position without any sudden changes.

[juujian]

You put the slider all the way down to 0, which is then mapped the the range from 0-0 and then you move it back up?!

[i_am_proteus]

Once the fader matches software, software follows the fader.

[magicalhippo]

They're not cheap, but not terribly expensive either. Adafruit has some[1] for $25, with 5V DC motors which is convenient. On DigiKey and Mouser there are some slightly cheaper[2] but with 10V motor.

[1]: https://www.adafruit.com/product/5466

[2]: https://eu.mouser.com/c/passive-components/potentiometers-tr...

[RUnconcerned]

Audio software will typically allow you to configure a soft takeover, where you must move the fader or knob until it matches the software value, and only then does it take over, to eliminate these surprises.

Rotary encoders are just not as good for controlling volume as faders.

[3D30497420]

Curious why rotary encoders aren't as good. I'm guessing because you cannot visually see the volume or the potential range based on the state of the interface? (E.g., How much is 1 tick of the rotary encoder? Who knows?)

I've been thinking about using a rotary encoder for lights to deal with this problem specifically (light state being out of sync with a fader/pot). I figure I'll just have software figure out the new state based on the user interaction.

[usrusr]

Either not enough resolution to tweak some nuance or too many rotations needed for a wide swing. Perhaps rotaries with 256+ increments per rotation exist, but I think most are much lower. A sample I just checked seems to have 64 per turn, pleasantly surprised but still not really there yet. The 128 values of a legacy MIDI CC are typically over 270 degrees I think.

[munificent]

This is an ancient problem which has been around since synthesizers first got patch memory in the 1970s like the Prophet-5.

There are a number of ways to handle the knob or fader's physical position not matching the current value:

* As soon as the control is touched, it becomes "live" and the value jumps to wherever it is. This is the simplest, but most disruptive approach because a value can jump abruptly.

* When the control is moved, it has no effect on the value until it physically reaches where that value is. This avoids any disruptive jumps, but can be confusing because a control feels "dead" until you reach the right point to get it alive again.

* I think there are other approaches where moving the control starts interpolating the live value to where it is.

There's no perfect solution, but it's tractable and not a huge issue in practice. Motorized faders are nice but very expensive and have shorter life spans.

For knobs, you can more easily avoid it by using endless encoders instead of potentiometers and then interpret its current location as the current value. (For example, Elektron hardware and the Hydrasynth take this approach.) But you lose the nice tactile affordance of having the knob stop at either end of its extent.

[prmoustache]

Those tradeoffs are what I meant by nasty surprises. The solution 1 would be totally unacceptable to me.

And yes by rotary encoders I meant those that rotate indifinitely. And I miss my Elektron Model:Sample, too bad it lacked the sampling function otherwise I would have kept it.

[munificent]

The Digitakt is calling to you...

[Mashimo]

The trick is to train yourself to always use the hardware :D

But like the others said, Soft-takeover has been a thing for many many years.

I would use the pots, you still have software vs hardware problem, but don't need to fiddle with small sliders when you just want to change the volume a tiny bit.

[Nexxxeh]

>What happens if you change the levels through software and your faders do not move?

Wouldn't your software changes are overwritten by the absolute values from the Deej? That wouldn't be a surprise.

I haven't dug through the code for the app, so I don't know if it monitors the levels in software and immediately corrects them with the hardware values, if it loops at a specific interval, or only triggers on significant hardware value change.

But if not monitored, I can't imagine it would be an insurmountable task to add.