linuxaudio.org

--_a120acb0-e3de-4aaf-8f9c-9c228ef54ff1_

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable
> From: d@drobilla.net

quoted text
> Just a thought=2C but perhaps an effort at a LAD HIG (Human Interface

> Guidelines) might be a good idea=2C so things like this aren't arbitraril=

y

quoted text
> different between apps and plugins?

>=20

> Naturally the scope of such a thing would be limited since different

> programs have different needs=2C but at least things like twiddling

> parameters could easily be standardized.

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.
Which ever seem reasonable/practicable to the group here might also

want to consider the kind of values that Shift/Control might have? Am=20

not advocating any preference=2C just giving examples: bristol/brighton

use Shift to go from min to max in 16 steps - ie=2C 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=2C that=20

is my best resolution due to using an extraction of MIDI 7bit=2C dual digit=

=20

encoding for the transfer syntax. The behavious is pretty anomalous or

arbitrary=2C that is admitted.=20
Most of the keyboard accelerators I use are based on U/D/L/R Arrow

and H/J/K/L 'vi' style controls.=20
I have no objection to changing them especially if it is a generally agreed

set of changes and a coherent proposal.
There are diverse other issues that might need to be considered such as

how to handle lin vs log controls?
Kind regards=2C nick

 		 	   		  =
--_a120acb0-e3de-4aaf-8f9c-9c228ef54ff1_

Content-Type: text/html; charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable
&gt=3B From: d@drobilla.net&gt=3B Just a thought=2C but perhaps an=

 effort at a LAD HIG (Human Interface&gt=3B Guidelines) might be a good=

 idea=2C so things like this aren't arbitrarily&gt=3B different between=

 apps and plugins?&gt=3B &gt=3B Naturally the scope of such a thing=

 would be limited since different&gt=3B programs have different needs=

=2C but at least things like twiddling&gt=3B parameters could easily be=

 standardized.That is a good idea. The recent comments on the use o=

f Shift vs Controland controller changes does highlight some difference=

s. Bristol usesShift for accelerator (as in shift your butt) and Contro=

l as a deceleratorto have more control of what is being changed but tha=

t was an prettyarbitrary choice I made a while ago.Which ever s=

eem reasonable/practicable to the group here might alsowant to consider=

 the kind of values that Shift/Control might have? Am not advocating an=

y preference=2C just giving examples: bristol/brightonuse Shift to go f=

rom min to max in 16 steps - ie=2C reasonably quickly.Control does the =

same motion in 256 (I might have actually changedthat a while ago). Up/=

Down on their own increment by 1/16384th=2C that is my best resolution =

due to using an extraction of MIDI 7bit=2C dual digit encoding for the =

transfer syntax. The behavious is pretty anomalous orarbitrary=2C that =

is admitted. Most of the keyboard accelerators I use are based on U=

/D/L/R Arrowand H/J/K/L 'vi' style controls. I have no objectio=

n to changing them especially if it is a generally agreedset of changes=

 and a coherent proposal.There are diverse other issues that might =

need to be considered such ashow to handle lin vs log controls?=

Kind regards=2C nick

=
--_a120acb0-e3de-4aaf-8f9c-9c228ef54ff1_--