You are here

'Subgroup' problem


i'm having multiple duplex buses wich are connected to the individual drum-outputs of my drummachine. I tried to create another bus to feed all the mixed drum buses into this one, so that i'm able to control the leveled drums alltogether with just one fader. But if i feed the outputs of the individual buses into the new bus, there is no signal arraving. If i just connect the individual bus-outputs to another jackclient, there is a signal comming out of them, but if try to route the output of a qtractor-bus into the input of another qtractor-bus, there is no signal comming in. Am i missing something?


I just found out, that it only happens, if i connect more than one bus-output to one bus-input. As long as there is just one qtractor bus-output connected, it seems to work, but if i connect a second one, the input signal disappears. If i connect multiple jackoutputs of other applications to a qtractor bus-input then it's working fine, so i guess it has something to do with the internals of qtractor.

rncbc's picture

how exactly are you 'feed[ing] the outputs of the individual buses into the new bus' ?

you must know by now that connecting via jack-connections is a no go situation (unless you insert a jack client in between, just like a stub).

the way to go is probably via aux-sends from audio tracks to output buses. however you must also beware of yet another no go situation like the one briefly discussed here


Thanks for the reference to the other post(man is it hard to spot the links inside your post). I will try to explain what is confusing me. I wasn't aware that 'connecting via jack-connections is a no go situation'. I thought that jack in-/outputs are transparent in a way that i'm free to connect them however i like to. I thought that is the idead behind jack in-/outputs. At least, that is exactly how subgoupswork in Ardour. You have 3 individual drum-buses. Every bus has a jack in- and output. You connect the inputs of those buses to the outputs of your drummachine, control the volume so you have a good balance between them. Than you create just another ordinary bus, connect the outputs of your drum-buses to the input of your new bus, there you go. Thats how subgroups work in Ardour. Very straight forward, through transparent jack connections. The same goes for tracks if you want to subgroup them. Same if you want to send some Tracks/Buses through one effects-unit. By having those 'transparent' jack in/outputs on every Bus/Track, it allows for very intuitive free/creative routing. In Qtractor, i'm having hard times even getting things as simple as subgroups getting to work.

I tried to use aux-send on a track as you suggested, but those are pre-fader 'plugins' so that wont work. Also i found a bug here. If you first create an aux-send and a new bus subsequently, the bus won't show up in the selection-box of the aux-send. Maybe it's not a bug, and you just have to obey the 'correct' order in which you have to create things..

I then found this trick in the manual of using an insert but only using the return path and connect it to the output of a bus. So i created a bus called 'drums subgroup' and selected this as the output-bus of my individual drum tracks. In the master bus i then created an insert where i connected the 'drums subgroup'-bus to the return path. But again, this seems to grab the signal of the 'drums subgroup'-bus pre-fader. Don't get it, because if i connect the very same jack-output to my soundcard instead of the return-path of another bus, the signal is postfader..

Now i'm running out of creativity..

I'm also wondering what the wet/dry value for the insert is supposed to do. I guess if you use an insert connected to an external fx-unit, it's used to control the mix between the send(dry)- and the return-signal(wet)? So having it set to dry means 'bypass' the fx and setting it to wet means only the return-signal is coming through? According to this assumption, if you have no send-signal, only a return-signal, you would hear nothing, if you have the value set to dry completely? In the case i described above, the dry/wet value seems to not affect the signal at all.

Sorry for all those questions, but i really tried to achieve a solution.



rncbc's picture

let's try to get a bit technical here... :)

'connecting via jack-connections is a no go situation' *iif* you're connecting ports owned by the very same jack client; depending on its internal processing order you most probably get just silence.

one major issue relates to the zero-copy optimization behavior of jack when only one connection is established on an input buffer port: it just references or points or shunts to the source/output port buffer instead of copying the whole bytes around.

when the input port belongs to the same client owning the connecting output port, then most probably again, you get nothing, zero, nada, dead silence. just because the jack client might process the input buffer *before* clearing and writing to the output buffer, which is perfectly normal on any causal system:)--there, if both buffers are one and the same (zero-copy, remember?) then the input port data just gets lost.

otoh. qtractor is not ardour in any sense (otherwise it would be named after q.i.n.a.;)) btw. have i ever told that it's not a daw.? the sophistication of ardour is well beyond what you might expect from a sequencer like qtractor... oh my...

like most daw's in the world, ardour tends and targets a monolithic, an all-in-wonder model. that meaning, you do everything and the kitchen sink *inside* it. quite the opposite of the jack, at least original prospect, of being the infrastructure of a modular workflow--yeah, qtractor is a hybrid, you can tell that-- nevertheless, linuxaudio history tells you that jack was the original internal audio engine of, yes, no other than ardour indeed, way back on a very early XXI century first decade.

things have changed, as the world itself.


I see. On one hand, i also prefer the non monolithic approach. More like the unix philosophy. One program should solve one problem only, but should do it really well. As you said thats where jack perfectly fits in. It's like pipes in unix or IPC in general but for audio applications. The only issue with this seperation of concerns so far is, that i started to write shell scripts for each projects i'm working on, which starts up all applications involved in the right order(like drummachines, sampler, synths..).

Ardour(or the DAW-approach in general) clearly moves towards the oposite direction. But that is how things get if you try to compete with commercially dominating concepts in the audio world. I'm not shure, if thats a good way to go in the opensource world. Most linux audio applications i have worked with had some serious issues, that existed simply because they tried to accomplish a goal that was way beyond their capacity in terms of manpower. For example, i have worked with Mixxx, but found some really fundamental issues. It's a DJ application, wich is inteded to be used in live situations. They managed to fuck up all their controls by not interpolating between value changes which results in click-noises while changing most values. Because of that, i would never use it in a live situation. To me, that is an essential functionalty for this kind of software. I don't understand why they started features like itunes support or live streaming insted of focusing on such important things. Ardour feels the same to me. A look at their roadmap reveals lots of ideas, but some very basic stuff remains unfinished.

In that regard, qtractor is really a nice supprise to me. It's working quite stable, obvously has a small code-base but despite that i really enjoyed working with it. I much preffer working with software that offers a limited feature set that really works above software which advertises a lot but can't keep up with it. Working with ardour was really frustrating to me. The midi-feature is really unstable and in my opinion should not have been released like that.

Back to the topic :) I didn't completly understand the technical problems related to jack. Only used it once for playback purposes. At the moment i'm struggling with the aux-send/insert routing. So far i have achieved a solution for routing the outputs of multiple tracks through one plugin using a construction of aux-send and an insert. I'm working out several usecases at the moment to make sure, that i fully understand the routing. I think, when i'm done with it, it will be a good idea, to attribute this to the wiki as well, as i'm not the only one having trouble with it, i think.

By the way, i have created a sourceforge account and will start to work on documenting the takes-feature. What's the correct way to get started, working on docucmentation?



rncbc's picture

re. i have created a sourceforge account and will start to work on documenting the takes-feature. What's the correct way to get started, working on docucmentation?

i need to know your handle (username) and grant it authorship privileges. after that, it's just a matter to start from the wiki home and possible add a page afetr another :)

assuming you know markdown, which is pretty simple, you can code html as well:


My username is 'jofuchs'. I have created a draft of the takes docu. It's written so that it might fit into the manual. But it's just a draft. Maybe i will make some screenshots to illustrate the examples. Because my english isn't that good, it would be nice if someone could correct mistakes and such before it's published.

rncbc's picture

@fuchs you're now a member of the project; you can start adding your draft.


Thanks, i have added my draft to the wiki. While i tried to make some screenshots, i encountered the following situation. I have a clip, which i scaled to the size of excatly 8 bars. I set the snap mode to one beat to position the beginning of the clip exactly to the beginning of a bar and then scaled the end of the clip down so it fits exactly into 8 bars. I then placed the edit markers at the beginning of bar one and the end of bar 4. I then used Clip > Take > Range... and selected 'edit'. I expected it to result in two takes, but it results in three. The last take is so small, that i could hardly see it. Don't know what causes this problem. On another clip that i did before, everything worked just fine.

rncbc's picture

well, maybe some offset and/or little rounding error leading to an excess of one tiny "last take" ? maybe the loop/take range vs. whole original clip length wasn't quite an integral multiple of bars?

ease try to reproduce the "problem" with several cases, clips and ranges. to find a pattern somehow.



Add new comment