Smarter equalizer frequency scrolling in Advanced etc

[umptious]

At the moment it is linear, so getting from 10kHz to 12kHz takes a hell of a long time - even though the perceived difference between these two frequencies is quite small. This isn't too bad with a scroll wheel player, but with button driven players like the Clip it is unnecessarily awkward.

So I suggest that either

1. the increment should be geometrical

2. the increment should increase with the length of time that scrolling in the same direction continues

3. that increment switch from being 10s to 20s at say 2000Hz, go to 50s at 5000Hz, and then to 100s at 10kHz

[umptious]

Ok.. the graphical equalizer is implemented in the same way. Same comment: this needs fixing! Hz are very misleading when you are thinking about human hearing: octaves are the true model of perception, and octavially speaking, the scroll rate reduces dramatically as you go up the frequency scale.

[saratoga]

This seems sensible enough, but I don't want to wade into the code badly enough to figure out how to change the increment to be nonlinear.

[JdGordon]

Yeah, this isnt trivial to implement, but if I have some time I may have a look (If i remember).

[umptious]

I'm really surprised -  I thought the third method had to be simple with any imaginable code base. Naively, I suppose, I envisioned

freq += 10

being replaced by

if (freq < 500) freq += 10
else if (freq < 2000) freq += 20
else if (freq < 5000) freq += 50
else freq += 100

..just goes to show you!

[[Saint]]

I thought this was already possible actually...but, if it is, I can't seem to "make it go"

Perhaps it is, and is just non-functional for whatever reason. Last time I was sniffing around where the steps are defined for cutoff, q, freq etc (eq_menu.c/h?) I noticed defines for EQ_*_FAST_STEP which pairs with EQ_*_STEP which made me think that someone thought of this at some stage in the past. I didn't follow it far enough to check to see if it was just another case of some confusingly named defines.


[Saint]

EDIT: Note that I'm aware this isn't quite the same thing - it's not a nice ramped curve - it's simply two distinct values.

[JdGordon]

I trhink the define you're talking about it used in the graphical eq screen, not the list (which should be doing acceleration automatically...)

[[Saint]]

I think what you are seeing is somebody removed the .5 increcment but you still have to press the button TWICE!! to incroment 1db.

Nope...no sir, they did not (The relevant define there is EQ_GAIN_STEP, which you can see is set to 5, or, 0.5dB). IFF the Clip Zip indeed does behave as you describe, I should think it a bug. I haven't checked to confirm or deny the claim, but I can say that none of my other devices behave in the fashion you describe, the gain stepping is correctly presented in .5db increments - and I see no reason for this to be target-specific.

I trhink the define you're talking about it used in the graphical eq screen, not the list (which should be doing acceleration automatically...)

It doesn't appear to be used there either...neither the GEQ or the lists appear to do so.


[Saint]

_{soap edit:  add opening bracket so url tag works.}