<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
> From: d@drobilla.net<br><div>> To: nickycopeland@hotmail.com<br>> > That is a good idea. The recent comments on the use of Shift vs<br>> > Control<br>> > and controller changes does highlight some differences. Bristol uses<br>> > Shift for accelerator (as in shift your butt) and Control as a<br>> > decelerator<br>> > to have more control of what is being changed but that was an pretty<br>> > arbitrary choice I made a while ago.<br>> <br>> Makes sense. We also need a "don't move, but hard set to this point I<br>> am clicking", but middle click is convention for that so it doesn't need<br>> a modifier. We do need an "I want to type in a value", though...<br><br>Hm, we need to review how many apps have hijacked Middle_Mouse for<br>controller registration. I thought Ardour had done this, bristol has: if you<br>click middle mouse then I register the next MIDI CC so the control tracks<br>that CC. I think Ardour might use (used to use?) Control-Middle_Mouse<br>for this purpose. No objection to either approach if 'enter a value' is <br>the target here for Middle_Mouse on its own.<br><br>> > Which ever seem reasonable/practicable to the group here might also<br>> > want to consider the kind of values that Shift/Control might have? Am <br>> > not advocating any preference, just giving examples: bristol/brighton<br>> > use Shift to go from min to max in 16 steps - ie, reasonably quickly.<br>> > Control does the same motion in 256 (I might have actually changed<br>> > that a while ago). Up/Down on their own increment by 1/16384th, that <br>> > is my best resolution due to using an extraction of MIDI 7bit, dual<br>> > digit <br>> > encoding for the transfer syntax. The behavious is pretty anomalous or<br>> > arbitrary, that is admitted. <br>> <br>> This would have to be defined in relation to the underlying unit the<br>> controller is for, to address the quantisation issues Fons has<br>> mentioned, or at least worded in a more generic way.<br><br>Personally I don't think the underlying unit should define the steps with <br>Control/Shift: I viewed them as going min to max in a given number of<br>keypress/repeats irrespective of the quantisation. If it is not done as a <br>fraction of the full throw of a control then it might just end up as being<br>another arbitrary set of definitions?<br><br>> > Most of the keyboard accelerators I use are based on U/D/L/R Arrow<br>> > and H/J/K/L 'vi' style controls. <br>> > <br>> > I have no objection to changing them especially if it is a generally<br>> > agreed<br>> > set of changes and a coherent proposal.<br>> <br>> A good attitude to have :)<br>> <br>> > There are diverse other issues that might need to be considered such<br>> > as<br>> > how to handle lin vs log controls?<br>> <br><br>Glad you said that. I prefer the GUI to have equal steps. The backend <br>needs to decide if they have to be lin/log.<br><br>Regards, nick.<br></div> </div></body>
</html>