On Wed, 2011-06-29 at 11:59 -0500, Gabriel M. Beddingfield wrote: [...] > And this is what I'm wondering... could/should this be > done with an LV2 extension?
Sure; it is straightforward to define new LV2 port types. (Warning: LV2 design tangent follows) However, the more I think about it the more I resent the hard distinction between port types. Us still being stuck with the tinkertoy control ports inherited from LADSPA are the most obvious effect of this. If people want to start playing with alternative sample formats, defining a different port type for each would pose a problem: you need a separate plugin for every sample type. Perhaps this would be okay, since you'd only want one on a given platform anyway, but it seems a bit weak. A more dynamic way to allow a plugin to work with whatever dynamically configured sample format would seem to be better... which is yet another argument for what I increasingly think is the best way to go with LV2 plugin I/O in general: To me (with good ol' 20:20 hindsight), it seems that a single port type that receives messages would be much better than the current situation[1]. Messages would have a standard binary compatible header which distinguishes the various types (much like the current provisional atom extension[2]). Separate units which communicate via generic well defined messages is well-known as a solid computational model with many advantages; it seems to map best to plugins (since many plugins are stateful so purely functional ideas are out, anyway). The plugin can simply list in the data that "this port supports such and such message types", and - if necessary - the host could configure the plugin to expect whatever types of messages it will be delivered. In this case, float audio, double audio, int16_t audio, or whatever. Anyway, the above is a more general "how" discussion mostly of interest to LV2 folks. As for the pragmatic issue of sample formats at hand, the answer is, as always: sure, we can do that. It would break compatibility with existing hosts, though. [1] Actually, I think there are fundamentally /two/ primitive types of ports based on the semantics of how they consume their value: "value ports" and "message ports", but that's a tangential discussion. Suffice to say here that audio ports are messages because they /consume/ their input, so nevermind values. [2] http://lv2plug.in/ns/ext/atom/ _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
