On Tue, 2009-08-11 at 15:15 +0100, james morris wrote: > Hi all, > > I've been thinking about this dynamic ports idea, but without looking at > the specification and without understanding how LV2 hosts work so much... > > So a few thoughts and/or questions: > > creation of a port property which specifies that a port should be > replicated to accommodate the number of channels the plugin will process.
Something like that; the data side of things is relatively easy. > i keep thinking about arrays. passing an array of outputs to connect to > the plugin's inputs. null terminated array ( but this would require a > new connect() method in the lv2core, which probably is a bad solution ). The connect method takes a void* pointer, so this is fine. You can stick whatever kind of data you want in ports without needing a new connect method. The question here is probably: array of pointers to buffers, or one big multi-buffer? The former is probably more flexible. > or > > example: a DC offset removal plugin for a stereo stream > > instead of specifying 'in_left' and 'in_right', we just have 'in'. > the 'in' port is specified with portReplicable (or some such). as the > plugin is operating on a stereo stream, two ports are created 'in0' > and 'in1' (or in1 and in2), then these ports are connected as usual. > > the plugin needs to discover if the host supports portReplicable??? if > the host does not support it, it will do things the old fashioned way - > and there'd be two plugins for left + right - so the plugin will know > because the host will give it the number of channels to process. Backwards compatibility is one reason a big multi-buffer (the first part of which is a single normal buffer) might be good. Though there can just be a rule something like "if the host doesn't support multi-buffers, the plugin must expect a single buffer", which seems fine. > so in LV2 how would the host tell the plugin how many channels the plugin > is to process? That's essentially the problem to solve :) > via const void* extension_data. Well, pretty much everything is via extension_data, and/or features. The usual pattern is to have it return a struct of function pointers. In other words, you can add whatever functions to the LV2 API you want. So here, we need something like a function the host calls to tell the plugin to increase its replication factor. Then rules for when this function can be called and its semantics etc. etc. > having the channel number appended to the port name ( 'in0', 'in1') Port names/symbols (symbols) must not be interpreted in ways like this, ever. > am i right in thinking this would be down to the host to do as it reads > the .ttl? Reading the .ttl and instantiating the plugin binary are different times. How the host behaves will depend on things it figured out from the .ttl though, yes. Cheers, -dr _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev