24 Nov
2011
24 Nov
'11
9:30 p.m.
From: d(a)drobilla.net
To: nickycopeland(a)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? There's also the acceleration/slow factors for
mouse control, which
can't be defined this way.
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.
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?