You are here

Home › Forums › Projects › qtractor

Test [xbuses2]

21 September, 2024 - 07:47 — G3N-es

Commit 3171791:
I'm working on a new song without incident.
It seems that the indirect loop suppressor fixes the bugs that were coming up.

Let's see if anyone else is willing to do some testing so that we have more guarantees.

I'll keep working with this branch to detect any incidents.

Related:
Since we're working on sending, I'm going to suggest a new request.

Sending signals from the output of an output bus to the input of an input bus still fails (at least in pipewire) if there are no intermediaries (Carla external etc.).
The first commit of the xaudio-bus-aux branch seemed to fix this.

It's useful for many things, mainly for exporting the song without having to resort to external recorders.

I'm not really asking you to fix it, just to take a look at it. Maybe there was always a small bug there that prevented it and with all this it comes to light and can be solved.
If this is not the case and we still don't know the cause, it's not worth fixing.

As always, I leave it to you to consider.

Forums: 
qtractor
21 September, 2024 - 16:15 — rncbc
rncbc's picture

thanks

it would be very interesting if you do all your tests, on both branches, [xbuses2](https://github.com/rncbc/qtractor/tree/xbuses2) and [xaudio-bus-aux](https://github.com/rncbc/qtractor/tree/xaudio-busaux), independently of course, starting from the same baseline, a new scratch session or one that is untouched by any of these experimental builds (remember to do backups and name or testing sessions wisely ;))

btw. the deeper cyclic/loop detection and avoidance is now also in effect in xaudio-bus-aux.

Sending signals from the output of an output bus to the input of an input bus still fails (at least in pipewire) if there are no intermediaries (Carla external etc.). The first commit of the xaudio-bus-aux branch seemed to fix this.

that's strange,... both branches do nothing in this regard, at least directly; are you really saying that xaudio-bus-aux fixed it in an earlier commit (and now it doesn't anymore)? or am I misunderstanding the whole story?

seeya

22 September, 2024 - 09:26 — G3N-es

__ test-xbuses2_ab3bcd5 __

1_ AUXsend Audio:
They never lose the signal.
"Master Default" only once loses the plugins>fader>vumeter chain when creating a new send.
Setting the send to none and assigning it again fixes the issue.
I have not been able to reproduce the error any more times.

2_ AUXsend Midi: No issues.

3_ Rename/Delete Audio/Midi Buses: No issues.

4_ Direct connection between buses without AUXsend: Not possible

__ test-xaudio-bus-aux_1773e51 __

1_ AUXsend Audio: No issues.

2_ AUXsend Midi: No issues.

3_ Rename/Delete Audio/Midi Buses: May cause you to have to reactivate the AUXsend in audio.

4_ Direct connection between buses without AUXsend:
Only sometimes possible.
Only from the Master Default bus.
BusInExport suffers from the plugins>fader>vumeter chain loss incident
___

CONCLUSIONS:
Generally speaking, both work.
Errors are unpredictable.
Even though all the tests are positive, it does not guarantee that it cannot fail on another occasion.

22 September, 2024 - 06:56 — G3N-es

"that's strange,... both branches do nothing in this regard, at least directly; are you really saying that xaudio-bus-aux fixed it in an earlier commit (and now it doesn't anymore)? or am I misunderstanding the whole story?"

__ [xaudio-bus-aux] commit 7de6ac9 Sep 15, 2024 __

Sending signal from Master to Export.

The signal is not displayed on the VU meter.

However, the "TRACK Export" is
receiving a signal.

I have tested with more buses and
only the "Master Default Bus" is able to
send a signal.

I don't know if there is a previous commit
that was squashed, because I remember being
able to send signal from any bus, without
the plugins>fader>vu meter disabled issue.
___

I continue testing the current commits of the [xbuses2] and [xaudio-bus-aux] branches.

File attachments: 
Image icon BusDirectoBus.gif
22 September, 2024 - 10:11 — rncbc
rncbc's picture

is this the commit where it's seen working (in the BusDirectoBus.gif) ? it's still there alright--it was not squashed--so you can reset to it temporarily (git reset --soft 7de6ac9) rebuild and confirm...

i've tried to replicate it with this commit exactly and the "Export out"->"Master in" doesn't work, as ever before; the same with all main, develop, xbuses2 and xaudio-bus-aux heads.

so, can you still reproduce it?

22 September, 2024 - 11:08 — G3N-es

A_____
"is this the commit where it's seen working (in the BusDirectoBus.gif) ?"
Yes, as indicated in the gif: [xaudio-bus-aux] commit 7de6ac9 Sep 15, 2024

B_____
However, I think there was an earlier commit that was squashed where direct bus forwarding worked fine. I think, I'm not sure.

C_____
"so, can you still reproduce it?"
As I indicate in:

__ test-xaudio-bus-aux_1773e51 __
4_ Direct connection between buses without AUXsend:
Only sometimes possible.
Only from the Master Default bus.
BusInExport suffers from the plugins>fader>vumeter chain loss incident

___

Anyway, that's a minor thing. I see that the behavior is not clear.
We can ignore the direct sending between buses.

22 September, 2024 - 13:35 — rncbc
rncbc's picture

many thanks for the testing and comparison

re. 4 Direct connection between buses without AUXsend results are not actually important and completely orthogonal to the issue at hand, as as they're related exclusively to external loops, on connecting output->input jack-ports directly of the same jack-client (qtractor).

cheers

22 September, 2024 - 15:55 — rncbc
rncbc's picture

hi, sorry to bother you again,

something come out in the mean time re. alleged old/new session compatibility to xbuses2 branch which wasn't quite right...

good news are: new commit 6ed844f tries to fix said allegation; bad news are that it might invalidate (hopefully not) some of your findings and testings :S

it would be awesome if you take the plunge again, granted it's now into xbuses2 alone and see if you find any inconsistencies...

nb. opening sessions that were saved under the previous xbuses2 head are granted to mess up the perceptual (UI) and procedural (DSP) order of the audio output buses, so it is here recommended for you to redo all the testings from scratch, if possible.

wholly thanks again for all the patience you had; no hard feelings, quite the contrary ;)

cheers

23 September, 2024 - 05:51 — G3N-es

I think we have a candidate.
I haven't been able to get her to fail.
I'm attaching a test project.

:)

File attachments: 
Binary Data test_xbuses2_6ed844f.qtz
23 September, 2024 - 07:44 — rncbc
rncbc's picture

great! thanks

so, it's official then :)

if no blockers appear until then, maybe today the xbuses2 solution will merge into develop and main.

thanks a lot. cheers

UPDATE: it's live now, in develop and main: qtractor >= 1.2.0.17git.be3b40

23 September, 2024 - 11:52 — G3N-es

If before Qtractor was the DAW that made normal tasks intuitive, and allowed to do the complex ones.
Now Qtractor is the DAW that makes any task intuitive, whether simple or complex.

Thanks

24 September, 2024 - 05:45 — windowsrefund

Thanks both of you for everything done here. I haven't been testing as I quickly realized I wasn't following and knew I'd just end up adding noise. That said, I've studied the test_xbuses2_6ed844f.qtz session. I'll start converting one of my sessions over to use the new workflow which I believe is based on the following:

  1. Routing from bus A to bus B should always be done via an AUX Send and never by connecting the outputs of bus A to the inputs of bus B.
  2. The Master Audio bus will always sit left-most in the Mixer, first in the list of Audio buses in the Buses panel, and exist in Duplex mode.

I think I'm starting to understand how cool this is going to be as it gets me out of the business of creating and connecting inputs! Nice.

24 September, 2024 - 06:13 — G3N-es

Hi, @windowsrefund :

1_
Exactly, fast and powerful. In 2 clicks and 2 seconds you get something much more functional than in 60 clicks and 60 seconds.

2_
Actually, if you want, the most appropriate thing would be to rename the "Default Master" to "Default Group" and create a master at the end (which is its most logical place).
This way you guarantee that if you create new tracks they will end up in the Default Group without having to configure anything.
Also, if you create more groups, the tracks without a group will rest in the Default Group.

Before this new flow, there would never have been a reason to have renamed the "Default Master" as "Ignore". Because it always made sense for there to be a "Default Group".

Reaching this conclusion is not intuitive, it has cost me a lot, and that was for me the real conceptual error. Calling Master something that really isn't. Master Default is not a Master, it is a Group that assumes Master functions to simplify the simplest workflows.

But of course, documentation would have been needed to explain what a Group is, what an Auxiliary Bus is and what a Master Bus is and how to take advantage of these concepts with Qtractor to create powerful workflows...
I'm working on it :), in less than a week the How to should be finished.

The current flow is much more flexible and allows you to improvise more without having to think too much :).

24 September, 2024 - 12:57 — windowsrefund

Number 2 makes perfect sense. I've done a similar thing with a "SCRATCH" bus which hosts a bunch of typical plugins (synths) I use. By enabling only 1 plugin at a time, I have a constant "audition" track. The benefit here is I'd end up with a similar work flow which wouldn't need to be chased after manually each and every time a new track is added. Brilliant!

26 September, 2024 - 06:34 — windowsrefund

Hi again,

So I just spent a bit of time playing around with this idea and am either doing something wrong or some issue is lurking. I've modified the test_xbuses2_6ed844f.qtz provided by G3N-es by just stripping away some non-essential bits in order to focus on signal flow.

I am hearing the mix in my speakers but I don't see any signal in the mixer's Master strip.

mixer

connections

I also found another crash scenario which can be reproduced by selecting the Filter pulldown menu in the Connections dialog. In my case, I selected the menu and attempted to change from All to Qtractor. It happens regardless of whether the sequencer is playing.

Edit: I forgot to attach my modified .qtz file

File attachments: 
Image icon xbuses2-mixer.png
Image icon xbuses2-connections.png
Binary Data xbuses2-windowsrefund.qtz
26 September, 2024 - 08:11 — rncbc
rncbc's picture

hi, it seems that you messing up the session with different versions of the program, possibly one built on xbuses2 branch and another from an older main or develop head...

for full correctness, once you work under the xbuses2 branch you ought to not open and save a session again on an older build (ie. non xbuses2-aware) as there's a bunch of information that gets lost in between the sheets... :)

anyway, provided you're running the xbuses2 build, you can fix it by reassigning the aux-send in "Mix" to "Master" again, possibly resetting it to "(none)" first and then to "Master" again (see below the results).

btw. the xbuses2 branch has been merged into main (and develop) a few days ago and by this time it is outdated on a couple of fixes already.

hth. cheers

File attachments: 
Image icon Screenshot_20240926_085435.png
26 September, 2024 - 12:03 — windowsrefund

Right, I'm just working from main. That said, I'll just whip together a brand new session as this one was cobbled together from the .qtz mentioned earlier in this thread.

Thanks

26 September, 2024 - 12:23 — windowsrefund

Yes, building a fresh session works entirely as expected. Very nice!

That said, I just discovered something. I have 3 audio buses: Default, MixDown, and Master

When I go to add the Aux Send on a bus, the MixDown string gets truncated.

aux send

Of course I figured "Oh we'll just shorten the string to Mix". Next time we pull down the same selection menu, Mix appears as expected but Master is truncated down to Ma..er

File attachments: 
Image icon aux-name-clobber.png
26 September, 2024 - 12:30 — rncbc
rncbc's picture

that's easily fixable, stay tuned... ;)

otoh. looking at the latest screenshot it seems you're missing some button icons, or are my eyes to blame?

26 September, 2024 - 12:56 — windowsrefund

No, that's just the minimalist approach taken with my theme. :)

26 September, 2024 - 12:55 — windowsrefund

Now I feel dumb because I can't manage to hear an effects bus (delay in this case) in my mix.

Am I doing anything terrible here? The Calf Delay is just left at default settings but the Dry is turned all the way down as my goal here would be to mix the wet signal into the overall mix via an aux send.

File attachments: 
Binary Data AuxSendMix.qtz
26 September, 2024 - 16:26 — windowsrefund

OK so on a whim, I removed the Aux Send on the Delay bus and created a new one with Master as a target. This works but it is not ideal since I'm in the habit of having a final bus where everything is sent before Master.

aux direct to master

File attachments: 
Image icon aux-to-master.png
26 September, 2024 - 17:37 — G3N-es

Hi @windowsrefund and @rncbc:

I'll get it back to you working but...
I've found that it's possible to collapse an auxiliary send if it's copied to a newly created bus.

However, reactivating it fixes it.
But we're already in such convoluted dynamics that I don't know if Rui can really foresee a solution for everything.
Maybe restart the plugin if it's moved or copied?
I don't know...

File attachments: 
Binary Data AuxSendMix.g3n.qtz
Image icon derrumbar-envio.gif
26 September, 2024 - 18:57 — rncbc
rncbc's picture

maybe the solution is just simple as this: moving or copying an aux-send must always reset target bus name to "(none)".

get it? :)

iirc. this was fixed to the current state of matters recently during the xaudio-bus-aux sprints, or sort of, but now I reckon that's probably a (serious) mistake. EDIT: it wasn't, sorry about that; but the writing is on the wall: copying/moving aux-sends must always reset to "(none)", nevertheless

what you think?

26 September, 2024 - 20:13 — G3N-es

I think that's the solution. That would also avoid copying or moving sends to the same destination bus. That is, moving or copying a Master send to the Master bus for example.

As for the user experience, I think it's a perfectly understandable, predictable and even desirable behavior.

Because there will be times when you will copy it with the intention of "cloning" it, but most of the time it will be to edit it and you use the copy/move simply as a shortcut to avoid going to the drop-down menu. (l at least that's my case :) )

26 September, 2024 - 20:27 — windowsrefund

Yes. That would work fine.

27 September, 2024 - 08:22 — rncbc
rncbc's picture

implemented in qtractor >= 1.2.0.22git.2fe581

cheers

8 November, 2024 - 16:51 — G3N-es

It was a bit annoying to lose the AuxSend configuration when moving or copying it. Especially when moving it within the bus itself.

It also creates a lack of coherence, because it is not applied to the tracks (and I think that applying it to the tracks where it is not necessary would be a step backwards).

I have tried a solution. Assign, reset and assign again.
I know it is a bit of a hacky approach, but it seems to work.
Tested with this test file and the gif routine:
https://www.rncbc.org/drupal/comment/10888#comment-10888

qtractorPlugin.cpp | line 2180
		// Special case for audio Aux-sends copied into output buses...
		if ((flags() & qtractorPluginList::AudioOutBus) &&
			(pType->typeHint() == qtractorPluginType::AuxSend) &&
			(pType->index() > 0)) { // index == channels > 0 => Audio aux-send.
			qtractorAudioAuxSendPlugin *pAudioAuxSendPlugin
				= static_cast (pNewPlugin);
			if (pAudioAuxSendPlugin) {
			//g Reset
				pAudioAuxSendPlugin->setAudioBusName(QString());
				pAudioAuxSendPlugin->freezeConfigs();
			//g Restaura
				pNewPlugin->setConfigs(pPlugin->configs());
				pNewPlugin->setConfigTypes(pPlugin->configTypes());
			}

qtractorPluginCommand.cpp | line 353
	// Special case for aux-sends moved into output buses...
	//gDEL m_pAuxSendPlugin = nullptr;

	qtractorPluginType *pType = pPlugin->type();
	if (pType && (pType->typeHint() == qtractorPluginType::AuxSend)) {
		if ((pPluginList->flags() & qtractorPluginList::AudioOutBus) && (pType->index() > 0)) { // index == channels > 0 => Audio aux-send.
			qtractorAudioAuxSendPlugin *pAudioAuxSendPlugin
				= static_cast (pPlugin);
			//gDEL if (pAudioAuxSendPlugin) {
			//g Asing
				m_pAuxSendPlugin  = pAudioAuxSendPlugin;
			//g Reset	
			m_pAuxSendPlugin = nullptr;
			//g Asing
				m_pAuxSendPlugin  = pAudioAuxSendPlugin;
				m_sAuxSendBusName = pAudioAuxSendPlugin->audioBusName();
			//gDEL }
		}

I attach the code. I will test it in the next few days and I will tell you if it really works or if it was a mirage.

PS:
Sorry, "Move" doesn't work, I didn't understand the reset correctly.
I'm still trying and I'll let you know.

File attachments: 
Package icon src.zip
8 November, 2024 - 21:55 — G3N-es

According to the tests I'm running, "moving" didn't create conflicts, it was just copying.

I've just commented out the exceptions and everything seems to work fine:

qtractorPluginCommand.cpp | line 353

/*
	// Special case for aux-sends moved into output buses...
	m_pAuxSendPlugin = nullptr;

	qtractorPluginType *pType = pPlugin->type();
	if (pType && (pType->typeHint() == qtractorPluginType::AuxSend)) {
		if ((pPluginList->flags() & qtractorPluginList::AudioOutBus) &&
			(pType->index() > 0)) { // index == channels > 0 => Audio aux-send.
			qtractorAudioAuxSendPlugin *pAudioAuxSendPlugin
				= static_cast (pPlugin);
			if (pAudioAuxSendPlugin) {
				m_pAuxSendPlugin  = pAudioAuxSendPlugin;
				m_sAuxSendBusName = pAudioAuxSendPlugin->audioBusName();
			}
		}
		else // index == 0 => MIDI aux-send.
		if (pPluginList->flags() & qtractorPluginList::MidiOutBus) {
			qtractorMidiAuxSendPlugin *pMidiAuxSendPlugin
				= static_cast (pPlugin);
			if (pMidiAuxSendPlugin) {
				m_pAuxSendPlugin  = pMidiAuxSendPlugin;
				m_sAuxSendBusName = pMidiAuxSendPlugin->midiBusName();
			}
		}
	}
*/

qtractorPluginCommand.cpp | line 409

	// Special case for audio Aux-sends moved into output buses...
/*
	if (m_pAuxSendPlugin) {
		if (pType->index() > 0) { // index == channels > 0 => Audio aux-send.
			qtractorAudioAuxSendPlugin *pAudioAuxSendPlugin
				= static_cast (m_pAuxSendPlugin);
			if (pAudioAuxSendPlugin) {
				const QString sAuxSendBusName
					= pAudioAuxSendPlugin->audioBusName();
				if (sAuxSendBusName.isEmpty())
					pAudioAuxSendPlugin->setAudioBusName(m_sAuxSendBusName);
				else
					pAudioAuxSendPlugin->setAudioBusName(QString());
			}
		} else { // index == 0 => MIDI aux-send.
			qtractorMidiAuxSendPlugin *pMidiAuxSendPlugin
				= static_cast (m_pAuxSendPlugin);
			if (pMidiAuxSendPlugin) {
				const QString sAuxSendBusName
					= pMidiAuxSendPlugin->midiBusName();
				pMidiAuxSendPlugin->setMidiBusName(m_sAuxSendBusName);
				m_sAuxSendBusName = sAuxSendBusName;
			}
		}
	}
*/

I continue testing.

File attachments: 
Package icon 2src.zip
8 November, 2024 - 23:13 — G3N-es

Restart the "Copy" seems to be a solution to avoid the kind of conflicts that arose when creating or deleting buses referred to in
https://www.rncbc.org/drupal/comment/10888#comment-10888

"Move" seems to not generate conflicts in those cases.

However, logically, now the loop conflicts appear
(I forgot to check this when testing xbuses2 !!!).

If the AuxSend is copied or moved to a position that creates a loop Qtractor will crash (not immediately, but when interacting with resources related to sends).

So the most functional solution instead of resetting the "copy" or "AuxSend moved" to "none", as it happens now, could be to make use of the "cyclicAudioBuses" function, and only in the case that the loop is generated, reset the Auxsend.

I don't think I'll be able to implement this, but I'll try.

9 November, 2024 - 18:49 — rncbc
rncbc's picture

I really appreciate your efforts, but...

what really are you trying to achieve? sorry for asking this--maybe--incredibly stupid question :)

cheers

Pages

Add new comment

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