<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: fons@linuxaudio.org<br><div>> To: linux-audio-dev@lists.linuxaudio.org<br>> Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs<br>> <br>> On Tue, Nov 22, 2011 at 05:59:40PM +0400, Alexandre Prokoudine wrote:<br>> > On Tue, Nov 22, 2011 at 5:54 PM, Fons Adriaensen wrote:<br>> > <br>> > >> For darktable we examined the slider from phat and created a similar<br>> > >> new, more usable widget which combines a label and a slider. You can<br>> > >> enter precise value after a right click inside the slider area, and<br>> > >> you can use pretty much anything as displayed unit: %, ", dB, px...<br>> > >> whatever. Here is an example:<br>> > ><br>> > > Not a real solution. You now have a value that is not represented<br>> > > by a slider position.<br>> > <br>> > Er... WHAT???<br>> > <br>> > It absolutely IS represented.<br>> > <br>> > 1. Right click<br>> > 2. Enter new value<br>> > 3. Press Enter to confirm<br>> > 4. Slider updates<br>> <br>> That is assuming that the slider has infinite resolution.<br><br>Which toolkit is this? Having the graphical position of the slider/pot define its<br>value sounds a little broken.<br><br>> In 4. the slider will move to the nearest (pixel) position.<br>> You could paint it with higher resolution, but mouse gestures<br>> are still quantised per pixel. If you move the slider 1 pixel<br><br>Touchpad interfaces support subpixel (floating point) coordinates based on an<br>interpolation of where somebodies fat greasy digit smudges the screen, it is <br>actually quite useful. HTML5 also transports pointer motion as floats for this<br>reason. Am an NOT advocating its use, just stating that subpixel is there.<br><br>> up and down again you don't get the value that was typed in,<br>> unless it happens to be one corressponding to a pixel.<br><br>Again, why does the graphical output have to define the value of the input?<br>Surely that is a limitation of the toolkit?<br><br>> The only solution is to ensure that slider positions correspond<br>> to values that make sense for the parameter being controlled,<br>> e.g. exact semitones (or fractions thereof) for a VCO frequency,<br>> 1/5 dB steps for the top half of a fader, etc. And if they do<br>> then you don't need the text input.<br><br>A better solution would be for the application callback to be given the actual<br>value and it decide what that means for whatever it is controlling and how the <br>graphical output should be depicted. The tail should not be wagging the dog<br>but again that might depend on the toolkit(?)<br><br>On a related note, Fons, weren't you actually working recently on some subpixel <br>controllers? How were they implemented?<br><br>Kind regards, nick.<br></div> </div></body>
</html>