linuxaudio.org

On Tue, 2011-03-01 at 14:13 +0100, Stefano D'Angelo wrote:

quoted text
> 2011/3/1 David Robillard :

> > On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:

[...]

quoted text
> >> 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.

quoted text
> >>

> >> 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,

quoted text
> 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

quoted text
> > 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

quoted text
> > 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

quoted text
> 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