Re: [LAD] Portable user interfaces for LV2 plugins

From: David Robillard <d@email-addr-hidden>
Date: Tue Mar 01 2011 - 17:45:15 EET

On Tue, 2011-03-01 at 14:13 +0100, Stefano D'Angelo wrote:
> 2011/3/1 David Robillard <d@email-addr-hidden>:
> > 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Mar 1 20:15:02 2011

This archive was generated by hypermail 2.1.8 : Tue Mar 01 2011 - 20:15:02 EET