[SOLVED] Can only set values of faders in 0.5 increments

[joe-b]

Using 3.1.1 on debian buster.

I can use the mouse to adjust fader levels (only in increments of 0.5 db or 1.8 db). Whenever I type in a value it rejects it. Also, control or shift does not allow the mouse to make finer adjustments; it's always 1.8 db increments for the scoll wheel or 0.5 db increments for mouse clicks/slider adjustments.

Am I missing something?

[Tim E. Real]

Hello. (How did you get the 1.8dB increments? Was that the audio or midi strips?)

So the keyboard and mouse and wheel increment by 0.5dB
and the keyboard can be accelerated to 5dB steps with Shift.
A slight oversight I suppose, the mouse wheel or mouse buttons do not appear to be accelerated.
I thought I had added that at some point, must check further

The entry boxes allow direct entry but they round off to the nearest 0.1 dB.
Any further increment by mouse or keyboard round off to the nearest 0.5dB or 5dB again.
Be sure to press enter after typing the value

Some sane rounding was required because all of our audio controllers are linear and you are seeing a logarithmic
representation of just one of them - the volume. I didn't want long strange unwieldy values in the volume boxes.
It was quite hard to ensure the stepping worked.

Ironically though, if you draw a volume audio controller graph in the Arranger, this does allow long floating point values,
simply because of the pixel placement and the interpolated values between points.
But ultimately the volume boxes still show a rounded value for compactness.

[joe-b]

Thanks for replying. I get 1.8 db increments by scrolling the mouse wheel up or down over the fader. This is for audio tracks.

The entry boxes allow direct entry but they round off to the nearest 0.1 dB.
Any further increment by mouse or keyboard round off to the nearest 0.5dB or 5dB again.
Be sure to press enter after typing the value

This absolutely does not work for me. For instance if a track is 0.0 db on the fader and I enter 0.2 and press enter, it immediately reverts to 0.0. Also I do not understand allowing 0.1 db increments in a text box but not using the mouse in a DAW.

I've just noticed the same behavior whether I use 3.0.2 or 3.1.1. I'm guessing this is a problem with my system? Any ideas?

[joe-b]

So I am wondering if I can change the following line in 'astrip.cpp' and re-install:

Code: Select all

const double AudioStrip::volSliderStep =  0.5;

By making the volSliderStep 0.1, will I unwittingly cause problems elsewhere? Is this even the right thing to change? I am guessing more changes would have to be made elsewhere. I am not a programmer, obviously.

[spamatica]

So I am wondering if I can change the following line in 'astrip.cpp' and re-install:

Code: Select all

const double AudioStrip::volSliderStep =  0.5;

By making the volSliderStep 0.1, will I unwittingly cause problems elsewhere? Is this even the right thing to change? I am guessing more changes would have to be made elsewhere. I am not a programmer, obviously.

That should be perfectly fine to edit. What value do you think it should be, 0.1?

Also, I can reproduce that it steps 1.8 on regular mouse wheel with 3.1.1, weird.

This absolutely does not work for me. For instance if a track is 0.0 db on the fader and I enter 0.2 and press enter, it immediately reverts to 0.0

Not sure how that can happen, if the track is set to Read and there is volume automation it will not accept the value but I don't think it will behave like that.
We've had trouble in the past on non-english languages that use decimal comma instead of decimal dot, but I believe that is taken care of.

[joe-b]

I guess the problems are somehow with my setup, but I wouldn't know where to look.

Anyway, I changed the line in 'astrip.cpp' to 0.1, and now I can use the gui slider for 0.1 db increments. Thanks for your help.

[Tim E. Real]

Not sure how that can happen, if the track is set to Read and there is volume automation it will not accept the value
but I don't think it will behave like that.

True. If the strip is set to automation 'Read' and there is an automation graph, any value entered in the box or adjusted with the slider
will be overwritten by the graph value - but only if the transport is playing or the play head cursor is moved otherwise it should
allow a value to be set.

So the boxes will not accept any value at all? Strange.
Feel free to post your ~/.config/MusE/MusE/MusE-seq.cfg file and an example *.med song file, I'll take a look.

I now see the 1.8dB steps, it is only with mouse wheel over the actual fader, not the box.
Probably an oversight. These things are often developed separately with intense focus on each one at the time - the slider, the box, the wheel -
and sometimes we overlook what the other things do, like the 'right hand not knowing what the left hand is doing'.
Must check if wheel step is set properly for the fader sliders...

[joe-b]

Just to be clear, I'm now satisfied with using the fader instead of the text box.

But if you want to look further, here is my ~/.config/MusE/MusE/MusE-seq.cfg file and a .med file (gzipped because I can't post certain file extensions). Any .med file produces the behavior for me, including the startup file. One thing I didn't try is removing the .cfg files and re-starting MusE.

[Tim E. Real]

Thanks.
Tested, could not find any trouble
The boxes accept what I type.

Hmm, just a guess, possible window manager problems?

[joe-b]

Thought about that. I only have herbstluftwm (a tiling wm) and openbox installed. The problem persists in both window managers.

Wait a minute, I can get the text box entry to work, but only if I delete the existing text including the 'dB' that is written in the text box. All this time I think I've only been highlighting and deleting the number and not the 'dB'. Don't know if that helps, but thanks for looking into this.

So for example, if I have '0.5 dB' in the text box, and delete only '0.5' and type '1.2' (leaving 'dB' alone), and press enter, it reverts back to '0.5 dB'. But if I delete the entire entry of '0.5 dB', and type '1.2' and press enter, it does work. Sorry for not noticing this earlier.

[Tim E. Real]

Ha! I thought about whether that might be the problem.
Yeah, slightly unusual behaviour I suppose.
If I recall, the boxes are custom, not 'stock', Qt boxes.

[spamatica]

Wait a minute, I can get the text box entry to work, but only if I delete the existing text including the 'dB' that is written in the text box. All this time I think I've only been highlighting and deleting the number and not the 'dB'. Don't know if that helps, but thanks for looking into this.

So for example, if I have '0.5 dB' in the text box, and delete only '0.5' and type '1.2' (leaving 'dB' alone), and press enter, it reverts back to '0.5 dB'. But if I delete the entire entry of '0.5 dB', and type '1.2' and press enter, it does work. Sorry for not noticing this earlier.

Gotcha!
It was actually not that hard to improve so the I've pushed a fix to master, such that the dB text can be left intact.

I'm thinking we should change the scroll wheel value distance too but haven't gotten around to it (unless someone else did).

[Tim E. Real]

Nice. Good one! Thanks, RJ.

[kybos]

I fixed the mouse wheel event for the audio volume slider.
Default step is now 0.5 (instead of the oblique values like 1.8 ), holding Shift + mouse wheel the step is 0.1.

[Tim E. Real]

Thanks again!