8 Mar
2004
8 Mar
'04
11:54 a.m.
Tim Goetze wrote on Mon, 08-Mar-2004:
since the latency number is fixed throughout the
plugin lifecycle, the
tap_limiter behaviour of writing to the 'latency' port once, namely as
soon as it is connected, seems the most sensible option.
This is not true for several of the plugins that have a "latency"
output port. The latency value is determined in some plugins
by a combination of the sample rate AND one or more control ports
(lookahead time, etc) which can be changed at any time. In practice,
these control parameters will rarely be changed by the host during the time that
the latency value will be used for compensation, but forcing a
read-once at instantiation will not be a viable solution either.
The way it is now seems fine to me, for the intended purpose.
Ardour, for instance evaluates path latency upon transport start,
so any changes to the latency value in plugins are ignored
while rolling anyway.... however we may not be calling instantiate
at that time.
jlc