[LAD] LV2 realtime safe memory pool extension

[Stefano D'Angelo]

2007/11/8, Krzysztof Foltman <wdev at foltman.com>:
> 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.

Damn users ;-P

> 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.

I repeat, I have nothing to do with LV2, but I guess that's what
extensions are for: "modularize" support for new features.

> > 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? :)

Yep.

> 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 :)

Damn users again :-)

> 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 :)

Cool. That's what I'm doing too in my project, I'm using debug
mode-only assertions in all functions against input and return values
(much like design by contract).
The difference here is that LV2 is "just a specification", while my
library is an implementation, so a test suite would be actually fine.

> > 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)

True :-)

> 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)

I'm not sure... do all GUI-supporting hosts have to support rt-safe
allocation as well?
In such case they would support level 4, but not level 2 as you
said... but what would happen? I think in such case those levels
wouldn't serve their purpose of being more or less respected and
accepted in practice.

> 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)

If and only if this "levelization" is accepted.

> 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.

I think this is more realistic, but such thing has to be carefully thought.

Stefano