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().
The problem with
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 kn
> That's somewhat like saying a corrupt binary
> should never cause a segfault...
No, not at all.
The data file is accessed as an input stream (to the host / LADSPA library).
It's fine for a bad data file to cause the library to fail to be able
to load it, or to load it and produce unexpected outpu
is <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie wrote:
> ...
>
> > Well, it provides a _built-in_ way of ensuring that the struct is
> > properly accessed,
> > even if the metadata file is corrupted or lost.
> > Say a user meddles
> don't think that the string is needed
I think that's fair.
> One version number should be enough though,
> and it doesn't have to match the actual version of the LADSPA spec
Both those points (especially the second) sound simple and sensible.
Okay, so on reflection...
There's a case to be ma
e point in
> changing it over just for the sake of it.
>
> Sure, for some possible future ABI-incomaptible extension we might want to
> add functions, but equally we might not.
>
> - Steve
>
> On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote:
> > Okay, I oug
Okay, I ought to have qualified my 'will always break...' that's
clearly not true.
But there is still real inflexibility in using a struct based API.
eg. Say a developer comes up with a nice extension (perhaps to allow a
plugin to deal with multi-channel IO / non-causal audio effects /
alter the a
I've been following the LAD mailing list for a while now,
mostly to keep an eye the development of LADSPA.
Now seems an appropriate time to voice my thoughts.
Separating out the metadata is certainly (IMHO) the right thing to do,
(I think Steve's proposal is a great step forward)
It mitigates the
