[LAD] Lv2 port replication [was Re: the role of lv2 extensions]

[David Robillard]

On Wed, 2009-08-12 at 23:24 +0100, Steve Harris wrote:
> On 12 Aug 2009, at 23:20, David Robillard wrote:
> >
> > Allow one group of ports to have either no replication, or the same
> > replication count as another group of ports.  Obvious example being,
> > controls tend to stick to 1, audio tends to get replicated, but we may
> > want to replicate the controls to match audio.  So, a single plugin
> > could do all of the above cases in a single instance, if the author
> > wants to do it that way.
> 
> That makes sense to me.
> 
> The real trick is making it back compatible in a clean way.

That, and letting it change while the plugin rolls without dropouts...

What immediately comes to mind is (simplified to ignore groups etc, all
functions on the plugin):

An instantiation class function:

void* prepare_replication(uint32_t count)

Which returns some opaque data structure.  Non-realtime things like
allocation can be done here.

An audio class(*) function:

void apply_replication(uint32_t count, void* data)

Where the host must pass whatever the plugin passed it in
prepare_replication.

This way the plugin can allocate whatever auxiliary data structures or
compute tables or whatever non-realtime stuff needs to be done, then
apply it in realtime, without having to bother the plugin with a bunch
of threading junk that should be the host's problem anyway.  (Apply NULL
to taste for plugins that need no data etc)

On backwards compatibility, something like "if apply_replication has
never been called, the port buffer is a single, normal buffer of the
given data type" seems to be all that would work.  Not too bad, I think.
If this is a problem for some reason it can always be made a mandatory
feature for the plugin.
 
-dr

(* We should change this to "process class")