Re: [LAD] "bleeding edge html5" has interesting Audio APIs

From: Nick Copeland <nickycopeland@email-addr-hidden>
Date: Tue Nov 22 2011 - 19:05:51 EET

> From: fons@email-addr-hidden
> To: linux-audio-dev@email-addr-hidden
> Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs
>
> On Tue, Nov 22, 2011 at 05:59:40PM +0400, Alexandre Prokoudine wrote:
> > On Tue, Nov 22, 2011 at 5:54 PM, Fons Adriaensen wrote:
> >
> > >> For darktable we examined the slider from phat and created a similar
> > >> new, more usable widget which combines a label and a slider. You can
> > >> enter precise value after a right click inside the slider area, and
> > >> you can use pretty much anything as displayed unit: %, ", dB, px...
> > >> whatever. Here is an example:
> > >
> > > Not a real solution. You now have a value that is not represented
> > > by a slider position.
> >
> > Er... WHAT???
> >
> > It absolutely IS represented.
> >
> > 1. Right click
> > 2. Enter new value
> > 3. Press Enter to confirm
> > 4. Slider updates
>
> That is assuming that the slider has infinite resolution.

Which toolkit is this? Having the graphical position of the slider/pot define its
value sounds a little broken.

> In 4. the slider will move to the nearest (pixel) position.
> You could paint it with higher resolution, but mouse gestures
> are still quantised per pixel. If you move the slider 1 pixel

Touchpad interfaces support subpixel (floating point) coordinates based on an
interpolation of where somebodies fat greasy digit smudges the screen, it is
actually quite useful. HTML5 also transports pointer motion as floats for this
reason. Am an NOT advocating its use, just stating that subpixel is there.

> up and down again you don't get the value that was typed in,
> unless it happens to be one corressponding to a pixel.

Again, why does the graphical output have to define the value of the input?
Surely that is a limitation of the toolkit?

> The only solution is to ensure that slider positions correspond
> to values that make sense for the parameter being controlled,
> e.g. exact semitones (or fractions thereof) for a VCO frequency,
> 1/5 dB steps for the top half of a fader, etc. And if they do
> then you don't need the text input.

A better solution would be for the application callback to be given the actual
value and it decide what that means for whatever it is controlling and how the
graphical output should be depicted. The tail should not be wagging the dog
but again that might depend on the toolkit(?)

On a related note, Fons, weren't you actually working recently on some subpixel
controllers? How were they implemented?

Kind regards, nick.
                                               

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Nov 22 20:15:03 2011

This archive was generated by hypermail 2.1.8 : Tue Nov 22 2011 - 20:15:03 EET