Conceptual work on signal flow / bussing

Community Ideas for Ardour
#1

The signal flow capabilities of Ardour, while flexible, have been somewhat lacking in terms of basic aux sends, busing, cue feeds and general I/O friendliness. Even a modest amount of routing equivalent to a 4-bus console requires quite a bit of JACK plumbing.

In addition to that motivation, we have hazure being paid by Google’s Summer of Code to implement surround panning. Some infrastructure is needed to support the n-channel panning plugins that hazure is developing, so I think this is a good time to tear into the signal flow of Ardour.

I’ve combined some ideas generated by recent IRC discussions regarding bussing, panning, signal flow and metering. This is a “straw man” design so feel free to tear it apart.

The basic design is as follows:

  1. When creating a track or bus, you choose the pan mode (mono, stereo, 5.1 etc)
  2. Any time a bus is created in Ardour, a corresponding “send” is created on every existing track and bus.
  3. Each “bus send” (different than the existing “sends” in Ardour) has a panner control for each track/bus that it can be connected to. The panner control has an on/off switch and a level control for that send.

The total number of “redirects” available on the redirects pane will be increased to 6:

  • plugins
  • inserts (exactly as they are now… a JACK output and input)
  • sends (exactly as they are now… an insert with no return path)
  • returns (a JACK input which gets “mixed” into the signal flow at that point)
  • bus sends ( one of these per bus in the session )
  • Meter point (this defines where the meter next to the fader gets its data)

All of the redirects can be moved around in the signal flow. The first 4 (plugins, inserts, sends and returns) can be arbitrarily created/destroyed per track. Bus sends are created/destroyed whenever the corresponding bus is destroyed.

One final point: the bus sends do not show up in the JACK graph, they are internal to Ardour. Tracks will have JACK inputs just like they do now. The only other JACK connections available will be the the inserts, sends, and returns that the user creates. The master bus will have a post-fader send created automatically and will be routed to the first physical outputs which emulates the same functionality we have now.

Ardour signal flow proposal
ardour_bus_proposal.png392×534

So, what are we showing here? The green dots are the on/off switches for the sends. The green bar is the level control. Just below that is the panner control. The only panner I’ve shown is a mono-to-stereo but there will be other types as well.

The only audio track (far left) has some pre-fader plugins and an insert, a pre-fader meter, a pre-fader cue feed for the musician, and post-fader sends to the drum subgroup, reverb bus, and master output. The master output (far right) has a post fader insert (for jamin?), a post-fader meter, and the final master send which is the main output. I hope everything else is fairly self-explanatory.

Any thoughts/comments?

-Ben Loftis

#2

Another good tweak from hazure

By default, sends will not be created for every bus. Instead, the user can instantiate a send to any bus by navigating a right-click context menu. Interestingly, this allows multiple sends to the same bus from within a track, interleaved between processing blocks. This would allow some parallel processing (such as parallel drum compression) without the use of any extra busses.

For those who expect true “hardware mixer” functionality: with this kind of infrastructure it is easy to add an option that says “auto-create sends to every bus when creating a track” and another option “auto-create sends from every track when creating a bus”. For example when creating a headphone (cue) feed you may want it to automatically create a send for every bus. But when creating a drum subgroup you may want to manually make sends from those tracks.

#3

i think this is definately the best way to do it. maybe the ‘auto create’ option should just be in the bus creation dialog. that way it can be done for some (headphone mixes) and not all (subgroups) without having to go into options and change it each time.

porl

ps. a little while ago i made a long reply in this thread but i obviously forgot to press submit :slight_smile:

#4

Cool! It would be very great to be able to change the send etc. volumes without having to open another window. And the other concepts would be very cool impovements, too - do this as soon as possible!

Benjamin

#5

So basically bus sends would move the selection of target buses to inside the post gain redirect areas, cutting out the creation step?

Might work. It might be better to allow deletion, though.

Would this still look as useful if there’s also a routing matrix?

#6

couple of things. firstly for hazure’s response; is it possible perhaps to make it so that going from ’lower’ to ’higher’ eg 1->2 to 2->2 just keeps the same position on the panner, but obviously adds the extra channels in to balance? eg. if i have a 1->2 panned 75% left, adding in a 2 output plugin above makes it into a default 2->2 panner, but with the option set 75% left. if it is a surround panner, then perhaps default to the middle (between front and back that is) and keep the rest the same.

Your suggestion only really works for the individual case…the panning being implemented is definitely arbitrary, so what happens when panning to a 4-channel bus is ambiguous (it could be a quadraphonic setup, tetrahedron for 3d, etc). Also from project to project, the assumptions on what the input to the panner is could be different.

You bring up a good point about the flood of info on the strip though. I’ll make sure to keep it in mind when doing the gui stuff so someone has the option to decide what they see by default when a connection to a bus is disabled. In the screenshot above, it’s a dimmed green dot, but I don’t see an issue with restricting it to a right-click sub-menu if that’s what the user decides.

#7

hazure, I would suggest d (don’t allow this kind of plugin)

I agree it’s a really cool idea, but it is very difficult to think of a practical reason to do this. Please give a good example and make a sketch of it. Please consider what would happen if the user changed the signal flow, for example moving an insert from before the plugin to after the plugin… must the user then go change the JACK routing to accomodate the new insert width? What if the user disabled the plugin? What if the user deletes the plugin? What if the user inserts 3 “1->2” plugins in a row?

A track/bus must be defined N-wide at startup. Then every redirect in the strip must either be mono (multiple instances with the same settings) or N-wide (such as a 5.1 limiter which has to share state across all 6 channels). In the unusual cases that you want to mix widths (for example sending a mono signal to a high-order ambisonic reverb and back to stereo), then the mixer bus structure accomodate this. In my example you’d send the mono signal to an ambisonic bus, and then send the ambisonic bus back to a stereo bus. There is no question of where the panner goes: it goes at the track/bus crosspoint. This has a secondary benefit of allowing you to run many channels through the same instance of the reverb, each panned to a different location in 3D space. These kinds of problems have been solved in a generic way for about 50 years now… it’s called bus routing. In analog hardware you have to spend exponentially more for each “bus” so only the big rooms had the ability to do complex series/parallel routing. In software we are freed of this limitation.

porl, your idea for hideable channel strip sections is very good. The same method is used in most (all?) of the popular workstations. I agree with your point that on a large project, each track will have lots of unused busses. I do however think that the ability to quickly assign a track to any bus, without doing JACK routing is a benefit worth keeping. So to solve your problem I’d suggest that the bus sends first be created in a “minimized” mode where only the name and on/off switch is showing. Enabling the send would pop up the level and panning controls for that track.

-Ben

#8

couple of things. firstly for hazure’s response; is it possible perhaps to make it so that going from ‘lower’ to ‘higher’ eg 1->2 to 2->2 just keeps the same position on the panner, but obviously adds the extra channels in to balance? eg. if i have a 1->2 panned 75% left, adding in a 2 output plugin above makes it into a default 2->2 panner, but with the option set 75% left. if it is a surround panner, then perhaps default to the middle (between front and back that is) and keep the rest the same. if you are going ‘down’ from high-low (eg 2->2 to 1->2) then a prompt should come up i suppose.

that may show my ignorance as to how the new panner is implemented though :wink:

the other thing, is if i add little ‘sub busses’ (eg ‘drum effects’, ‘percussion section room sim’ etc) on a large project i may have a lot of unused busses listed in each channel. i think there should be an option to not add these buss sends by default and just make it easy to do so in future. adding them automatically by default is a great idea for small projects though.

this is a shameless plug for an issue i put into the tracker, but i think it is especially important now that there is potentially a lot more in each channel strip to have hidable channel strip sections to allow for cleaning up and simplifying the mixer for specific workflows. (note: if you aren’t going to read it, it also includes the ability to move sections of the channels around, eg move the fader to the bottom etc).

cheers
porl

#9

Something to consider…

  • When the connections are made between tracks/busses and all other busses, they will get a panner associated with it.
  • Typically a mono track would get a 1->2 panner to a stereo bus that exists.
  • Adversary goes and puts a plugin somewhere in the strip before the panner.
    • This plugin takes a single input and generates two outputs.

So what happens?
a. Panner goes to default 2->2 scrapping the 1->2 settings
b. Panner takes the first output of the plugin and keeps the 1->2 panner
c. User is prompted to choose option a. or b.
d. Those plugins aren’t allowed.
e. Something else…

#10

Are there any updates concerning this project or plans when to implement it?
It looks very good as it would make the working flow easier and faster.
Keep on the good work!

Benjamin