Forums
A track has as much audio channels as its destination bus. The mapping is straight forward, alsways counting from the beginning.
So if there is a track with a multi channel plugin, e.g. drumgizmo, and we use an AUX send to a 2 stereo bus then the first 2 channels are sent to the bus. To send channels 3+4 to the stereo bus we have to use a matrix mixer plugin. To distribute channel 1+2 to a stereo bus, 3+4 to another, 5+6 to another there will be a big mess with many instances of a matrix mixer plugin.
Is it possible to enhance AUX sends by making it controllable which channels in what order are sent to a bus? This would make the use of multichannel instrument plugins much easier, also sidechain handling.
Abnormal behavior when generating channels
Sometimes they disappear, other times they don't add anything but reorder it, and other times they do it correctly.
re. Abnormal behavior when generating channels...
maybe there's still a reason why the "Refresh" button exists on the Connections window? :)
seeya
re. generating channels...
The problem is that it doesn't work until it's updated. It's not that the channels aren't displayed correctly in the connections window, it's that they're not available for sending... Curiously, they do appear in the Matrix, but they don't work.
We're in a parallel sending workflow where it's not necessary to have the connections window open, since the AuxSends work internally.
The user simply perceives that something isn't working as it should... They have no idea (nor could they possibly imagine) that what's happening is that the connections haven't been updated in a window that you don't have open and that you don't have to for this workflow.
(Even though I had it open, it didn't even occur to me.)
Could a connection update be added to the Matrix "accept" function routine?
PS:
In some cases refreshing the connections window doesn't fix it either.
The only way to fix it is to repeat the process of modifying channels until the correct ones appear in the connections window.
Confirmed, it's a problem from before
Refreshing the connections window doesn't fix it.
Apparently, this is a long-standing problem. I downloaded the 1.5.6 appimage, and the problem is also present there.
I'm on Ubuntu Noble Studio, with PipeWire 1.0.5 and XFCE, in case that's related.
My build is with Qt 6.4, and the one in the appimage (as you know :) ) is 6.9.1.
Maybe it's PipeWire, not QTractor, that's failing?
PS
Another curiosity, Qpwgraph and Qtractor give names (different numbering) to the same port when changing the number of ports.
Qtractor out_1, Qpwgraph out_5
re. refreshing...
is also needed on qpwgraph as well, probably... have you tried pressing F5 on it ?
No, the problem is PipeWire, and there may be a solution
I've been testing on three different installations: Mint and Ubuntu with PipeWire on one computer, and Jack on another computer with Ubuntu.
Modifying channels always produces random behavior.
On JACK_
The problem doesn't manifest itself. However, sometimes the modification restarts the server (which has no real consequences; everything works as expected), other times it crashes Qtractor, and other times it works correctly without restarting Jack.
On PipeWire_
Sometimes it performs port modifications correctly. But generally, it's unable to interpret the modifications correctly. Updating in Qtractor does nothing. Updating in Qpwgraph sometimes does nothing, other times it changes things but doesn't quite do it correctly.
It's as if it doesn't know how to interpret what's being asked of it. If you send it 5 output channels, sometimes it creates 2 input and 3 output... It's as if you tell it 5, and it tries to distribute them randomly.
It seems to be a problem interpreting port names.
For example, if I have a Master bus, and I create a Master1 bus, PipeWire may not create the ports for Master1 and instead add ports to Master.
But as I said, you don't know what will happen... it's completely random.
What PipeWire does correctly is always create new ports, not modify them. Whenever you create a new bus, it works fine, creating the indicated ports (unless the name is the same as an already created bus plus numbering. Example: "Master1." As I said before, that sometimes fails).
So there is a solution. Instead of asking PipeWire to modify the ports, you have to ask it to delete the existing ones on that bus and create new ones for the requested ones.
re. problem is something else...
most probably due to the way qtractor:Connections, qjackctl:Connections (also Graph) and also qpwgraph copes when changing the number of ports on same client or node: it doesn't do it very well, most especially when reducing the port count, no so much when increasing it.
I'd suggest you just ignore this bug as it won't get solved any time soon, I guess ;)
thanks anyway.
re. maybe the problem is NOT something else...
please check whether v1.5.6.19git.aef4bd gets any better in this regard.
thanks
:D Now yes
Now we have a tool that allows us to reliably create sidechains (and I suppose more things if we use our imagination).
Thank you very much!
PS:
Interesting. Qtractor needed only 20 ms to do the job properly.
Thx Rui
And again: The best Qtractor the world has seen.
Only one track -> one bus
I thought this way I can easily set up vocoders and side chain compressors. One track with the carrier, one track with the modulator.
But I noticed that only one track's signal arrives on the bus.See example session with two 4ch-tracks.
Track 1's 4ch go to ch 1-4 on the 8ch bus.
But track 2's 4ch don't arrive at ch 5-8 on the 8ch bus.
I think in PW I get the expected behavior
I got a little confused with the cursor when highlighting the flows :), however it seems to work well
re. in PW I get the expected behavior...
how could it be any different ?
this kind of routing--via aux-sends and their new routing matrix--is pure all internal processing: it doesn't depend on the sound-system in charge, whether genuine jack or pipewire-jack substitution...
and I can confirm @G3N-es results on genuine jackd2; all seems to work as expected (bustest.qtz): track 1's 4ch do appear on channels 1-4 on the 8ch bus and track 2's 4ch on channels 5-8 resp. (also under pw-jack as well).
Yes, but...
Although routing doesn't depend on the audio engine, creating and/or modifying ports does.
This is probably what happened here (as I already reported).
If @bluebell opens the file, they'll surely see that everything works.
However, it didn't when they created it; possibly those ports were never generated or were generated with a different ID (name with a different output).
This would confirm that my report also affects Jack, although I couldn't reproduce it on him.
That bug wasn't important before. The need to modify channels or work with multi-channel sessions was anecdotal. But this new feature makes channel modification something that was rarely used in a workflow before now becomes a critical bug. It's completely disconcerting for the user. It's unacceptable to be considered stable.
If I made the connections correctly, why doesn't it work?
Why don't the channels I created exist?
A solution...
The Matrix could be considered unfit for production, but rather an experimental feature. (A special section could be opened in options for experimental features, as Blender does.) And yet, the problem isn't with the Matrix...
That's just my thought. Much appreciated.
Let's see if it's that (the port modification bug) or something else, @bluebell will let us know.
re. Yes, but...
most probably, the new channels you create, they do actually exist!
sometimes, esp. when reducing the number of ports of a bus for example, they may not show properly with their correct names on the connections/graph GUIs (qtractor, qjackctl and even qpwgraph), due to their own inventory recycle process--nothing related to aux-send routing matrix per se (because, as said, this is all done internally to qtractor...)
as told before, a simple full "Refresh" may show them back again, as they are indeed out there for x sake.
but yes, @bluebell will tell the verdict ;)
Oh, yes.
Reloading the session makes it work magically.
Is there another way to do the refresh?
Create or Update?
@bluebell When you open the session, Qtractor generates the ports it reads in the session file correctly, as it does with any other session.
A question. Did you create the "8chan" bus
from scratch with 8 channels? Or did you create it with a different number of channels and then modify (update) it to 8?
My experience is that the error only occurs with modifications. If the bus is created from scratch with the correct channels, there's no problem.
This could be an approach to avoid the problem and indicate it in the documentation.
But perhaps the error also occurs during creation. I'm sure Rui can confirm if the creation process is free of the problem.
For testing, what has worked best for me is to repeat the modification process until I see the correct ports in the connections window.
But I assume the problem will be less evident in a real proyect, since the most logical process is to create a sidechain bus with the correct channels from scratch.
PS
Rui, unfortunately, refreshing doesn't work (in 99% of cases) and therefore does not fix the problem. Matrix connections simply won't work if Qtractor doesn't generate the correct ports.
It seems it's not an audio engine issue, but rather, as you say, a problem with how Qtractor generates channel ports. Obviously, you know this better than anyone; you created it yourself :).
I fully understand that it's something difficult to solve now or in the near future. But then it will need to be documented so the user knows what to expect.
It's said that in computer science, it's impossible to create a truly random algorithm.
Until today. Modifying Qtractor channels gives truly random results. XD
You're right
When I create the bus with the correct number of channels (iinstead of modifying it after creation) then everything works as expected without having to reload the session.
Add new comment