30 May
2006
30 May
'06
1:44 p.m.
On Tue, 2006-05-30 at 13:22 +0100, tom christie wrote:
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?
This is why I added the UNKNOWN one; you will always be able to just get
the property directly and check it's value. I suppose you're right, the
enum doesn't really make the API that much cleaner.
The problem with returning strings is namespace prefixes. It's all fine
if the type is in the lv2: namespace so it can return something nice
like lv2:float, but if it's something else it will have to return the
fully qualified URI. For consistency's sake I'll have to return the
full URI for everything.
I think what I'll do is have the type function return a full URI, but
#define symbols for the builtin port types (which is easily extensible
without breaking anything).
Something like:
char* type = lv2_port_get_type(someplug, 0);
if (!strcmp(type, LV2_DATATYPE_FLOAT))
/* ... */
free(type);
Better?
-DR-