[LAD] [ANN] LV2 beta3

Thomas Vecchione seablaede at gmail.com
Wed May 9 23:14:05 UTC 2007


> I don't really see the point of these "profiles" at all, to be honest.
> Seems like just defining things for the sake of defining things.

All it does is maintain an easier way of telling if a plugin will work 
for the end user.

Keep in mind I am NOT talking about the programmer here, I am referring 
strictly for the end user.  And these 'profiles' actually are nothing 
that isn't already in the spec, just put together in a different way 
that is simpler for an end user to understand.


> Either a plugin author supports these features, or not.
> Either a host author supports these features, or not.

And that is great, for the programmers.

> Either way, everything just works (or not) as it should.
> 

Not to someone not familiar with the internals of how LV2 works.  As an 
example(I hate to bring up) how many people do you think could tell you 
how the ineternals of a VST program work.  Heck how many do you think 
have an even basic idea of computer programming, much less tell you the 
above.

> I understand the idea of "plugin A doesn't work in host B" is maybe
> unnerving at first glance, but you're looking at it from a strange
> perspective and trying to come up with solutions to a problem that
> simply doesn't exist.

Actually this is just it, I understand it perfectly well.  I am the one 
stuck helping many people looking to use linux for audio that it would 
make no sense whatsoever to.

"Why can't my plugin that is LV2, that is the same thing as a AU or VST 
plugin, work in this program that is LV2 compliant?"

Again for a programmer and specifically someone familiar with how LV2 
works, that is fine.  For someone that has no concept of programming, 
and just want something that works when(To them) it is supposed to, this 
is a huge screwup that can be fixed relatively easily to be honest.

> Host H is a command line app, and doesn't support GUIs.
> Plugin P is a plugin with an optional GUI.
> Plugin G is a plugin with a mandatory GUI (silly example, yes).
> 
> P works in H, P's GUI doesn't.
> G doesn't work in H.
> 
> Of course GUIs don't work in H - it doesn't support GUIs!  There is no
> problem here...
> 

Until you get someone that has no clue in programming say...

Hey this had a GUI in this application, why doesn't it here?

And you try to explain that it is because this implementation doesn't 
support GUIs, and they take that to mean the programming is broken 
because it doesn't work for them.

Once again, this is not about me I am mentioning this.  This is for the 
half dozen people(As of right now, obviously not counting those that I 
have gotten used to linux and how things work that might start again) 
that still come to me wondering why something doesn't 'just work'.

       Seablade



More information about the Linux-audio-dev mailing list