Live data from Hacker News

Deej: An open-source hardware volume mixer for Windows and Linux

github.com

41–50 of 57 posts

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#41
post #12

You can buy premade MIDI faders for about $25 [0], there's no way that the hardware aspect of this project is worth making over that. The software is the only real issue, at a quick glance, [1] appears to be relatively equivalent for generic MIDI fader support, perhaps with a few more bells and whistles available. [0] https://www.aliexpress.com/item/1005005589381790.html (a chinese clone of the korg nanoControl 2, th…

Where’s the fun in that?

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#43
post #16

Earlier quoted context omitted.

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

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

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

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#44
post #16

Earlier quoted context omitted.

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, inc…

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

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?!

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#45

Earlier quoted context omitted.

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.

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…

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.

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#46
post #25

Earlier quoted context omitted.

Sounds like your hardware isn’t set right. The volume of your hardware device should be set so that it’s barely above comfortable listening volume when your device is at 100%, and then the device attenuation works from there. You probably have the hardware volume maxed out, which is also bad because it tends to run the amplifier all-out which will use much more power and generate more heat, as well as having lower dy…

I never have my hardware "maxed out". Usually barely 50%. But anyway, all of my Windows using friends have the same problem and find it equally ridiculous. Seems like whatever Windows does by default on our machines is just a not working so well default.

I've worked with hundreds and hundreds of users over a decade and this is not a thing, no idea what you're talking abut. Learn to set your gain properly on your external amplifier, it's a you problem, not Windows.

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#47

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.

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.

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#48
post #3

What I really need is a software bass/treble control that can be mapped to keyboard shortcut.

While this is certainly possible to hack together using LADSPA [1] plugins it may be easiest to use something like e.g. Easy Effects [2], configure some sound profiles - 'music', 'voice', 'video', '...' - and configure some key combinations to load these on demand using easyeffects -l . As to how to bind these keys depends on your operating environment, this is how it could look in e.g. Xmonad (which is what I use):

   newKeys conf@(XConfig {XMonad.modMask = modm}) = [
     ((modm .|. shiftMask, xK_m), spawn "easyeffects -l music"),
     ((modm .|. shiftMask, xK_v), spawn "easyeffects -l video")
      ]
In this (contrived) example you'd press SHIFT-L_ALT-m to enable the 'music' profile, SHIFT-L_ALT-v for the 'video' profile.

You can also make a script which cycles through available plugins and bind that to a key, showing which plugin is activated when the key is pressed. There are many ways which lead to this version of Rome, choose the one you like best.

If you're using Gnome there is an extension which does most of the work:

https://github.com/wwmm/easyeffects/wiki/Preset-Selector-GNO...

(quote) It basicly adds a button to your top panel. Then you can click on it to see your available presets and click one to activate it without opening EasyEffects window. It also adds keyboard shortcuts to cycle through available input and output presets. Those can be set from extensions preferences window. Default keybindings are Ctrl + Super + o for output and Ctrl + Super + i for input presets.

[1] http://www.ladspa.org/

[2] https://github.com/wwmm/easyeffects

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#49

Earlier quoted context omitted.

I never have my hardware "maxed out". Usually barely 50%. But anyway, all of my Windows using friends have the same problem and find it equally ridiculous. Seems like whatever Windows does by default on our machines is just a not working so well default.

I've worked with hundreds and hundreds of users over a decade and this is not a thing, no idea what you're talking abut. Learn to set your gain properly on your external amplifier, it's a you problem, not Windows.

Your experience does not invalidate my experience. I have had the same bad behavior across multiple versions of Windows, using multiple different loudspeakers, headsets and headphones, all the while it worked perfectly well in GNU/Linux distributions, where I can set volume like a sane person would, instead of like on Windows, where I need to micro management between 1 and 5 out of 100.

The fact, that this is a well known issue, that basically all my friends know about, having it right now, and in the past using various audio output devices themselves, tells me, that it is not a "me problem", but actually something that in general does not work so well in Windows. They have all accepted, that Windows volume mixer simply does this and that there is nothing that they can do. They are not regular GNU/Linux users like I am, so they are stuck with that.

Consider, that you might be in some kind of bubble, with your fortunate experiences. Consider, that maybe you did not understand the problem I am describing well. Since you are talking about "external amplifiers", makes me doubt, that you understand correctly what I am talking about. Note, that I have already stated, that I do not put volume externally to any maximum, like someone claimed earlier. So either you claim, that I am lying, or you do not understand what I wrote.

Perhaps you should rather ask questions about the issue and try to be helpful, instead of going on assuming and pretending the problem does not exist, when it very much does and you simply seem blissfully unaware of it.

I also find your tone quite in conflict with this site's rules. It is quite rude.

Re: Deej: An open-source hardware volume mixer for Windows and Linux

#50

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.

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 th…

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.

Post reply on HN