Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Sat May 05 2001 - 22:34:22 EEST
> We're not permitting feedback loops, are we ? My impression
> >from this talk of busses and stuff is that a plugin will process a
> >chunk of data from one bus at time `t' and write it to another bus
> >also at time `t' -- not at time `t+chunk_size'. This means that
> >everything that writes to a bus must be processed before something
> >that reads from it. This means that some combinations of plugging
> >things together are illegal. Is this the idea ? Am I on the right
> >track here ?
>
>
> Yes. Each relay through a bus will cause a "frames_per_cycle" delay. I
> am working on some ideas on how to fix this. Its non-trivial. The
> solution is something like:
>
>
> foreach bw in bus-writers {
> bw->do_your_writing (nframes);
> }
>
>
> foreach br in bus-readers {
> br->do_your_reading (nframes);
> }
>
>
> (note that a plugin that is doing bus-reading and bus-writing will
> have to subdivide its own internal work this way too; clearly, some
> combinations will always generate a cycle's worth of delay)
>
>
> this breaks the simple, single "process(nframes)" model, which is why
> i've been reluctant to go there. but i think it may be necessary.
>
Well, I am a big fan of feedback loops, and the ability to make them
with paul's model will allow us to go where fripp and eno could only
dream of going. My simple mind says that there is no need to break the
simple, single "process (nframes)" model if every route connected in a
feedback loop contains a delay line >= n samples. If this is correct
then the only issue is to address the situation where a route does not
contain a delay line >= n samples. Since this is a low latency
environment, n will correspond to something less than 5 msec. Feedback
loops are naturally unstable. They are controlled by placing delay
and/or attenuation components in the loop. Devices that use feedback
deliberately are oscillators, chorus, reverb, and multi-tap delays.
Most other instances of feedback are unintentional, undesirable, and are
eliminated as quickly as the user can figure out what he did to create
that ear splitting noise. Chorus, reverb, and multi-tap delays all use
feedback loops with delay lines. They need to offer delays of less than
5 msec, but they are plugins that can subdivide frames internally.
AES/ardour doesn't need to know about this. So the only reason to break
the simple, single "process (nframes)" model is to allow users to
configure ardour as one grand oscillator. Leave this to the soft
synths. Any user who configures ardour to go into oscillation will do
so by mistake and will immediately remove the feedback loop. They won't
care if the oscillation is clean or if there are artifacts introduced
because each iteration contains an xrun. They will just want to get rid
of it. All musical use of feedback loops within *mixers* contain delay
lines of several seconds (and I can't wait to make some!)
Or am I wrong?
> >> >The use of the bus metaphor seems
> >> >limiting, however. Why not have a complete signal flow graph similar to
> >> >the Max family of languages?
> >>
> >> we do. its only the terminology that's hanging you up. i have been
> >> drawing some diagrams (on paper, alas) to try to make this clear. here
> >> is rough ascii rendition:
> >
> >I'm struggling a little here to understand - I was also imagining a
> >signal flow graph kind of thing. I'm trying to find a model to help
> >me understand how you're thinking about this. I'm wondering if this
> >corresponds to a studio patchbay.
>
>
> No. The diagram shown (for ardour) corresponds to a mixing console,
> plus the connectors on the back. I don't want to encourage this
> metaphor too much because it seems to distract people from the
> possibilities of the model, but its the simplest way to think about
> it.
>
It *IS* the simplest way to think about it.
It is *THE* simplest way to think about it.
It is the *SIMPLEST* way to think about it. (can you tell that I am
enthused?)
This diagram represents the best model that I have ever seen. It is so
simple that it is also deceptive. Please encourage it.
Now I may be blinded by euphoria, but this model supports everything
that I personally have wanted to do in audio mixing, and I feel that it
represents a milestone in audio development. Instead of trying to dream
up a model for accomplishing whatever audio mixing goals that you may
have, project your goal onto this model and see if it can get you
there. If it is a legitimate audio goal and you can't see how this
model can accommodate you, then post your goal and let me see if I can
figure out how to accomplish it with this model. Until someone can come
up with a goal that this model can't accommodate, or come up with a more
efficient way of accomplishing the same thing, this is it. Now someone
may come up with a more efficient model, but for now this is the most
elegantly simple design that I know of.
Tom
This archive was generated by hypermail 2b28 : Sat May 05 2001 - 23:00:01 EEST