[LAD] Portable user interfaces for LV2 plugins

Stefano D'Angelo zanga.mail at gmail.com
Wed Mar 2 19:55:30 UTC 2011

2011/3/2 David Robillard <d at drobilla.net>:
> On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
>> On 03/02/2011 06:32 PM, David Robillard wrote:
>> > Why you are trying to pick apart web UIs in the same email as you're
>> > arguing where one size does not fit all I don't know... I want a remote
>> > control that works on any device out of the box. It's about as blatantly
>> > obvious as anything can be that web is literally the only way to go for
>> > that, because the browser is actually on those devices. QED.
>> >
>> > Do I think /all/ desktop PC hosts and plugin should use it? No. It's for
>> > "remote control" things (even if not remote). Is GL good? Yes. I sure
>> > wish I used it for the Ingen canvas. Has anyone actually showed up yet
>> > who wanted to write a GL UI? No. Unless you're one, talking about it is
>> > a waste of time.
>> My Android audio application is GL based. Right now I see things from a host
>> developer, and am wondering how third-party plugin UIs could integrate into my
>> app. Plugin support is in my plans. Of course I will generate the UIs by myself
>> from the ports data, but I think that specific well-design UIs could be nice in
>> some cases.
>> It seems to me like we are talking about different things. You give a lot of
>> importance to remote control, why my concern is "$subject on native hosts". And
>> you seem to agree that a Web UI is not necessarily adapted for a PC host.
> Yep.
>> Right now, all my plans for audio software on mobile platforms involve GL and
>> highly interactive interface. If there was a way to create plugin UIs which are
>> portable on both desktops and mobile systems, then it could result in plenty of
>> attractive plugins arriving on Android and others. But this is only important
>> for fancy UIs. The UI can be generated from ports and groups in other cases as
>> Paul mentioned. I don't need no HTML stuff for that.
> I would much rather all the UIs be based on GL than a bunch of different
> toolkits, but toolkits solve all the problems required (e.g. input), and
> GL solves a tiny part of it, and people in this community know the
> toolkits. So here we are.
>> Also, I am mainly brainstorming and sharing some of the knowledge I acquired
>> while doing mobile development. I don't think that I can really help with the
>> long-term design choices that you need to make in the context of LV2. But I hope
>> that sharing my point of view shred a little light :)
> UI types aren't pressing decisions (a point that this list in general
> loves to miss lately...). The UI extension is toolkit agnostic for this
> reason. Maybe some day someone will make GL plugin UIs. Maybe not.
> Whatever.

No no and no, this won't be settled down this easy. :-)

I want to try to make sense of the whole issue from the start.

What is a plugin UI? UI = user interface, the thing that lets the user
interface with the plugin, i.e. control the plugin. Not necessarily a
GUI, but let's talk about GUIs.

Plugins expose "control ports" (which, to me, are a design mistake how
they're done, but whatever) for the purpose of managing how they work.
They basically represent parameters that the algorithm uses to do the
sound processing (fx or synthesis). (Let's forget control out for a

Since it's stuff for the user, they should be effective and
understandable for the user. And here's the first problem: parameters
and GUIs don't necessarily have to match! E.g., my amp simulator
algorithm should really expose stuff like "air impedance" or "triode's
magnetic perveance", that's stuff the "average user" ("dumb" guitar
player) doesn't understand. I would prefer to show "air temperature"
and "triode model" instead.

As things are currently done in the LV2 world, it seems common
thinking that this does not belong to the GUI, but I disagree. The
mapping from GUI parameters to algorithm parameters, I think, is
better done in the GUI. If I am right, the GUI is not purely
descriptive, but does also involve some calculation (whether that is
done in Javascript or C, it doesn't really matter, however).

The good thing about LV2 is that you can have multiple GUIs for a
single plugin, so I can show a scientific GUI to a scientist, another
for audio engineers and yet another for guitar players (or even have
all of them in one single GUI), and all of them map to the same

Perhaps there is the possibility to have explicit mappings in form of
RDF data with embedded math expressions or similar, so that you could
choose your mapping and still have auto-generated GUIs if you have
none that suits your needs.

There are cases, however, in which a "rich GUI" does really help
(e.g., spatialization)... but this is still about inputs to the

What I don't really get is why you would ever want visualization,
since that is more related to sound analysis, that LV2, as of now,
doesn't really support (yes, you can do whatever you want, but don't
tell me about spectrograms... that stuff is better suited to Vamp and
the like as of now - this may change, hopefully, however).

Let's start with this, and see what comes out...


More information about the Linux-audio-dev mailing list