'Subgroup' problem

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.

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.

Greetings,

fuchs

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?

greetings,

fuchs