<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'>
This is sent with apologies to Fons who now has about 50,000 copies of the<br>same submit grace of hotmail (great web interface).<br><br>> From: fons@linuxaudio.org<br>> To: nickycopeland@hotmail.com<br>> Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs<br>> <br>> On Tue, Nov 22, 2011 at 06:05:51PM +0100, Nick Copeland wrote:<br>> <br>> > Which toolkit is this? Having the graphical position of the slider/pot define its<br>> > value sounds a little broken.<br>> <br>> ?? I must be missing something essential...<br>> <br>> For example, you have a slider that is 100 pixels long, it has<br>> 101 possible positions, each one of those corresponds to some<br>> parameter value which is recomputed whenever you move the slider. <br>> <br>> Other approaches are possible, but this is AFAIK what most<br>> toolkit sliders do. So the graphical state determines the<br>> parameter value...<br><pre>> Igor sanin wrote:<br>> I may be missing something here. The purpose of a slider is to set a<br>> value. The position of the slider is a graphical representation of<br>> that value.<br></pre>So let's talk about the tail wagging the dog.<br><br>An application needs input and output, toolkits are used for all of this for lots<br>of reasons such portability, segregation of duties, whatever. The toolkit needs to<br>provide input to the app, the app needs to generate the output.<br><br>Input to an app are the cursor motion, keystrokes, on this list there is also MIDI<br>and similar control channels.<br><br>Is audio the only output? I kind of disagree that the output is only audio since<br>we are looking at whatever we are working with as much as we are listening to it.<br>The graphical output is as important as the audio output, you might disagree but<br>at least you can say that minimally these are both outputs rather than inputs - they <br>are what you see and what you hear from the application.<br><br>Input to the application should be values that are extracted from the pointer <br>positions in relation to what they are controlling. They are inputs, they have nothing<br>to do with slider positions on the screen just as they have nothing to do with the <br>actual generation of the sound, they are floating point numbers from the user interface <br>into the program.<br><br>The program/application uses these numbers to change audible output since some<br>control value has changed, they should also define the graphical output since, let's<br>be honest: the graphical display is output, not input.<br><br>If you are using a toolkit that has a data flow of the following:<br><br> pointer motion->graphical display->values->application->output<br><br>Well, basically that is broken as you have a flow that is<br><br> input->output->input->application->output<br><br>invariably that is going to lead to issues. The tail (the toolkit) is wagging the dog <br>(the application) as it imposes restrictions on the values the application is allowed<br>to see.<br><br>In my opinion (ok, it is only opinion) is that the correct flow is <br><br> input->application->output<br><br>It is irrelevant whether the output we are discussing is graphical or audible. The <br>API/library/toolkit should give values to the application, the application should <br>decide how these values need to be processed in the audio DSP and also how the <br>toolkit should represent them to the visible user interface. Remember, the toolkit <br>has no inclination of what it is being used for so why should it define what values it<br>passes to its owner?<br><br>> Then when you numerically enter a value, the slider will<br>> move to the nearest position. But in most cases that won't<br>> correspond to the value you entered, but to something near.<br>> So as soon as you move the slider, you're back to one of<br>> its 101 possible values, and you can't return to the typed-in<br>> one except by typing it again.<br><br>With this model, when you enter a value that value will be given to your application<br>and it can use it as it sees fit to generate sound: it uses the value to tell the DSP <br>code what it has to generate. It should also use similar processes to tell the other<br>output channel, the graphical one, what is should display to represent that value<br>in the graphical interface. The graphical output should not define the input values <br>to the application.<br><br>Just as the audio is output, so are the graphics. Your slider might go from 0 to 101,<br>or if the GUI is resized them from 0 to 201. The input channel has the responsibility <br>to normalise that back to 0.0 to 1.0 and give it to the application. There is no reason<br>that the toolkit be based on pixels, if it is then it is broken as it does not have any <br>abstraction that makes it generally useful.<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>> Are you referring to the case where the application needs less resolution<br>> than the widget provides ? I that case it can compute its nearest preferred<br>> value and make the widget display that (as soon as the user releases the<br>> widget).<br><br>I was referring to the application always being given a float of the value of the <br>control - 0.0 to 1.0 representing zero to full throw. The application decides how <br>this should be used, if it is continuous so be it. If it is a stepped control (semitone<br>tuning) then the application should send the stepped value to the audio engine<br>and request the graphical engine depict a 'step' in its display - the graphical <br>output now has steps just as the audio output does. If there is any quantisation<br>that has to be done then let the application control that, not the toolkit. The app<br>is not responsible for what gets drawn but it does give directives about what it<br>wants to have displayed that reflect the parameter being represented.<br><br>Back in the '90s I was writing a mixing desk emulator call S-Lab which had direct<br>to disk sampling and some basic (cheesy) editing. It used a graphics toolkit. <br>Somewhere around 2001/2002 I started working on what become bristol, a set of<br>synths for this Lab but the limitations of the toolkit became an issue, the code I<br>wanted had to bend over backwards to get the desired output - the graphics were<br>grisly.<br><br>So I dumped the toolkit and wrote my own that was based on a input-app-output<br>paradigm that left the application in control of what is wants to do. This is how <br>brighton works, it's a holistic approach, the user interface becomes as much what<br>they see as what they hear - the different output channels.<br><br>I really do not see why a toolkit should define how it is used and hearing people talk<br>about pixel boundary limitations makes me cringe.<br><br><pre>> Igor sanin wrote<br>> On a related note, the probability that a potentiometer can be set to exactly the same <br>> resistance twice is close to zero. This does not make potentiometers less prevalent in <br>> musical applications.<br></pre>Yeah, I like that. All the small discrepancies are a large part of why analogue was/is so nice.<br><br>> > On a related note, Fons, weren't you actually working recently on some subpixel <br>> > controllers? How were they implemented?<br>> <br>> Yes, I did a mixer gain fader that has subpixel resolution, not only the value<br>> but also the graphical state itself. Nothing special. If you create the 'knob'<br>> pictures using e.g. cairo (pycairo in this case), it's easy to make it move by<br>> a fraction of a pixel. <br>> <br>> But I also found that for a 250 pixel long gain fader it's just overkill.<br>> The one I use has exact 0.25 dB steps over the upper part of its range. Below<br>> that the steps size increases, and you get values that are not k * 0.25 dB,<br>> but below -30 dB or so that doesn't matter much.<br><br>What about 25 pixel long faders? Don't fanning controls give you back the resolution<br>you need here? I think I must be missing something in the pixel level controls with<br>respect to how the toolkits work, the issue is that I have not used anybody else'<br>graphical toolkit for over 10 years now.<br><br>"we have to make sure the old choice [Windows] doesn't disappear”.<br>Jim Wong, president of IT products, Acer<br><br><br><div><hr id="stopSpelling">From: nickycopeland@hotmail.com<br>To: fons@linuxaudio.org; linux-audio-dev@lists.linuxaudio.org<br>Date: Tue, 22 Nov 2011 18:05:51 +0100<br>Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
<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>
<br>_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev</div> </div></body>
</html>