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-
