Re: [LAD] LV2 realtime safe memory pool extension

Nedko Arnaudov wrote:

> I dont think such leveling can be defined. For example custom and generic
> GUIs are at same level. Maybe there could be feature (extension)
> sets. They may need to be defined in ttl file too.

I only mean, level 3 host must support the custom GUIs if plugin has
them - it was thought to be a kind of incentive for host makers to
implement the most crucial features in order to get bragging rights :)

There will be less hosts than plugins, so it is important that host
makers get it right in the first place. Then, users would drive plugin
authors to start making use of "high level" spec features (like, custom
GUI or MIDI ports). They would basically bitch and moan until plugin
devs start showing parameters in Hertz instead of arbitrary units, until
everything has GUIs, until parameters are handled in sample-accurate way
etc.

That was my experience from Buzz community at least. Users were pushing
devs to add more and more advanced features (and devs were pushing
oskari to add more advanced features in Buzz machine spec). Of course,
what worked there doesn't have to work in open source community. But it
might be worth trying.

> Unfortunately, I doubt test suite will happen at all. I think it will be
> more like, plugin A version "n" is known to work well in host B, vesrion
> "m".

Which is a kind of hell for end users, isn't it? :)

From user perspective, either everything should fully work everywhere
(at least to some degree), or determining compatibility should be as
simple as possible (ie. plugin says level 3 and host says level 4 - so
the plugin will work well in that host). Musicians aren't necessarily
technically-minded, and some stuff, even simple to us, may simply scare
them off, just because it *seems* complex :)

Test suite must happen at some point - I might do some work for that
too. It doesn't have to be something big, in simplest case it would just
be a set of short programs/plugins full of asserts :)

> Also testing imposes kind of certification, i.e. work that IMHO
> should be done by packager. see below...

Certification is the possible next step, but not a requirement. The test
suite is basically designed to help devs write correct code, not to
force them to do so. Encouraging them to do so is more of reputation
thing (if someone writes buggy plugins, he will be complained to on
mailing lists, irc channels, and his work won't be included in
distributions etc).

I think whether it will be open or closed source is irrelevant - the
main goal of the compliance level is a helpful, structured development
process, where:

1) compliance bugs are caught before the plugin is released, eliminating
the problem of buggy plugins in circulation (unless the developers don't
use the test suite at all, but then it's either their bad decision that
will cost them reputation or bad test suite that will cost me reputation)

2) host authors are encouraged to add features in a predictable order
(they can always add level 4 features without level 2, but then they
can't brag about level 2 compliance)

3) when - say - 100% of hosts support level 1, 50% of hosts support
level 2 and 25% of hosts support level 3, the plugin authors would first
want to make use of level 2 additions, then level 3 additions etc -
basically, concentrate on this kind of work that makes the most of end
users happy with them (as in: what's the point of doing level 4
additions when no host does level 4 - except for doing it for fun)

Of course, I'm not saying the model would always be used - just it would
be the expected case the audio scene could (hopefully) slowly converge to.

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu, 08 Nov 2007 14:24:19 +0000