[LAD] sliders/fans

[Nick Copeland]

> From: d at drobilla.net
> To: nickycopeland at hotmail.com
> That said, some laptops don't have middle buttons...

Pretty sure they can all emulate with dual button click.

> > > 
> > > 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 are some implementation issues here though which might mean the
pragmatic approach is to not specify the actual stepped values as long as
the model is adhered to.

For example, bristol goes from 0.0 to 1.0 and the graphic is just a visible
representation of the value. Other libraries might work with pixel steps
so isn't there an issue where the whole issue of what acceleration given 
by 'Shift' becomes a little subjective? I suggested we might advise on what
the step should be but that might be incorrect. If the interface definition
just suggests that accelerated motion is given by ''<Some_Key><Arrow_Up>"
then an implementation can confirm just by given the acceleration, the 
actual values depend on the app?

> 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.

Perhaps I need to have a look at the HID documents you were referring
to, the next step is probably to make some proposals and see how many 
people agree/object to the suggestions?

Regards, nick.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20111124/bf4d63f3/attachment.html>