10 Aug
2009
10 Aug
'09
7:58 p.m.
David Robillard -
Anyway, ...replication in basic form is pretty
straightforward: the host
needs a way to pass a 'replication factor' to the plugin. This raises
a
few obvious questions:
- Should changing this at run-time be possible? This is more useful
with polyphony than with replication for multi-channel purposes. This
raises nasty realtime issues, but since buffer allocation is the host's
problem and a clever host could possibly do it, I think the spec should
make this possible. Maybe there are problems with internal plugin data
that needs to replicate as well but in a non-realtime way though?
I have written plugins that support port replication. In my case they
*appear* to do so in realtime, but don't actually.
The host re-instantiates a replacement (with the extra ports), and the
same parameter settings, then inserts the replacement in the graph 'swapping
out' the old instance (and destroying it). This happens pretty darn fast -
milliseconds.
The advantage is a minimal, simple API - when a plugin in created it
queries it's 'replication factor' and adjusts itself accordingly. I don't
need to support changes 'on the fly' while the plugin is processing audio
(which could be difficult to perform within the constraints of realtime
operation (without memory allocation etc).
So you can avoid the nasty realtime issues, yet easily support run-time
flexibility.
Jeff McClintock