Looks good, I have one thought... One of the good things about moving to LV2 will be the possibility of extensions, possibly requiring new whizzy data types / classes on the ports. If this is the case is it a good idea to be tied down to the "enum SLV2DataType" which means the library has to know and support the data type (ie. be able to map "float" to SLV2_DATA_TYPE_FLOAT), and that new data types can only be added by changing the library. If the data type was presented just a char * to the string as given in the .ttl file, then the plugin authors would be free to work with new data types without having to get the core library changed. (This possibly holds for the enum SLV2PortClass too, although that's arguably less likely to need to change (?) ) I hope I've explained myself clearly enough! :) Any sense in this? On 5/26/06, Dave Robillard <drobilla(a)connect.carleton.ca> wrote:

Sounds reasonable to me. Just to clarify, does that mean LV2_DATATYPE_FLOAT would be #define'd as: "http://lv2plug.in/ontology#float" or something else?... I guess consistency would suggest using the same approach for both slv2_port_get_class() and slv2_port_get_data_type().

On Tue, May 30, 2006 at 03:09:33 -0400, Dave Robillard wrote: This is maybe a PITA, but what about a runtime provided enum list, like: foo_enum = { { FOO_FLOAT, LV2_FLOAT_URI }, { FOO_MIDI, "http://example.org/datatypes/midi" }, { 0, NULL } }; lv2_set_urilist(foo_enum); the library can contain an builtin enum list that is set implictly, ie. it does lv2_set_urilist(lv2_internal_enum); when it starts. that way simple hosts can just use it as is, and more complex ones can specify the types they support, and everyone gets to use ints. - Steve

On Tue, May 30, 2006 at 11:43:57AM -0400, Dave Robillard wrote: Returning QNames is bad mojo. Makes sense to me. You could make the API (optionally?) take a char * to write the result into to avoid a lot of malloc() and free()s, but I doublt it's a worthwhile saving. - Steve

On Tue, 2006-05-30 at 19:38 +0200, fons adriaensen wrote: It's not a constant. -DR-

On Tue, 2006-05-30 at 22:27 +0200, fons adriaensen wrote: Well, they can't, but the actual port type values in the data file aren't fixed in any way - there can be any URI (string) there. 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). (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) -DR-

On Wed, 2006-05-31 at 00:24 +0200, fons adriaensen wrote: 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? 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-