From: d(a)drobilla.net
To: nickycopeland(a)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.
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?
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.
Regards, nick.