On Tue, 2011-03-01 at 19:36 +0100, Olivier Guilyardi wrote:
> On 03/01/2011 12:58 AM, David Robillard wrote:
> > On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
>
> >> Actually, on current mobile platforms, when one wants a portable UI, there is an
> >> alternative to Web UIs: OpenGL. This runs everywhere, and as smoothly as can be.
> >> All you need is the plugin to expose draw() and mouse motion functions.
>
> >
> > Yep... and it's not remote, and involves writing a bunch of platform
> > specific native code. The whole point is avoiding that.
>
> Hmm, what platform specific native code? In my idea, the host would handle
> setting up the GL viewport and such.
... "the host would <platform specific native code>" ;)
Going to something in a web browser doesn't involve any of that. It
doesn't involve anything on the "thing with a UI on it" whatsoever
except "go to this URL in your web browser". i.e. no platform specific
native code (including GL) is required, at all, to operate the UI. It'd
work on a hypothetical(*) tablet you can't even install software on
whatsoever.
> The plugin would expose a draw() callback
> in which it would only perform standard OpenGL calls.
>
> I'm not an expert about GL portability, but AFAIK this might allow the UI
> provided by a plugin to run unchanged on Linux, iOS, Android, Mac, Windows, etc..
Probably, since the host deals with all the non-portable things. What
you describe here sounds like how a GL UI type should indeed work. It
would be better if there was some equivalent of a "widget" the UI could
return, but I guess that is not the case for GL.
So far, nobody has showed up with a desire to write a GL plugin UI.
Extensions don't get invented until there's an actual use for them. If
someone does, drop by lv2-devel, and we'll get this done (or don't, and
just do it).
The next SLV2 will abstract away UI types, so if/when this gets
invented, it will magically just work in existing hosts, since embedding
GL in most toolkits is possible.
> > Do I think GL is the thing to use _if you want to, and can deploy,
> > implement device specific native code for the UI_? Absolutely. Is that
> > suitable for all (or even most) cases where browser UIs shine? Nope.
> >
> > 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).
>
> I'm confused now. You are talking about UIs automatically built by the host from
> the plugin parameters, ports, metadata, etc..
Yes, partially...
> To me, this is not a plugin UI,
... except a plugin could provide such a (plugin specific) UI as well.
My "dirg" plugin provides a web-based grid UI in the browser, for
example. Currently it just does this by running its own web server, but
this needs to be pushed up to the host for obvious reasons.
> this is the absence of plugin specific UI, and the kind of thing which you can
> already do with LADSPA plugins, etc.. So, automatically generated web UIs from
> plugin metadata is of course possible, but I wasn't talking about that.
>
> I'm talking about those cases where the plugin needs to provide a specific UI,
> as it's currently being done with LV2 using GTK, for example in Calf plugins,
> etc.. But here you mention a mix of automatically generated UIs and "special web
> UI fragments" provided by the plugin.
"special web UI fragments", or, in other words, a plugin specific UI.
Yep.
> Regarding remote controllers.. Well this is already in the wild, tablets
> included, with OSC and MIDI. For example, there is TouchOSC (sorry, not free,
> but a great project) which even has a UI editor.
Same kind of realm as this stuff, yes, except the UI design is
integrated with the host and plugins, and is roughly infinity times
slicker as a result.
> I think that I understand you idea of doing this with a browser. No need to
> setup OSC, ports, map URIs, etc.. But this sounds like a web-based controller
> project. It's application level IMO, not sure it belongs to LV2, apart from the
> UI fragments idea, but this all sounds like fundamental research to me.
My LV2 host /is/ an LV2 plugin ;) Think about the implications of that
for a minute and a big lightbulb should go off (Hint: Want to make
plugins with universal UIs? Don't want to write code?)
Is it about web-based controllers on a tablet or whatever? Yes. But it
is not /only/ about that. If you have such a UI, well, it works just
fine on the PC too. One UI written, both problems solved, objectively
better solution - unless you need the performance of OpenGL. I don't
deny that sometimes you do, but personally I'm more into making music
and less into fancy screenshots and idiotic pixmaps of physical boxes or
whatever.
Hopefully its fast enough. Seems fine. Good enough for controllers and
basic/loop/pattern sequencing, maybe not for actually playing keys and
pads and whatnot.
> That said, I don't think that I can help some more here. I'm more into simple
> user needs and every day music/audio tasks.
Having remotes is obviously a good "every day music task" sort of thing.
Ditto being able to easily build UIs for plugins or collections of
plugins, remote or not. Users around here have been vocally pining for
such a thing for ages. Don't assume that just because a technology is
novel it's some abstract theoretical wank. The point here is entirely
pragmatic and user focused.
-dr
(* Or perhaps not so hypothetical if you consider the implications of
trying to put free software on an iPad)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Mar 2 04:15:02 2011
This archive was generated by hypermail 2.1.8 : Wed Mar 02 2011 - 04:15:03 EET