On Tue, 2011-03-01 at 14:13 +0100, Stefano D'Angelo wrote: > 2011/3/1 David Robillard <d...@drobilla.net>: > > On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote: [...] > >> Also, I don't see what's so easy with browsers. I've done web development > >> for > >> years, and compatibility problems are the rule. > > > > Never said it was easy, but requiring a modern browser is still much, > > much more portable and less annoying than requiring a bunch of specific > > native code on every device. This is not a "web site" that needs to work > > in IE6 or whatever. > > If we exclude older IE releases it all gets a lot better :-)
If you exclude IE entirely it gets even better. I hear maybe the very latest release is just unawful enough that maybe you don't have to do this, but I couldn't care less. > >> > Just want the UI on the same machine? Do the same in your browser. > >> > >> I don't see why this is so crucial for plugins. > > > > This stuff is more appropriate for controllers. Faders, knobs, buttons, > > grids, loop sequencers, etc. Maybe you personally don't care to control > > audio software with a tablet (or any machine on which you can't install > > a bunch of native LAD crap) but there's no question that a lot of people > > do. > > > > Personally I don't care about high performance native UIs that draw > > waveforms or whatever, because the last thing I want to be doing (or > > anybody wants to watch) is clicking around on a damned screen when I'm > > trying to play. 99% of that stuff is worthless fancy bling intended for > > back of the box screenshots, if you ask me. Plain old lines and flat > > rectangles are not only as good - but better - for tactile UIs actually > > designed for playability/readability. > > True for live usage, not really for offline processing, recording > sessions, etc. Like I said, I am doing the web thing for controllers, for which it is awesome. > At least not in the long run. Think spatialization, > EQs, physics-related stuff, scientific usage and, somewhere in the > future, sound analysis (spectrograms, etc.), highly interactive stuff. I've no doubt there's things that the browser isn't good for. They're also usually things that involve a lot of data and you wouldn't do remotely anyway. Use a native UI. As for my personal goals, that's all a bunch of "nerd clicking and staring at a screen" crap that is specifically what I am trying to avoid entirely. > > As one example, I want to have a machine controlling the audio rig, have > > people arrive with their tablet (or whatever), go to a particular > > address and participate in the jam. This is be a pretty > > awesome/novel/unique possibility. Non-realtime audio is even a > > possibility if their device can do such things. Obviously, the only way > > of doing this is web UI. As a nice plus, when you do it that way, hey, > > you get a PC appropriate network transparent UI for free. From the > > perspective of someone who needs this anyway, some very tangible reasons > > would be needed to make rewriting the whole UI in GL as well not an epic > > waste of time. Note that most of realising this dream will be done by > > the host, only certain plugins would need special web UI fragments. The > > rest just need to provide sufficient information for the host to make > > sense of their parameters (as they need to regardless). > > /me thinks, at this point, about a possible WebUI decorator plugin > with interactive design possibilities... > > (then my mind pushes it too far: let's integrate with Firebug or something. > :-P) Your mind pushed it too far as soon as browser specific anything got involved. > > If you want to do some sort of experimental fancy 3D plugin UIs rendered > > in the same 3D universe or whatever (right now, i.e. not using webGL), > > where it is necessary for a plugin to have special UI code (i.e. the > > host can't generate it) sure, this is not the way to go. Use > > GL/Clutter/whatever. Unless you actually need the performance advantage > > of native GL, though, browser is better. > > Uhm, GL is actually embeddable in most semi-serious toolkits (even SDL > should allow that IIRC). Should we go for a GL/WebUI approach? Yep. I'm all for GL UIs. > /me: GUI decorator plugin #2 - give it a bunch of metadata (and maybe > fonts image), it will create the GUI on the fly for you. In any case where it's actually feasible for the host, or a library, to generate the UI, rather than having to write specific UI code, that's very definitely the way to do. Along those lines, I need to spread the port groups extension... you can automagically make pretty good UIs as long as you can actually group things sensibly... -dr _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev