Master Default

I didn't test enough.
In audio there seems to be no problems with just one input or output bus.
In midi it is essential to have an input and output, or Qtractor starts doing strange things.
I should have tested it thoroughly before publishing anything.
I will continue testing it in the coming days.

Could it be made that the new buses are created in the opposite direction to the current one?
I think that would solve all the problems.

I've been doing tests and I think there is no technical conflict in this, although I could be wrong.

"Master Default" would always be the last ones, and they would be identified by being the last ones.

In general, a Master should always be the last one (unless you want to add complementary tools that go outside the real audio flow you are working on, like a special BUS to create RENDERS etc...)

Also, in general, when you create a new bus it always tends to be lower in hierarchy than the previous one (it's not a strict rule, just a tendency).

It would still have some limitations, but there would be much fewer cases where they would manifest themselves. In fact, if you need a "BUS (DISABLE)" or a "BUS RENDER", the problem would not appear, because you would rename the "Master Default" and it would appear after the real Master that you would have created, right in its place (the auxiliary tools should be outside, or after, the real audio stream.

I also thought that it would not hurt to add a lock icon to the "Master Default" to make it clear that it has some properties locked.
Also, the "Duplex mode" should appear disabled, just like the delete button now appears disabled.

What do you think Rui?

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.