<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 said, some laptops don't have middle buttons...<br><br>Pretty sure they can all emulate with dual button click.<br><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>> I see. Yes, that's probably fine. I was wrong about units/quantisation<br>> here (see below).<br><br>There are some implementation issues here though which might mean the<br>pragmatic approach is to not specify the actual stepped values as long as<br>the model is adhered to.<br><br>For example, bristol goes from 0.0 to 1.0 and the graphic is just a visible<br>representation of the value. Other libraries might work with pixel steps<br>so isn't there an issue where the whole issue of what acceleration given <br>by 'Shift' becomes a little subjective? I suggested we might advise on what<br>the step should be but that might be incorrect. If the interface definition<br>just suggests that accelerated motion is given by ''<Some_Key><Arrow_Up>"<br>then an implementation can confirm just by given the acceleration, the <br>actual values depend on the app?<br><br>> There's also the acceleration/slow factors for mouse control, which<br>> can't be defined this way.<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>> Agreed. Everything here is about the *view*. How that maps to actual<br>> parameter values is an underlying model issue.<br>> <br>> The view is is inherently always in pixels, which are inherently never<br>> quantized to whatever unit you want. It mustn't be confused with the<br>> underlying model, which is where things like unit quantization and<br>> linear/log mapping happen.<br><br>Perhaps I need to have a look at the HID documents you were referring<br>to, the next step is probably to make some proposals and see how many <br>people agree/object to the suggestions?<br><br>Regards, nick.<br></div> </div></body>
</html>