12 Aug
2009
12 Aug
'09
8:36 p.m.
On Wed, 2009-08-12 at 23:24 +0100, Steve Harris wrote:
On 12 Aug 2009, at 23:20, David Robillard wrote:
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")
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.