[LAD] sliders/fans

[David Robillard]

On Thu, 2011-11-24 at 20:02 +0100, Nick Copeland wrote:
> > From: d at drobilla.net
> > To: nickycopeland at hotmail.com
> > > That is a good idea. The recent comments on the use of Shift vs
> > > Control
> > > and controller changes does highlight some differences. Bristol uses
> > > Shift for accelerator (as in shift your butt) and Control as a
> > > decelerator
> > > to have more control of what is being changed but that was an pretty
> > > arbitrary choice I made a while ago.
> > 
> > Makes sense. We also need a "don't move, but hard set to this point I
> > am clicking", but middle click is convention for that so it doesn't need
> > a modifier. We do need an "I want to type in a value", though...
> 
> Hm, we need to review how many apps have hijacked Middle_Mouse for
> controller registration. I thought Ardour had done this, bristol has: if you
> click middle mouse then I register the next MIDI CC so the control tracks
> that CC. I think Ardour might use (used to use?) Control-Middle_Mouse
> for this purpose. No objection to either approach if 'enter a value' is 
> the target here for Middle_Mouse on its own.

Middle click to "go here" is a convention from scroll bars dating back
to the dawn of X11.  Using something easily done accidentally (and
unknowingly) for learn doesn't seem like the best idea to me.

That said, some laptops don't have middle buttons...

> > > Which ever seem reasonable/practicable to the group here might also
> > > want to consider the kind of values that Shift/Control might have? Am 
> > > not advocating any preference, just giving examples: bristol/brighton
> > > use Shift to go from min to max in 16 steps - ie, reasonably quickly.
> > > Control does the same motion in 256 (I might have actually changed
> > > that a while ago). Up/Down on their own increment by 1/16384th, that 
> > > is my best resolution due to using an extraction of MIDI 7bit, dual
> > > digit 
> > > encoding for the transfer syntax. The behavious is pretty anomalous or
> > > arbitrary, that is admitted. 
> > 
> > This would have to be defined in relation to the underlying unit the
> > controller is for, to address the quantisation issues Fons has
> > mentioned, or at least worded in a more generic way.
> 
> Personally I don't think the underlying unit should define the steps with 
> Control/Shift: I viewed them as going min to max in a given number of
> keypress/repeats irrespective of the quantisation. If it is not done as a 
> fraction of the full throw of a control then it might just end up as being
> another arbitrary set of definitions?

I see.  Yes, that's probably fine.  I was wrong about units/quantisation
here (see below).

There's also the acceleration/slow factors for mouse control, which
can't be defined this way.

> > > Most of the keyboard accelerators I use are based on U/D/L/R Arrow
> > > and H/J/K/L 'vi' style controls. 
> > > 
> > > I have no objection to changing them especially if it is a generally
> > > agreed
> > > set of changes and a coherent proposal.
> > 
> > A good attitude to have :)
> > 
> > > There are diverse other issues that might need to be considered such
> > > as
> > > how to handle lin vs log controls?
> > 
> 
> Glad you said that. I prefer the GUI to have equal steps. The backend 
> needs to decide if they have to be lin/log.

Agreed.  Everything here is about the *view*.  How that maps to actual
parameter values is an underlying model issue.

The view is is inherently always in pixels, which are inherently never
quantized to whatever unit you want.  It mustn't be confused with the
underlying model, which is where things like unit quantization and
linear/log mapping happen.

-dr