You are here

Add new comment

As it is now, it generates configuration conflicts.

The Master, by definition and functionality, must be last so that the others can send data to it.

The "Default Master" can stop being semantically and create a new one to replace it.
Correct. But this is where the problem arises, because not only can it not be moved, it must necessarily be "Duplex".

EXAMPLE:

Let's imagine that I rename it as "MIX" to mix before the Master (which is highly recommended, by the way).

The "MIX" must not be "Duplex", but "Output".

Problem? Now I have a "MIX" input bus that I don't need, it takes up space and is confusing, because it appears in the connections.
Can you tell me... Well, use it as an input to record, what does it matter? Yes, it does, because it is confusing. Enough with the mess of plugis, sends etc etc to have inputs that are called incorrectly.

I continue, now I realize that I need a Reverb.

The Reverb must go before the "MIX". Yes or Yes because it is another element that must be mixed.
Again I can't. I must rename "MIX" as "REBERB" and create "MIX" again.
While mixing I realize that the mix requires a bit of strength and character.
A distortion or AMP BUS?
What a coincidence... It turns out that a distortion or AMP is subordinated to the reverb, yes or yes (First the effect, then the space). Start over.
And so on forever and ever.

It's not just that I always end up with two audio inputs that I don't need and that confuse. It's that every time I want to create a new BUS it becomes a nuisance. Because as I indicated in the previous entry, in audio: the buses that are created later are because they are less essential, and for the same reason that they are less essential they are more subordinate.

Summing up. As it is now, it forces you to work in the opposite way to how you should work. That's how it is. You will encounter this problem if you have to work with buses.

The solution that some have adopted is to name "Master Default" as (Ignore) and finally be able to work correctly.
I don't think it's a solution because there are still too many buses and too many inputs and outputs in the connections, which is not clean and is confusing.

The way to work is the Master at the end and subordinate buses from lowest to highest. There is no other way.

Therefore, reversing the order of creation would solve the problem, because it would be the logical way to work.
The MASTER at the end. In this way, you wouldn't have to rename anything, in fact, in most cases the user wouldn't even notice their limitations to move it or change its mode. Because it would be right where it should be, with the configuration that it should be.

It's not something that prevents you from working, but it is something annoying and confusing and frustrating when you start doing advanced things with Qtractor.
Over time, you accept it. I was not the first and I will not be the last. I am surprised that this has not been reported before.
Maybe it was reported and they did not know how to explain the problem properly, because it is complex to explain. Maybe it was not reported because we simply accept that it is a peculiarity of QTractor.

However, it is possible to solve it as I have indicated in the previous entry.