You are here

Home › Forums › Projects › qtractor

Master Default

10 September, 2024 - 01:36 — G3N-es

I have edited templates in text mode and have successfully created templates with only one Masters Defaults bus in "non-duplex" modes.
Both audio and midi.
Everything has worked perfectly without any errors or crashes.
--- Post edited note ---
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.
---
Obviously, the tracks were not assigned the missing bus, leaving the box empty. But they worked as expected.
If a new bus was created to replace the missing one, the track automatically adopted it.

This experiment has led me to the following conclusions:

1
The interface should allow changing the duplex property and moving the position of the "Master Default" bus, because there is no technical reason that prevents or advises against it.

2
It would be interesting to create a "No Bus" state (both in input and output) for the tracks and that it was selectable, as if it were another bus. Sometimes this configuration is useful. (It allows parallel AuxSends from the same track).

3
If the track has "No Bus" selected it should remain that way even if there is a bus that can take its place.

4
As long as there is more than one bus regardless of its mode, it should be able to be deleted.

5
If there is only 1 bus it cannot be deleted.

Not being able to move the Default Track gave me a lot of headaches until I found a configuration that justified a duplex bus at the top of the bus list.

Many others have encountered this problem and decided to name the master bus "Ignore" or "Disable", but it still took up a visual space in the mixer, which is annoying.

For my part I have already solved it.
Editing the template in text mode frees it from these limitations.

Rui, if you can review what I said and see some sense in it, it would be helpful for everyone, especially for those who are new.
If not, as I indicated, for whom it is useful: it can be solved from the text editor.

Thanks anyway whatever you decide :)

Forums: 
qtractor
19 September, 2024 - 18:25 — rncbc
rncbc's picture

great!

now for not-so-great news:I've come to realize that the xaudio-bus-aux branch is not really the way it should go mainstream, mainly because it might clash on the proverbial all-mighty-back-compability-mantra... yes, yada-yada... whatever.

so let's take another turn, shall we? I know this might be a disgusting situation for you, just because you spent all your time on testing the the xaudio-bus-aux thing and I might just ask you to so it all over again.

so, bear with me... if you're still here... in a few moments there will be this so called xbuses2 branch in the repos: all functionality should be quite equivalent to previous xaudio-bus-aux, nevertheless it binged on the knowledge aquired so all is not (never) lost ;)

I think and strongly believe this is will be the one! :)

You tell me. hyu.

wholly cheers!

19 September, 2024 - 18:48 — G3N-es

It seems correct to me :)

20 September, 2024 - 09:46 — G3N-es

Sometimes creating a new Auxend mutes others. Much less so than the first xaudio-bus-aux version.

Indirect loops cause glitches, but this is unavoidable, I think, unless you're following the chain recursively.

For example mix>effect>reverb>mix

If I'm in reverb, instead of just asking effect>, also ask effect do you have any sends?, which will tell us mix>, and it should be excluded.

I'm starting to think that maybe one-way sends was the way to go.

Rename the master to StereoSequencer, if more buses are needed, and create a new master. :S

20 September, 2024 - 09:55 — G3N-es

In fact, if the "Default Master" was called "Default Sequencer" there would be no conflict. I still think this is a conceptual error, not a programming error. If I want to do simple things, I use the default input and output of the "sequencer". If I want complex things, I create an output Master, which is completely free and editable.

The default bus of the sequencer is not a Master, because according to how Qtractor is designed it lacks the properties to be one (difficulty in receiving all the signals). But it is an excellent default input and output for the sequencer.

20 September, 2024 - 15:39 — rncbc
rncbc's picture

assuming this is already a follow-up to re. xbuses2 branch......

yes, the cyclic aux-sends detection only searched one level deep...

not anymore: hopefully, commit 3171791 in xbuses2 branch gets it agressively deeper, or so I believe ;)...

take care that, for the session(s) already saved with the naive 1-level deep cyclic/loop detection, it surely is advisable to reassign all the target output buses anew, or simply removed and redone all over again, one by one.

thanks && cheers; keep on!

ps. please do try and follow-up to re. xbuses2 branch..., if that's the case; it's increasingly confusing to track all this scattered replies on this lousy forum--no, you're not to blame, it's this arcane drupal thing that is >;)

16 September, 2024 - 06:29 — G3N-es

"you may now switch the aux-sends to "(none)" and back again to the intended target one (eg. "Master") to make it work."
That's not a solution.
If signal reliability cannot be guaranteed, it's better not to have this new feature (although it's wonderful).

Imagine that some subtle reverbs that I put in the background stop working. It's very likely that it will go unnoticed while I mix and master.

Then after listening to the mastered track several times I would say.
This mix is ​​very dry, why?

I would have to go through reverb by reverb to find out which one failed... and the worst thing is, when opening the session from scratch they may all work, or a different Aux Send fails.

16 September, 2024 - 07:21 — rncbc
rncbc's picture

you may now switch the aux-sends to "(none)" and back again to the intended target one (eg. "Master") to make it work.

this is indeed a solution for the interim sessions that were saved while under previous xaudio-bus-aux branch builds (which have been squashed and fixed up by now).

as for all other cases,... keep up!

thanks

17 September, 2024 - 06:12 — G3N-es

I have only had one AUXsend with signal loss.
I have not been able to reproduce the incident.
Everything seems to be working.

I would like to try it in real cases. I don't know how long it will take to communicate the results, whether hours or days.

13 September, 2024 - 19:21 — windowsrefund

I was about to start working with this but find myself confused on the value of this branch since at the moment, it's only 1 commit ahead of main (which was just added 1 hour ago).

13 September, 2024 - 19:31 — windowsrefund

oh maybe you're just appending to your initial commit. That would explain it.

13 September, 2024 - 19:46 — rncbc
rncbc's picture

yes, at the time of this writing, there should be just one commit ahead (from develop or main)

all interim changesets have been squashed to this one:

commit 5db050b2ed7b10a9bea40d637ece459cc09f8713 (HEAD -> xaudio-bus-aux, origin/xaudio-bus-aux)

UPDATE: now superceded by re. xaudio-bus-aux: commit 7de6ac9 (NEW)

12 September, 2024 - 21:32 — windowsrefund

Very interesting! Thank you for the effort. I'll mess around with this tonight and see what I can make of it. Uncharted territory, here we come.... :D

13 September, 2024 - 05:43 — G3N-es

I'm going to start testing right now
(maldito traductor)

On the other hand, I have continued studying a solution.

I have tried to create the solution with the intention of explaining myself better.
I have not been successful (I can read code in c++, but not write it. It is not a language I know).

I respect your opinion. It is not an imposition. It is a simple need to be able to communicate and understand why it could be conflictive.
As I see it, it does not affect audio engineering, it only affects the interface, although I could be wrong.

I will try to explain myself with pseudocode. We open "qtractorBusForm.cpp"

Line 478
// Check whether the current view is elligible for action.

Line 490 should be::

	if (
    "Bus not is duplex mode" ||
    "There is more than one Audio Bus in duplex mode" ||
    "There is more than one Midi Bus in duplex mode"
	) {
		iFlags |= Delete;
	}
	if ((m_pBus->prev())
		iFlags |= MoveUp;
	if (m_pBus->next())
		iFlags |= MoveDown;
	
Line 526 should be::

	if ((pBus == nullptr  || 
		("Bus not is duplex mode" || "There is more than one Audio Bus in duplex mode" || "There is more than one Midi Bus in duplex mode") ||
		m_ui.BusModeComboBox->currentIndex() == 2))
		iFlags |= Update;

Line 643
// Create a new bus from current view.

Línea 699 should be:
	// usually created as last one...
  // "So we will have to move it first of the list later"
  // "because it is a more comfortable place in the usual workflow"
  // "If the sends have to end up at the end, it is most common to position the bus who sends the "send"
	qtractorBus *pBus = m_pBus;
	while (pBus->next())
		pBus = pBus->next();
	showBus(pBus);

	"Send to the new item at the first of the list"
	
	// Select the new bus...
	setBus(m_pBus);

It would not affect old sessions.
The tracks always have an entrance and exit to stay in.
Any bus can now be moved, deleted or updated.
The only restriction is to ensure that there is at least one duplex.
This restriction does not limit the workflow.

But I could be wrong.

19 September, 2024 - 18:54 — rncbc
rncbc's picture

so it begins, again...

as briefed in re. general AUXsend..., this is the new stuff: xbuses2

IMPORTANT: sessions saved while on old xaudio-bus-aux are not compatible with the ones from new xbuses2, not even vice-versa; please start your testings on a clean slate. ;)

r.

Pages

Add new comment

Copyright (C) 2006-2024 rncbc aka Rui Nuno Capela. All rights reserved.
Powered by Drupal