Main menu
You are here
Move, edit MasterDefault
I'd like to know if anyone else finds this useful.
I'm still working on this in parallel.
Being able to move or edit the "Master Default" would make the work much more fluid and logical.
I'm testing and have found that it is possible as long as a condition is met.
It is complementary to allowing a flexible flow in AuxSend, which Rui is developing now.
Condition: It is possible as long as after the action there are more than 0 inputs and 0 outputs
Pseudocode:
If (
IamBusAudioDuplex AND (NumberOfBusesAudioInput > 0 AND NumberOfBusesAudioOutput > 0) OR
IamBusMidiDuplex AND (NumberOfBusesMidiInput > 0 AND NumberOfBusesMidiOutput > 0)
OR
IamBusAudioInput AND (NumberOfBusesAudioInput > 1) OR
IamBusMidiInput AND (NumberOfBusesMidiInput > 1)
OR
IamBusAudioOutput AND (NumberOfBusesAudioOutput > 1) OR
IamBusMidiOutput AND (NumberOfBusesMidiOutput > 1)
) {
DeletedButton= On;
UpdatedButton= On;
}
I've attached qtractorBusForm.cpp in case anyone wants to test it.
Please note that the condition is not implemented!!!
It allows deleting all channels!!!
It has only been edited to test whether moving/editing MasterDefault generates any unwanted conflict with engineering or the interface.
| Attachment | Size |
|---|---|
 move-edit-MasterDefault.gif | 116.62 KB |
 qtractorBusForm.cpp_.zip | 6.03 KB |
re. Move, edit MasterDefault...
hi,
I'm afraid to say that, under the new internal solution being fostered by the xaudio-bus-aux branch, the (visual) order to the buses will become irrelevant, moot or just kept for UI purposes alone.
though, the Master shall be kept as the first and top of the list, always, no matter what--failing to keep that way is prone to shed some some strange behavior, at best, just because it's a pervasive assumption in way too many internal points (in code) to count, not just in the View/Buses... dialog.
iow., the restrictions you current have in the buses dialog, specially re. Master bus, are there for some old, deep reasons, they aren't there out of a whim ;)
hyu.
I finally understood it. Thanks :)
I finally understood it. Thanks :)
No problem
Maybe I get it totally wrong but I never saw a big problem. You can always create a bus far right and call it MainMaster or whatever. And this bus can output to master (with one jack buffer size of additional latency). Or you connect its output to system:out.
I put my reverb buses more to the right than my echo buses since my echo buses have aux sends to the reverb buses. Once I learned that it has to be that way this was my solution.
re. No problem...
yes, you may still make it like so, no problem at all, but...
the sole benefit to this new
xaudio-bus-auxexperimental/feature branch is exactly that you may now aux-send to buses that are to the left : while the internal processing order is changed accordingly to accommodate the new route, the visual UI order remains untouched.br.
But you have to forbid bus
But you have to forbid bus destinations that would create a loop. So basically it's the same UI problem telling the user why some destinations are missing.
A solution in the old Qtrcator could be that buses to the left are not missing in the menu but grayed out with some kind of hovering message "destination bus has to be right from the sending bus".
In xaudio-bus-aux the message could be "this destination would create a loop".
The xaudio-bus-aux solution would be a little bit sexier, agreed.
re. forbid bus destinations that would create a loop.
prevented already!
in re. Master Default: acyclic aux-sends...:
cheers
Yes, I know. My comment was
Yes, I know. My comment was meant that the forbidden destination buses shouldn't be missing but getting displayed grayed out and with a tooltip when hovering over these grayed out entries saying "this destination would create a loop".
Then no user would ask himself why some destination buses are missing.
Add new comment