Fixed in r22252.

Made volume scrolling behavior much better when using the knob.  Couldn't reuse the long list acceleration algorithm -- tried it with completely unsatisfactory results.  

In this algorithm, scroll speed is simply proportional to knob speed.  This works very well.

Affeded file is only Bar.pm.

Need somebody to fix Settings.pm so that knob accelerations parameters can reach Bar.pm::changePos.

same question as before.  what params?   remember, Im working in the dard here.  I dont get checkin emails so i'm left with manually checking svn logs and reverse engineering (both of which suck even when you are paid and do have time).

as far as I can see, the new code in Input.Bar is a client accessor, so it's alreay there. I can't gt any idea of if it's working as I know not what is supposed to work and what's supposed to be not yet working. volume seems to move faster, but still very flakey.  so are the settings. offhand, i'd say they are about the same.  hence, code already seems to be working.


-k

Sorry to be unclear. It all makes sense in my head when I'm writing the comment :-)

There is a value $knobAccelerationConstant on line 337 of Bar.pm (r22121).  Currently this is set to 0.1, for all Bar inputs, regardless of whether the knob is spinning up or down.  

This needs to get set to different values for each Bar.pm input type, like Volume, Bass, Treble, etc, *and* to different values for Up and Down.  Bass/Treble should be symmetric, but volume should accelerate faster down than up.

So, my question is, when we instantiate a Volume, or Bass, or whatever Bar.pm controller, how do we pass these acceleration values down so that Bar.pm can get them.  

So:  for volume, I think we want the volumeDownAccelConstant = 0.1 and the volumeUpAccelConstant = 0.05.  

But for Bass/Treble, etc volumeDownAccelConstant == volumeUpAccelConstant == 0.1 or so.

These constants should be set wherever the Bar is instantiated, and I assume that's in that giant hash in Settings.pm.  

If the volume Bar is instantiated in other places, the acceleration constants need to be set there too. i.e. is the Bar that's instantiated when knocking volume up button the same instantiation as going Settings->Audio->Volume?   If not, the knobAccel constatns need to be consistant.

gotcha.  yes, I think we can add accel data to that settings hash.  volume is a bit different as it creates a dupe of Bar which is used in certain cases.

One possible method.  It feels a bit clunky since it's a pair of params for one specific device (and does nothing for the 'other' knob on Transporter), but they don't have to be used.  Is the knob accel applicable to INPUT.List or INPUT.Choice as well?  Also, we could write this another way, creating constants in ChangePos depending on "type" which is set by the caller.  Or we could even detect the type, say checking for "volume" in the header (since it saves us having to set params in each case of a volume UI.  Alarm volume for example, is a volume UI but doesn't control the current volume.  Does that also want default accel or should it have the volume accel?

===================================================================
--- C:/slim/boom/server/Slim/Buttons/Input/Bar.pm	(revision 22267)
+++ C:/slim/boom/server/Slim/Buttons/Input/Bar.pm	(working copy)
@@ -342,9 +342,9 @@
 		# be the same in both cases.
 		# 
 		if ($dir > 0) {
-			$knobAccelerationConstant = .1; # Accel going up.
+			$knobAccelerationConstant = $client->modeParam('knobaccelup') || .1; # Accel going up.
 		} else {
-			$knobAccelerationConstant = .1; # Accel going down. 
+			$knobAccelerationConstant = $client->modeParam('knobacceldown') ||.1; # Accel going down. 
 		}
 		my $velocity      = $client->knobData->{'_velocity'};
 		my $acceleration  = $client->knobData->{'_acceleration'};

change 22273 is the initial pass. feedback welcome

Dean didn't like the asymmetric volume ramp.  So, set volume speed to 0.05 on both up and down.

Thanks for the mod kdf.  Now I understand how to do it myself.

fixed in r22281
note: adding bug numbers when entering the log message also helps to verify this stuff.  the format "Bug: ####" then creates a link in viewCS to get to the relevant report (or at least it used to)