Audio bus routing enhancement/clarification

Forums

For some time now we can chain audio output buses with no latency via aux sends, eg
track -> audio output bus 1 -> audio output bus 2 > master audio ouput bus

This works fine but it's not very intuitive for new Qtractor users, they will probably use the outputs button. And the fader has no effect and the LED meter is misleading..

So my proposal is:

  • Rename the outputs button to "external output" (or an abbreviation)
  • Add a button "internal output" or "destination bus" which is the same as an aux send.
  • Place this "destination bus" aux send in the signal path after the fader
  • Take the whole chain of destination buses into account when calculating latency

Thus we could improve user friendlyness and latency compensation.

What do you think?

File attachments
Permalink

Well... I think "outputs" is clearer than what you're describing.
What you're really asking for is a default "auxiliary send" that doesn't require a plugin and sends post-fader... (we're back to the same old issue: is it really necessary? :)).

I would put the "auxiliary send" button at the very end of the tracks and buses to indicate that it's post-fader. Since the pre-post-fader position doesn't affect MIDI... it will always refer to an audio send.
If there's no audio plugin, it appears disabled.

However, we're back to the same old problem: it can't be easy to create a post-fader send, otherwise Rui, after so many requests... would have done something. Unless he's deeply convinced it's unnecessary... then there's nothing to be done XD.

For me, yes... what you're proposing is a solution that would clear up a lot of confusion. It is limited in functionality, but very user-friendly, since almost all DAWs include an auxiliary send in their strips.

Permalink

well, for almost two decades now, the "outputs" button stands for the actual output bus ports available to connect to the outer world, so to speak, outer to qtractor pov, in the jack/pipewire graph realm that is.

so, making these "external outputs" semantics change to something "internal", like an aux-send, is not something I'll take so lightly or at the least. There are good points about new users, but well and again, we are still here for the mansplaining aren't we? ;)

excuse me if I'm being funny (no offense intended)
cheers

When working with a DAW I claim that connecting output buses to other output buses is a daily business, much more often than connecting them to the outer world (except for the master output bus). In old times it was only possible to use the output button and connect them to the inputs of a duplex bus (which added one buffer of latency). Now this is disregarded and we have the latency free connections with aux sends.

Users coming from other DAWs or newbies will probably use the output button to connect other buses and get a warning message. So my idea was: Qtractor needs a button that shows that it's possible to connect output buses internally.

I have no problem if the "output" button is kept as-is. I see 2 ways to make internal connections visible for users:

  • Add an additional button for connecting another audio output bus (via the aux send way). This connection should not be shown as a pseudo plugin but only in this dialog.
    or
  • Change the dialog that gets displayed after the "output" button is clicked so the user can configure both external connections and connections to audio output buses (maybe 2 tabs). Also, this aux send should not be shown as a pseudo plugin.

This will retain backward compatibility and also pave the way to an unambigous chain of output buses from a track to master bus which makes adding their latencies simple. If it's possible to put this special aux send post fader, then it will behave like connecting the bus to the outside world – no must for me, but it would be cool.

Mansplaning:
To improve latency compensation there must be one of the many possible aux sends in an audio output bus as a primus inter pares, the one that shows the way to follow to add all latencies. For me, a good solution would be a separate setup dialog and not displaying it as a pseudo plugin. That this would help new users is just a c̶o̶l̶l̶a̶t̶e̶r̶a̶l̶ ̶d̶a̶m̶a̶g̶e̶ nice little extra.

Permalink

Thoughts...
MIDI plugin racks already include an audio out option.

I don't know if the audio plugin boxes lack it due to a simple conditional setting, or if there's more complex programming involved...

The truth is, the design proposed by @bluebell would be more intuitive. It took me months to discover that option in MIDI tracks and buses because it's hidden at the bottom of a right-click menu.

If audio plugin boxes could share this out property, just like MIDI plugin boxes currently do, and they don't simply because it's limited (initially, the point didn't seem clear)... enabling it might be worthwhile.

The problem is that it would still be prefader... and in the case of audio strips it shouldn't replace the current output, it should simply provide the plugin box with an extra audio out.

It would be like having an insert or an auxsend (since MIDI strips rack plugins allow their own output = insert or send to bus = auxsend, the logic doesn't have to change in audio strips rack plugins) always available on all strips without having to necessarily add a pseudo plugin.

Rui?

If the postfader option were added over time, it would simply need to be added to menu.

P.D:
In the case of audio strips, the option "(none)" would have to be added to the existing ones, and it would be the default.

File attachments
Permalink

If audio plugin boxes could share this out property, just like MIDI plugin boxes currently do, and they don't simply because it's limited (initially, the point didn't seem clear)... enabling it might be worthwhile.

no.

  • MIDI tracks (or buses) only have audio outputs the moment you insert an instrument or an audio fx plugin; they're strictly MIDI otherwise, so the "Audio" sub-menu won't ever appear on their plugin-box context-menus;
  • Audio tracks (and buses) have (and are) their own outputs; so for them all this is moot.

on the end of the day, I can't feel it's worth to over-complicate things internally, adding up to dsp branching load, the slightest it might be per track or bus, but non-negligible at scale, that is being traded for an alleged benefit in intuitiveness (or friendliness to new users).

maybe I'm getting old and stubborn :/
thanks anyway

Add new comment

The content of this field is kept private and will not be shown publicly.

Markdown

  • Parses markdown and converts it to HTML.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type='1 A I'> <li> <dl> <dt> <dd> <h2 id='jump-*'> <h3 id> <h4 id> <h5 id> <h6 id> <img src alt height width> <strike> <pre> <p> <br>
  • Lines and paragraphs break automatically.

Filtered HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <b> <i> <pre> <img src alt height width> <strike>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
File attachments
Unlimited number of files can be uploaded to this field.
2 MB limit.
Allowed types: jpg jpeg gif png txt doc docx xls xlsx pdf ppt pps odt ods odp zip gz bz2 xz patch diff wav ogg flac ogv mp4 qtz.