[Ardour-Users] A3: Silence and session load weirdness after re-open
grib at billgribble.com
Wed Apr 24 09:32:59 PDT 2013
In the context of plugins as "instruments" and building sounds from
networks of plugins, there are certainly plenty of reasons to have
feedback loops. Flange, chorus, delays with feedback, filters
constructed from raw poles and zeros. These can be done within a
plugin, but also by networks of plugins working together.
The only time feedback is a real problem is when it prevents scheduling
of a processing network. Within a single host, you have to choose what
order to run the plugins. If it's a simple network, the order is
obvious... run the ones connected directly to JACK inputs first, then
the ones connected to their outputs, and so on. In general, you have to
look at the network of plugins and "schedule" them.
When there are cycles in the processing graph (feedback paths) you can't
solve the scheduling problem without more information. Classic
"chicken/egg" type situation.... can't run plugin B until plugin A's
output is ready, can't run plugin A until plugin B's output is ready.
UNLESS, you know something about the processing being done. For
example, if you know that a plugin in a feedback path is guaranteed to
ignore its input from this cycle until the next processing cycle (for
example, a delay plugin that has no "dry" output and a delay time of at
least 1 cycle, where a "cycle" here is a JACK process() buffer size) you
can safely run it first and break the feedback cycle. This has to be
known from metadata of some kind. I don't know if LADSPA or LV2
supports this kind of metadata.
Alternatively, the host can just insert such a delay in the feedback
path without asking. I think this is a pretty common approach.
I'm not sure what the right answer for Ardour is, but I just didn't
think it fair to ignore both (1) the good reasons a host doesn't like
feedback, and (2) the good reasons a user might need it supported :)
On Wed, 2013-04-24 at 11:28 -0400, Thomas Vecchione wrote:
> On Wed, Apr 24, 2013 at 9:39 AM, Q <lists at quirq.ukfsn.org> wrote:
> My point was, that feedback loops can be created on purpose
> and if you have created one -- however you've achieved it --
> for a particular effect, you don't want audio to be disabled,
> at any point.
> Personally I am still struggling to think of a case that I would
> prefer to create a feedback loop than to simulate the effect a
> different way(Maybe not possible with current plugins on Linux), but
> that is neither here nor there.
> I could see the value in Ardour disabling audio immediately
> that a loop was created, but there seems little point in
> disabling audio only when the session is re-opened, by which
> time damage could already have been done.
> Actually there is tremendous value, as I mentioned above. When you
> create the feedback loop then chances are you are going to know
> exactly what caused it as there was likely only one action that led to
> the feedback when you create it and hear it. On the other hand in
> opening a session it is far from obvious exactly what caused the
> feedback loop, as there are hundreds of actions happening at once and
> there is no user interaction required for any of them.
> It is almost certainly far better to err on the side of caution in
> this case in my opinion. Personally I would tend to err on the side
> of immediately cut off when a feedback loop is created, but I can see
> some cases where people may want one in corner cases, but also as I
> said above in most of the cases I can think of there are other ways I
> would rather have it handled.
> Ardour-Users mailing list
> ardour-users at lists.ardour.org
More information about the Ardour-Users