[linux-audio-dev] LV2 library API

[Dave Robillard]

On Wed, 2006-05-31 at 00:24 +0200, fons adriaensen wrote:
> On Tue, May 30, 2006 at 05:48:35PM -0400, Dave Robillard wrote:
> 
> > The function we're talking about pulls this info directly from the data
> > file (not eg from a loaded Port object which would have a const type
> > string).  The library doesn't load all the stuff from the file into
> > memory (in which case the port type would be const), it just queries the
> > data file every time you ask for something (I won't attempt to enforce
> > my guess about what a host would want to cache in memory, that's the
> > hosts' decision).
> 
> In that case it would even make more sense to have the allocation
> for this string done by the caller.

That makes the code even more convoluted, and the caller has no idea
beforehand how big the string might be.  Many functions in this library
return strings, I'm not very keen on the idea of making them all take a
writeable buffer and a size as a parameter (it's weird, more prone to
breakage, and requires more code on the host's part).   I could be
missing something though - what's the benefit?

> > (Rationale being that an LV2 host can run an LV2 plugin keeping only the
> > actual DLL in memory (eg consuming far less memory than an equivalent
> > LADSPA plug), rather than having a bunch of data sitting around that may
> > not be useful)
> 
> The amount of data required for this in LADSPA is really trivial,
> unless it's all created dynamically as is done in some plugins
> (never understood the purpose of allocating a <type> and then 
> copying a constant into it - the thing already exists).
>
> Also considering the amount of code required to get at the data,
> and that you could encode up to 256 port types into a byte, inside
> the .so, I wonder if there is any real gain.

640k ought to be enough for anybody. :)

Who gets to designate what values correspond to what type?  What if
something messes up and different people start using type 38 for
different types of data?  Crash. (This is the lesson learned with LADSPA
numeric ID's - it doesn't work).  As for 'the amount of code', from the
host perspective it's much, much less with libslv2 than with LADSPA.  I
won't lie - accessing the data for LV2 plugins directly /is/ a lot more
difficult than LADSPA, and involves things the vast majority of LAD
coders probably don't care to spend time learning about - that's why I
wrote the library (to make that a non-issue).

I think maybe the point of all this RDF stuff has been missed on this
list in general (stop reading here if you don't care):

The amount of data associated with a plugin may not be 'trivial' at all
- an LV2 plugin could have HUGE amounts of data associated with it if
someone takes the time to put it there (heck, considering you can point
to web resources and the like it wouldn't be difficult to make a plugin
which no known computer could store /all/ information about in RAM, let
alone one a LADer would own).  Authors can put absolutely anything in
there if they want - ridiculous things, host specific things,
categorization based on how much they personally like the
thing, /anything/.  The magic of RDF is that there is no downside
whatsoever to doing this.  You just can't break anything by adding more
data.  Maybe noone cares that you think a plugin sounds "swooshy", but
go right ahead and stick that information in there if you want.  None of
this requires changes to the core LV2 spec (or any centralised consensus
whatsoever).

It's best illustrated by (a less ridiculous) example - take the oft
requested "port grouping" feature (eg signifying that two or more ports
are part of the same group, like a stereo channel):

LADSPA:  Start mailing list discussion, beat the topic to death over
weeks, realize it breaks the spec and it's not worth breaking
compatibility over, have a nice discussion about how the spec sucks
because your pet feature isn't in there, someone mention something about
GMPI saving the day (hah), someone else decides to take the opportunity
to talk about plugin GUIs for the 99999th time, etc. etc. etc,
accomplish nothing.

LV2:  Add the data to the data file.  There is no step 2.

Convoluted?  You tell me.

-DR-