On 13/8/2009, "David Robillard" <dave(a)drobilla.net> wrote:
On Thu, 2009-08-13 at 10:08 +0100, james morris wrote:
I was trying to point to the question of: Why
base the replication of a
control port on the replication of the audio ports? The audio port
replication is based on the number of channels, so base the replication
of the control port (if it is to be replicated) on that also.
.... the audio port replication IS the "number of channels".
So we have two new port properties: one to say
this port should always be
replicated - audio ports would use this - and another to say that this
port can be replicated but does not have to be. The matching of counts
is implied because there's no sane reason why port replication counts
would not match.
You are (falsely) assuming the replication is the same across the entire
plugin. i.e. there is no global "number of channels" value
I'm assuming the only ports to be replicated are those which have say a
multiPort property. I don't see why replication would not be the same
in a plugin instance, across all ports with that property.
....
I was imagining the "number of channels" value as being accessible by
something like this:
typedef struct {
/** Opaque pointer to host data.
* The plugin MUST pass this to any call to functions in this struct.
* Otherwise, it must not be interpreted in any way.
*/
LV2_Multi_Ports_Callback_Data callback_data;
/** Access the number of channels the plugin should process.
*/
uint32_t (*get_channel_count)(LV2_Multi_Ports_Callback_Data
callback_data);
} LV2_Multi_Ports_Feature;
Where the host defines the callback data struct and the callback to
access it (and thus provide the dreaded channel count of the particular
stream the plugin is inserted in). The plugin calls the callback when
needed. It might store the channel count (or count of outputs it's
inputs should connect to).
I doubt it, but have to ask: are you saying the plugin will not know how
much replication it should do until its connect method is called with
multiple outputs?
Cheers,
James.