2 Mar
2011
2 Mar
'11
8:55 p.m.
2011/3/2 David Robillard <d(a)drobilla.net>et>:
On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi
wrote:
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
while)
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
algorithm.
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
algorithm.
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...
Stefano
On 03/02/2011 06:32 PM, David Robillard wrote:
Yep.
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. 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.