Forums
If the bus input and output ports aren't connected to anything, shouldn't their faders be disabled?
This would prevent attempts to use the fader for something it isn't intended for and would clarify the workflow proposed by Qtractor.
re. A question..
I tend to believe that keeping the faders enabled makes more sense, even though when no ports are connected.
bus connections are all about external routing and can change anytime--they may well be issued elsewhere on the whole jack/pipewire and/ar alsa-seq subsystems.
maybe more fit would be a visual indication that the bus isn't connected than disabling their faders altogether...
but, anyway, is it really worth having yet another visual clue? doesn't meters give you enough?
hyu.
regards.
re1. A question..
I see; that would imply having a continuous monitoring mode, which would consume resources.
For input ports, the meter is sufficient, but that’s not the case for output ports.
The question came up because of that age-old issue: faders on output buses with AuxSend aren't usable.
At least this way, the user wouldn't try to use the faders to control the send from one bus to another via AuxSend. It’s happened to me a lot. They’re just sitting there, and subconsciously you think they’ll control the send. It’s inevitable. It doesn't matter how aware you are that it won't work; realizing the mistake can take milliseconds... or whole minutes XD.
Sooner or later, you’ll find yourself moving the fader to try and control the mix.
It would also clarify the workflow in Qtractor. The user might ask, "Why is it disabled?" Because it isn't connected to anything—and therefore not to the mix; in other words, it isn't part of the mix.
I’ve kept looking into solutions for audio output faders... and no, none of the proposals so far make sense from an engineering standpoint. They’re just workarounds.
Ultimately, the only sensible option to me seems to be turning them into plugins (like in Ardour), meter included. That would simplify not just the user workflow, but also the internal logic of Qtractor’s architecture.
Currently, there are duplicate gain methods for tracks and buses, plus special methods for track automation.
All of that becomes unnecessary if faders and meters are treated as plugins. Automation could be handled by leveraging existing plugin methods.
It would also open the door to @bluebell’s proposal for assignable faders. Mixer faders could simply act as plugin GUIs—logically equivalent to the interfaces you see when opening a plugin's properties.
But a refactor like that is a massive undertaking. So, at the very least, avoiding the use of a fader that you can't actually use seemed to make sense and be logical—especially since faders nowadays operate directly on the port.
P.S.
It's best to leave everything as it is; thanks for replying... XD
Add new comment