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!)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.
Or am I wrong?
It *IS* the simplest way to think about it.>> >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. (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
