linuxaudio.org

2011/3/2 David Robillard :

quoted text
> 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

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

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev