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
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.

Pages

Add new comment

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