allow to change volume at higher resolution #100

landroni · 2015-09-11T18:54:48Z

Please allow for more fine-grained volume changes. While the default percentage steps, 1% or 5%, work very well for a majority of users, there are cases when a user would need 0.1% steps. For instance some USB DACs have so much power, that already at 4-5% it already gets too loud for safe listening, while 1% may be too low. With traditional stepping it's hard to find a useful sound level.

One way to deal with this would be to allow decimals in Mouse Scroll Step. For instance a step of 0.1% would be a big improvement. In addition to this, a Scroll Step for the pop-up dialogue would also be useful; now it seems to default to 1% or in the whereabouts, but allowing to go in the decimals would help.

Some mixers provide this feature. QasMixer has an unfortunately named Number of turns for a slider change. Maxing it allows for about 4-5 steps within a percentage (i.e. ~0.2pp resolution). Here's how their option looks like:

The text was updated successfully, but these errors were encountered:

hasufell · 2015-09-11T19:21:16Z

elboulangero · 2015-09-14T08:41:57Z

Allowing decimal numbers for Mouse Scroll Step preferences is probably not a problem.

For the popup dialog, I think it would make sense that the Mouse Scroll Stepalso applies here. For the moment, there are two hard-coded values for the popup:

<property name="step_increment">1</property>
<property name="page_increment">10</property>

step_increment is used when hitting up/down when the slider has focus. page_increment is used when hitting Page up/down, but it's also used when mouse-wheeling on the slider.

Alright, let's suppose that the Mouse Scroll Step is also used for the slider. I think first, we should rename the preference in something else, like Volume Changing Step (feel free to have a better idea for the name :)). We can't let it named Mouse Scroll Step since it would apply to keyboard hitting also.

Now, the mapping: I'd say that we map this Volume Changing Step to step_increment. Because when you use your keyboard to change volume, you're more likely to use up/down rather than Page up/down. I mean, if you define Volume Changing Step to 5, then you go changing the volume with up/down, you expect that the volume will change 5 by 5. We could define page_increment to be automatically defined to step_increment * 10, then when a smart user uses Page up/down, he's happy, it's probably what he wants.

Ok, the only problem with this mapping is that currently, mouse-wheeling on slider is tied to page_increment. I'll dig a little bit to see how we can tie it to step_increment instead. If it's possible, I'll go for that solution.

OK, so to sum that up: we would have only one setting in the UI Volume Change Step. It would apply to mouse-wheeling on the icon, on the slider, and up/down keys from keyboard. Page up/down would change the volumes with a step ten times bigger.

Simple and consistent. What do you think of that ?

landroni · 2015-09-16T10:52:55Z

Could work...

we would have only one setting in the UI Volume Change Step .

I thought about this and I can't make my mind if it's better to have one or two settings for this. Maybe others have an opinion. I can see arguments for and against each solution, so it will be a matter of developer preference.

The argument for keeping things separate (as it is now) is that people may be using rough steps (e.g. 5%) scrolling while hovering the icon, and fine steps (e.g. 0.5%) when popping up the slider. I think this arrangement is intuitive and makes sense. This would imply though adding another pref, which might be confusing UI-wise.

we should rename the preference in something else, like Volume Changing Step (feel free to have a better idea for the name :))

Scrolling is not reserved for mouse wheels. I think Volume Scroll Step would work just fine, be it keyboard- or mouse-based scrolling.

Page up/down would change the volumes with a step ten times bigger.

This could be hardcoded (OK as far as I go) or a separate pref (but this might feel like too much for the GUI).

Allowing decimal numbers is ultimately the key part here and hopefully an easy one.

elboulangero · 2015-12-17T05:10:34Z

See Pull Request #115

After giving it a second thought, I implemented it exactly as you suggested @landroni, it seemed the easiest and the most intuitive. See screenshot below:

Basically everything is tied to Scroll step, except Up/Down keys from keyboard which are tied to Fine Scroll Step. See commit message 677b370 for more details.

Any comment ? Otherwise I'll merge that

elboulangero · 2015-12-17T05:18:02Z

Now, you may notice that, in the HotKeys tab, we have another volume step defined just for Hotkeys.

So the current situation is that we have three volume step settings: two (normal step & fine step) that are used for both mouse and keyboard (when the popup GtkScale has focus), and another setting that is used for HotKeys.

We could make it simpler, and have only two settings (Hotkey would use the same scroll step as the rest).

Or we could make it more complicated and more flexible, and have four settings: one for the mouse scroll, two (normal step & fine step) for keyboard shortcuts inside popup, and another for Hotkeys.

At the moment we're halfway between the most complicated and the most simple solution...

Any thought on that ?

Scroll rework, allow volume change at higher resolution #100

elboulangero · 2015-12-21T02:32:21Z

Merged

landroni · 2016-02-06T07:09:30Z

Sorry for looking into this so late! Real life intervened.

I am trying to check out current master but something goes awry. After building fine, I want to run pnmixer in place (without installing), but it ends up with this error:

** (pnmixer:12507): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-6LQazRtFk7: Connection refused
Can't find the volume popup window interface file. Please ensure PNMixer is installed correctly. Exiting.

Is this expected?

elboulangero · 2016-02-06T08:15:47Z

Not really. But wait a little bit. I'm currently in the process of re-writing a big deal of PNMixer code. Doing so I found that the changes I made regarding this ticket were not complete. I missed plenty of things, so the "higher resolution volume changes" is probably bogus on the master branch.

However I think I'll be done with the PNMixer rewriting in a few days. At this moment, I will need people around to help me with testing. If you're available, it will be great !

landroni · 2016-02-06T08:55:37Z

Sounds great. Will try the code in the following days.

elboulangero · 2016-02-08T10:02:30Z

@landroni Check #120 for discussion, and also for the branch to checkout and test.
Cheers !

elboulangero · 2016-02-08T10:27:35Z

I remember that you had a weird setting with different cards etc... It would be great if you could test that a little bit again. Here I don't have a USB dac anymore, the best I could do was to create a dummy virtual alsa card and play a little with it. But it can't be as complete as the test you can do with your setup.

landroni · 2016-02-08T16:13:04Z

I'm trying the pnmixer-dirty branch and I still get an error when executing in place (without make install):

/home/geek/Build/Devel/pnmixer-dirty/pnmixer/src/pnmixer (4228)

** (pnmixer:4228): WARNING *: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-cm8tMrUfrt: Connection refused
*
ERROR:ui-popup-menu.c:223:popup_menu_create: assertion failed: (uifile)

/home/geek/Build/Devel/pnmixer-dirty/pnmixer/src/pnmixer (4228) returned '6'

I am not sure if something is wrong with the local setup or not. In any case, right now I'm using Alsa but no fancy USB DACs.

elboulangero · 2016-02-09T08:01:06Z

The "WARNING"comes from Glib or Gtk+, given the look of it. I never saw this warning before, but I don't think it's relevant.

The error means PNMixer don't find the UI file. I think I know what's wrong. When you start PNMixer from source, ALWAYS launch it from the root directory. That's to say, DO NOT do cd src && ./pnmixer, but instead DO ./src/pnmixer.

This is because PNMixer looks for the files it needs in ./data/... first, then in your system . If you don't launch it from the root directory, it will not find the files, or it will pick up the files installed on your system (if it's installed), but they may be outdated.

elboulangero · 2016-02-09T08:06:17Z

Please also ensure that your git directory is clean (git clean -dfx is my favorite), that you start well from scratch with ./autogen.sh, this kind of things. I guess you do that already, but just to be sure :)
Also don't forget that you can run PNMixer with the -d option to see what's happening.

landroni · 2016-02-09T08:08:16Z

Exactly! I must have forgotten this. Now it launches.

Here are some messages on hte console:

/home/geek/Build/Devel/pnmixer-dirty/pnmixer/src/pnmixer (11348)

** (pnmixer:11348): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-cm8tMrUfrt: Connection refused

(pnmixer:11348): Gtk-WARNING **: Unknown property: GtkAccelLabel.margin-start

(pnmixer:11348): Gtk-WARNING **: Unknown property: GtkAccelLabel.margin-end