On 03/01/2011 12:58 AM, David Robillard wrote:
>> Actually, on current mobile platforms, when one wants a portable UI, there is an
Hmm, what platform specific native code? In my idea, the host would handle
setting up the GL viewport and such. 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..
> Do I think GL is the thing to use _if you want to, and can deploy,
I'm confused now. You are talking about UIs automatically built by the host from
the plugin parameters, ports, metadata, etc.. To me, this is not a plugin UI,
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.
This sounds like abstract maths to me ;) Sorry, I can't follow you, it's not my
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.
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.
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.
Linux-audio-dev mailing list