3 ms·

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 happen

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.

RUnconcerned 3y ago
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 3y ago
  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 3y ago
    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.
Nexxxeh 3y ago
>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.
i_am_proteus 3y ago
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/05/Prophet-6-Operation-Manual.pdf https://www.davesmithinstruments.com/wp-content/uploads/2015...
- Goz3rr 3y ago
  What happens when software is at 0%, your slider is at 100% and you want to raise the volume?
  - i_am_proteus 3y ago
    You must move your slider down, and then up. It becomes reasonably intuitive with a small amount of practice :)
    - actionfromafar 3y ago
      Could have feedback with a LED ramp next to slider, showing the discrepancy...
    - usrusr 3y ago
      Down then up wouldn't be too bad, but up then down could very much be, in certain situations.
  - squarefoot 3y ago
    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.
Mashimo 3y ago
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.
magicalhippo 3y ago
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 https://www.adafruit.com/product/5466 [2]: https://eu.mouser.com/c/passive-components/potentiometers-trimmers-rheostats/slide-potentiometers/?type=Motorized%20Slide%20Potentiometer&qty=1 https://eu.mouser.com/c/passive-components/potentiometers-tr...
munificent 3y ago
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 3y ago
  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 3y ago
    The Digitakt is calling to you...

RUnconcerned 3y ago

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 3y ago
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 3y ago
  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.

Nexxxeh 3y ago

>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.

i_am_proteus 3y ago

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/05/Prophet-6-Operation-Manual.pdf https://www.davesmithinstruments.com/wp-content/uploads/2015...

Goz3rr 3y ago
What happens when software is at 0%, your slider is at 100% and you want to raise the volume?
- i_am_proteus 3y ago
  You must move your slider down, and then up. It becomes reasonably intuitive with a small amount of practice :)
  - actionfromafar 3y ago
    Could have feedback with a LED ramp next to slider, showing the discrepancy...
  - usrusr 3y ago
    Down then up wouldn't be too bad, but up then down could very much be, in certain situations.
- squarefoot 3y ago
  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.

Mashimo 3y ago

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.

magicalhippo 3y ago

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 https://www.adafruit.com/product/5466 [2]: https://eu.mouser.com/c/passive-components/potentiometers-trimmers-rheostats/slide-potentiometers/?type=Motorized%20Slide%20Potentiometer&qty=1 https://eu.mouser.com/c/passive-components/potentiometers-tr...

munificent 3y ago

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 3y ago
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 3y ago
  The Digitakt is calling to you...