I'm no gamer but even I know games can be have been written in java. Minecraft springs to mind. A very interesting 3d block game. James Sent using BlackBerry® from Orange -----Original Message----- From: David Robillard <d(a)drobilla.net> Sender: linux-audio-dev-bounces(a)lists.linuxaudio.org Date: Mon, 21 Nov 2011 13:40:36 To: Neil C Smith<neil(a)neilcsmith.net> Cc: <linux-audio-dev(a)lists.linuxaudio.org> Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs On Mon, 2011-11-21 at 10:36 +0000, Neil C Smith wrote: Once Java actually makes it possible to write hard realtime safe code, then maybe I'll actually consider it an appropriate option for audio engines. Notice how every single popular audio application, free and mainstream, is conspicuously *not* written in Java? There's a reason for that. Even games aren't, and they don't have the strict hard-realtime requirements we do. There's a reason for that too. You can call it "FUD" or "general anti-Java diatribe" or whatever if you like, but I have better things to do than argue against reality. -dr _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

Yes, and those sample accurate synchronised loops.And that realtime UI response: build something now and know that even dalvik will have responded to it by nightfall. I think somebody already suggested this thread be moved to another list. There is no language nor transport that suits all solutions, expecting Java and a Browser to be an ultimate panacea is being hopeful at best. Regards, nick.

I think I missed the point so this response might also miss the mark. This has nothing to do with blue skies. Green grass is also everywhere but not being a cow means I will probably get serious gut ache if I eat it. Liking/disliking Java or browsers does not really bear on their applicability to any given problem. Does one size now fit simply because everybody has some kind of browser? Availability has nothing to do with applicability to a solution. That is also a bit of a longshot. Web content is as volatile as any programing language, now its java applets, javascript, or html4, or html5, or flash. Hoping that it works in your browser is just pushing a lot of effort back onto the developer. This mish-mash of languages just about seems to work for the web because the websites want to get exposure to everybody so it is totally in their interest to work in all the different browser configurations (including text based ones for example). It might not work so well for applications that are not after universal exposure or that want to be used for what they are - applications and not web pages. What I am trying to say is that just because every system has a hammer does not mean you have to support nails. Screws will still always have a use but people may just have to get a driver from somewhere to use them. Nick.

Hey guys! I have worked several years as a web developer and continue to create personal projects actively. What can I say - the web obviously has lots to offer. However, the client-side has more promises than actual accomplishments, especially when it comes to cross-browser things. Want it or not, even jQuery has problems, especially on (you guessed it) IE. The amount of hacks one needs to put it to make even normal html look the same in FF and IE is enormous. Experienced html guys might not notice how much hacks they automatically put into the code. Not to mention the memory problem. Browsers simply cannot handle as much memory as a desktop app can and you never know if settings of the visitor of your web app will allow him to not have his browser crash. As for graphics, each solution available today has loads of issues and nothing I've seen is satisfactory. Google stuff is interesting, but how lasting it will be - nobody knows. I would agree that the web has potential. I would agree that Java failed as a dream of an ultimate platform for all. But I would not agree that the web is there already today, nor that it is close. In terms of actual interaction it is very, very far away from what even a Java tool like Processing can offer, not to mention all of Java. -- Louigi Verona http://www.louigiverona.ru/

Ah, is that all we need? I never realised it was so simple. Can I have them in some dull, boring grey colour with sad square boxes? You know, something that really inspires and that will convince every iPad user that their ubercool GUI are a total waste of time. Can you do that for me? That would be a killer! Regards, cnik

On Mon, 2011-11-21 at 22:57 +0000, Fons Adriaensen wrote: For stuff like this you need a way to enter precise values with a corresponding text box anyway. Though the old fan slider idea was a pretty good one... -dr

On Mon, 2011-11-21 at 23:59 +0000, James Morris wrote: Yeah, I think it was always sort of a given that this would never work ideally without compositing, unfortunately. I assume transparent window hacks don't work out so well? It's a shame really, it's IMO by far the best controller idea I've seen - knobs on a mouse-driven computer screen are, have always been, and will always be, completely inappropriate... I wonder how useful it would be with the limitation of keeping it confined to one window would be... with Gtk3, the entire app draws to a single Cairo context so I believe it should be straightforward to draw a big fan or whatever across the entire window... I should probably implement this idea in FlowCanvas for (at least) Ingen. It should be doable there, confined to the canvas of course, but since it's scrollable it should be possible to make that usable by automatically scrolling as needed (the usual thing with dragging stuff in a scrollable widget). Cheers, -dr

On Tue, 22 Nov 2011 15:33:16 +0400 Alexandre Prokoudine <alexandre.prokoudine(a)gmail.com> wrote: That looks interesting. I take it you removed the fan drawing code? What about imprecise but fine grained adjustments? If not, would adding a modifier such as [shift] for finer grained movement of the slider be considered? It probably would be unimportant for darktable, but in an audio application where adjustmented has immediate affect on the audio stream it would certainly be useful. (It was a feature requested during discussion on petri-foo-devel about the phat fan sliders and the problems with converting them to cairo). James.

Am Dienstag, den 22.11.2011, 09:25 -0500 schrieb Paul Davis: guitarix controllers (libgxw/libgxwmm/pygxw/glade-gxw) do all of that also, just they use control shift as modifier for fine tune but right click for enter a numeric value.

That is a good idea. The recent comments on the use of Shift vs Control and controller changes does highlight some differences. Bristol uses Shift for accelerator (as in shift your butt) and Control as a decelerator to have more control of what is being changed but that was an pretty arbitrary choice I made a while ago. Which ever seem reasonable/practicable to the group here might also want to consider the kind of values that Shift/Control might have? Am not advocating any preference, just giving examples: bristol/brighton use Shift to go from min to max in 16 steps - ie, reasonably quickly. Control does the same motion in 256 (I might have actually changed that a while ago). Up/Down on their own increment by 1/16384th, that is my best resolution due to using an extraction of MIDI 7bit, dual digit encoding for the transfer syntax. The behavious is pretty anomalous or arbitrary, that is admitted. Most of the keyboard accelerators I use are based on U/D/L/R Arrow and H/J/K/L 'vi' style controls. I have no objection to changing them especially if it is a generally agreed set of changes and a coherent proposal. There are diverse other issues that might need to be considered such as how to handle lin vs log controls? Kind regards, nick

Hm, we need to review how many apps have hijacked Middle_Mouse for controller registration. I thought Ardour had done this, bristol has: if you click middle mouse then I register the next MIDI CC so the control tracks that CC. I think Ardour might use (used to use?) Control-Middle_Mouse for this purpose. No objection to either approach if 'enter a value' is the target here for Middle_Mouse on its own. Personally I don't think the underlying unit should define the steps with Control/Shift: I viewed them as going min to max in a given number of keypress/repeats irrespective of the quantisation. If it is not done as a fraction of the full throw of a control then it might just end up as being another arbitrary set of definitions? Glad you said that. I prefer the GUI to have equal steps. The backend needs to decide if they have to be lin/log. Regards, nick.

Pretty sure they can all emulate with dual button click. There are some implementation issues here though which might mean the pragmatic approach is to not specify the actual stepped values as long as the model is adhered to. For example, bristol goes from 0.0 to 1.0 and the graphic is just a visible representation of the value. Other libraries might work with pixel steps so isn't there an issue where the whole issue of what acceleration given by 'Shift' becomes a little subjective? I suggested we might advise on what the step should be but that might be incorrect. If the interface definition just suggests that accelerated motion is given by ''<Some_Key><Arrow_Up>" then an implementation can confirm just by given the acceleration, the actual values depend on the app? Perhaps I need to have a look at the HID documents you were referring to, the next step is probably to make some proposals and see how many people agree/object to the suggestions? Regards, nick.

So there are a few options for middle mouse: a. it does not exist since we have 2 button mouse b. it does, or is emulated and implies 'jump to here' c. it does, or is emulated and implies 'post pop-up to request value' d. it does, or is emulated and implies 'MIDI CC Register' That probably needs to be voted on to see what is generally implemented. It might also make sense to post on LAU and see what people generally anticipate, as ever there can be disconnects between users and developers. Out of interest, how many apps respect mouse buttons 4 and buttons 5 for scroll up/down? This is the middle-mouse-wheel, it should at least be part of the proposal, then perhaps also with 'Control', and 'Shift'?

Excerpts from hermann's message of 2011-11-24 21:31:22 +0100: Plug in an external interface (like basically everyone does) and it has a midi connection. Also, jack doesn't need a midi hardware device to be useful. I'd worry about left/right buttons first, find agreement on basic stuff, worry about the leftovers later. Yes, I'm also very much pro a convention. I don't see any real solution to the problem that different human interface guidelines create in general, and it's a real mess on linux or when you want to go cross platform, but a convention for Linux Audio sure wouldn't hurt.

Am Donnerstag, den 24.11.2011, 18:57 -0500 schrieb David Robillard: I didn't know, never use nor have a Macbook, but I'd like to turn the question into : can't you connect a mouse with middle button to a MacBook, same as you can do with any laptop without middle mouse button? Then you could make your midi connections ones, they will be stored, and you didn't need to take the mouse with you, but can use the midi device for controlling. I guess the only thing witch is common right now, is that the left click will grep the controller and make it follow the mouse. But, as a first step, we could possible find a agreement about witch controller key will introduce the "fine settings mode", as far I see we have "control" or "shift". I will be cool if we could get a agreement witch one is to use. Then, if we found a agreement, we could make the next step and talk about right/middle click. I guess we cant manage all in one run. regards hermann

On Fri, 2011-11-25 at 05:06 +0100, hermann wrote: [...] Random thought arrived at while working on the successor to FlowCanavs: How about using the axis inline with the slider for coarse control, and the other axis for fine control? For example, a horizontal fader would use horizontal drag as a "direct grab" as usual, but the vertical distance would be used as a fine control. This saves a modifier, and is more discoverable for it (users are pretty likely to figure this out by mistake), as well as accurately usable with one hand. Could be applied to touch screens, as well. -dr

How easy is that to use in practice though? With a mouse, and particularly with a touch screen, it's not that easy to do a purely vertical movement without introducing lots of horizontal "noise" that will surely hamper your attempts at fine settings?! Neil On 7 December 2011 19:32, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net

On Wed, 2011-12-07 at 14:43 -0500, Paul Davis wrote: Hm... so my description wasn't quite what you'd want. It's more like the distance along the minor axis controls sensitivity, and the actual value change is always along the major axis? -dr

On Wed, 2011-12-07 at 17:32 -0500, Paul Davis wrote: I am kind of torn on which is better. One is nice for being able to very precisely pivot around the current value, the other lets you do a big change precisely in one movement... -dr

On Thu, 2011-12-08 at 06:22 +0100, Nick Copeland wrote: More or less the same idea without the visuals, except here I am using the full width of the screen in all cases, even the most coarse. I think fansliders act as normal sliders when you interact directly with them. I guess my approach is more like the knob once, since my sliders are quite small. -dr

On Thu, Nov 24, 2011 at 02:21:25PM -0500, David Robillard wrote: Not always. Consider the case of 'VCA' groups for faders. That is: you have a slider that controls the gain of a group of channels (without those being mixed). The effective channel gain (in dB) is the sum of the per channel fader value and the one from the group fader. The model sees only this sum. Now a fader has to go down to zero gain (-inf dB). So you would map the lowest possible (finite) value of the widget to something that the model (the DSP code) would translate to 'off'. The question is then: is this exception handled by the widget and the DSP code, or by the DSP code only ? Suppose the minimum value of the widget would correspond to say -100 dB if not handled specially. If you just have a single fader per channel, you could arrange for the model or the DSP code to translate that to 'off'. That is no longer the case if you have 'VCA' faders. There are two thing you'd expect from such a system: * If either the channel or the group fader is at minimum, then the channel must be off (zero gain). * If the channel fader is at -50 dB, and the group at -60 dB you don't want zero gain, but -110 dB. Becaus either fader is still in a position where you'd expect that moving it makes a difference. In other words, you'd expect such a system to behave as if you had two faders in series. Now if the DSP code only sees the sum of the two values (as it should, having a VCA group is just a user interface issue), then that implies that the mapping of the minimum fader position (e.g. -100 dB) to something that would be interpreted as 'off' by the DSP code (e.g. -9999999 dB) _must be done by each individual fader_. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Thu, Nov 24, 2011 at 10:03:47PM +0100, Nick Copeland wrote: Agreed, yes. But I was replying to your suggestion that the translation of 'widget value' to 'actual parameter value' would always be the task of the model or DSP code. That is in general not the case if what the model or DSP code sees is a combination of widget values. If these don't combine in a linear way (as in my example, due to the 'off' exception) then at least part of the interpretation of the widget values must be done at the point they are combined. I'd say that if the widget can be resized or modified in any way that affects its resolution then it should not be controlling anything that depends on the availability of certain discrete values (such as e.g. oscillator frequencies in a synth). If it does, that is IMHO a design error. It's like having an elastic tape measure - it's OK for it to be elastic, but the cm or inch tick marks must remain at a fixed distance :-) Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Thu, Nov 24, 2011 at 03:12:12PM -0800, Jeff Koftinoff wrote: Not always. Consider the case of a mixer application that has full OSC remote control. The VCA fader could be an implementation detail of the remote interface, unknown to the model. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Thu, 2011-11-24 at 20:45 +0000, Fons Adriaensen wrote: This isn't an "exception" to anything, you just described some controller logic. I guess you are being pedantic and jumping on me saying it's a "model" issue. True, it's not necessarily, depending on your architecture. What I meant to say was it is definitely not a view issue. *No matter what* you have a widget which is giving you some value within some range (possibly with some undesirable quantisation). This is true even if you wrote the whole thing yourself from the ground up, it is inherently true. With that value, you do whatever it is you need to do. Some situations are indeed much more complex than others, but a widget is still just a stupid thing that gives you a number. -dr

On Fri, Nov 25, 2011 at 09:52:25AM +0100, Nick Copeland wrote: Agreed, my comment was out of scope, sorry for the noise ! Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

Are there any LAD reference docs here or is it completely greenfield? I did some searches on LAD HIG and you get some really off-topic results, good read, just off topic. If it is greenfield then any concept of semantics should be dropped and leave the basic concept of what key/button pairs should cause a controller to do. The net effect of the change is up to the app, no? Regards, nick.

On Tue, Nov 22, 2011 at 4:05 PM, James Morris wrote: Hard to remove something that was never used :) We did it from scratch. Ctrl is used for smaller steps right now. Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Nov 22, 2011 at 5:54 PM, Fons Adriaensen wrote: Er... WHAT??? It absolutely IS represented. 1. Right click 2. Enter new value 3. Press Enter to confirm 4. Slider updates Alexandre Prokoudine http://libregraphicsworld.org

Which toolkit is this? Having the graphical position of the slider/pot define its value sounds a little broken. 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. Again, why does the graphical output have to define the value of the input? Surely that is a limitation of the toolkit? 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.

This is sent with apologies to Fons who now has about 50,000 copies of the same submit grace of hotmail (great web interface). So let's talk about the tail wagging the dog. An application needs input and output, toolkits are used for all of this for lots of reasons such portability, segregation of duties, whatever. The toolkit needs to provide input to the app, the app needs to generate the output. Input to an app are the cursor motion, keystrokes, on this list there is also MIDI and similar control channels. Is audio the only output? I kind of disagree that the output is only audio since we are looking at whatever we are working with as much as we are listening to it. The graphical output is as important as the audio output, you might disagree but at least you can say that minimally these are both outputs rather than inputs - they are what you see and what you hear from the application. Input to the application should be values that are extracted from the pointer positions in relation to what they are controlling. They are inputs, they have nothing to do with slider positions on the screen just as they have nothing to do with the actual generation of the sound, they are floating point numbers from the user interface into the program. The program/application uses these numbers to change audible output since some control value has changed, they should also define the graphical output since, let's be honest: the graphical display is output, not input. If you are using a toolkit that has a data flow of the following: pointer motion->graphical display->values->application->output Well, basically that is broken as you have a flow that is input->output->input->application->output invariably that is going to lead to issues. The tail (the toolkit) is wagging the dog (the application) as it imposes restrictions on the values the application is allowed to see. In my opinion (ok, it is only opinion) is that the correct flow is input->application->output It is irrelevant whether the output we are discussing is graphical or audible. The API/library/toolkit should give values to the application, the application should decide how these values need to be processed in the audio DSP and also how the toolkit should represent them to the visible user interface. Remember, the toolkit has no inclination of what it is being used for so why should it define what values it passes to its owner? With this model, when you enter a value that value will be given to your application and it can use it as it sees fit to generate sound: it uses the value to tell the DSP code what it has to generate. It should also use similar processes to tell the other output channel, the graphical one, what is should display to represent that value in the graphical interface. The graphical output should not define the input values to the application. Just as the audio is output, so are the graphics. Your slider might go from 0 to 101, or if the GUI is resized them from 0 to 201. The input channel has the responsibility to normalise that back to 0.0 to 1.0 and give it to the application. There is no reason that the toolkit be based on pixels, if it is then it is broken as it does not have any abstraction that makes it generally useful. I was referring to the application always being given a float of the value of the control - 0.0 to 1.0 representing zero to full throw. The application decides how this should be used, if it is continuous so be it. If it is a stepped control (semitone tuning) then the application should send the stepped value to the audio engine and request the graphical engine depict a 'step' in its display - the graphical output now has steps just as the audio output does. If there is any quantisation that has to be done then let the application control that, not the toolkit. The app is not responsible for what gets drawn but it does give directives about what it wants to have displayed that reflect the parameter being represented. Back in the '90s I was writing a mixing desk emulator call S-Lab which had direct to disk sampling and some basic (cheesy) editing. It used a graphics toolkit. Somewhere around 2001/2002 I started working on what become bristol, a set of synths for this Lab but the limitations of the toolkit became an issue, the code I wanted had to bend over backwards to get the desired output - the graphics were grisly. So I dumped the toolkit and wrote my own that was based on a input-app-output paradigm that left the application in control of what is wants to do. This is how brighton works, it's a holistic approach, the user interface becomes as much what they see as what they hear - the different output channels. I really do not see why a toolkit should define how it is used and hearing people talk about pixel boundary limitations makes me cringe. Yeah, I like that. All the small discrepancies are a large part of why analogue was/is so nice. What about 25 pixel long faders? Don't fanning controls give you back the resolution you need here? I think I must be missing something in the pixel level controls with respect to how the toolkits work, the issue is that I have not used anybody else' graphical toolkit for over 10 years now. "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer From: nickycopeland(a)hotmail.com To: fons(a)linuxaudio.org; linux-audio-dev(a)lists.linuxaudio.org Date: Tue, 22 Nov 2011 18:05:51 +0100 Subject: Re: [LAD] "bleeding edge html5" has interesting Audio APIs Which toolkit is this? Having the graphical position of the slider/pot define its value sounds a little broken. 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. Again, why does the graphical output have to define the value of the input? Surely that is a limitation of the toolkit? 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(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

If you use both slider and direct entry methods, you are aware of the different behaviour. If you are aware of the different behaviour, and still use the slider, you want to change the current value. If you don't want to change the current value, don't touch the slider. If you want finer control of your parameters, there are different approaches.

On Tue, Nov 22, 2011 at 10:03 AM, Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: its hard for me to see how a single GUI controller can be the solution to that particular problem (though its clearly something worth doing). its not clear to me how any GUI controller that responds to mouse motion can be immune to this issue. indeed, this is a separate issue: essentially ensuring that there is a precise mapping of pixels to integral values of desired units (and back), rather than (as typically happens) pixels to some fractional value of desired units. e.g. I don't want to be able to tune to +2.8291 semitones, only to +1, +2, +3 and so on. and fons is right that the slide should work this way, regardless or not of whether direct numerical input is available too. of course, for plugins, its even more complex, because the plugin API has to be able to specify not only the fact that it has desired units, but also the fact that it wants only integral values of them. some plugin APIs do provide both pieces of information.

On Tuesday, November 22, 2011 11:06:43 AM Fons Adriaensen did opine: A valid point. This, IMO is operator error. That doesn't mean that an interface can't be coded up that encourages such though. :( In which case a 2nd multi-selector might be needed, to switch between a tempered scale and a non-tempered scale, in such a manner that its global and pinned to A=440. That exposes the need for a tune in "cents" button that applies globally also, to tune it to accompany for instance a pipe organ which is not being played at the same ambient temps as when the organ constructor last tuned it. It also assumes he had an adequate std reference much better than a tuning fork. Sadly, many who pass therm selves off as organ techs, don't. But that is also not Germain to this thread. This need for more buttons can be carried to extreme silliness of course but the point is at least semi valid. This is an interesting thread, made moreso by FA's injections, do carry on. Referring to the .png image previous in this thread, limiting the colors used to a greyscale personally detracts from the 'eye candy' aspect. But that is just me. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> My uncle was the town drunk -- and we lived in Chicago. -- George Gobel

On Mon, 21 Nov 2011 18:32:51 -0500 David Robillard &lt;d(a)drobilla.net&gt; wrote: See, I find stupid little grey boxes a lot less clear and usable than pixmap controls. Using the native toolkit widgets just looks shite. Audio apps that use them are totally unusable. I don't want to sit staring at a spreadsheet when I'm trying to create music. -- Gordon JC Pearce MM0YEQ &lt;gordonjcp(a)gjcp.net&gt;

Does html5 support JACK yet? That will be nice. With html5 support for opengl this is actually decent on new browsers. -- Patrick Shirkey Boost Hardware Ltd