Main menu
You are here
'Subgroup' problem
2 November, 2014 - 19:16 — fuchs
Hi,
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?
Forums:
'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.
re. 'Subgroup' problem
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
hth.
cheers
re. 'Subgroup' problem
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
re. 'Subgroup' problem
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.
hth.
cheers
re. 'Subgroup' problem
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
re. starting with documentation
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 sf.net 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:
seeya.
re. starting with documentation
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.
re. starting with documentation
@fuchs you're now a member of the project; you can start adding your draft.
thanks
behaviour of creating takes
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.
re. behaviour of creating takes
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.
cheers
re. behaviour of creating takes
Ok, i found another big problem. The TakeRangeForm needs to be be sanitized more seriously. At the moment, the only check that lets you choose an edit-range is, whether there is an edit-range at all. There are no checks if the edit-range makes any sense. If i for example set an edit-range, which is located completely outsite of a clip, i should not be able to select the edit radio button. At the moment, the form gives me that option and if do so with a range located after the end of the clip, qtractor freezes completly. Due to the current implementation, it would result in a negative number of takes. I have not further investigated so i am not sure what excatly causes the freeze.
re. behaviour of creating takes
good catch.
the Clip/Take/Range... dialog indeed needs some input range sanitizing whenever not dealing the current clip selection (ie. "Selection" radio button option). meaning that all other options ("Loop", "Punch" or "Edit") *must* get their values constrained to the target clip extents, no matter what (and reflect that on the actual/effective range, as it should on "Custom"...
internally, the actual take range must be also capped. probably it doesn't, leading to some potential huge values (formerly unsigned converted from negative) making it all overwhelming lost, somehow :S
nice catch again.
holy thanks
re. behaviour of creating takes
Right. I would have written a patch by now, if this was only a minor range-check or something, but from what i saw this needs some more work. I also think, i found a reproducable way of this takes issue. I will try to hunt it down. Position the playhead at the very beginning of a track. From this point, record 4 bars and just a little bit more from the next bar. Scale the clip down to exactly 4 bars. Position the editmarkers at the beginning of the track and the beginning of bar 2. If you try to create takes from this editrange it will always result in 5 instead of 4 takes.
Do you have an idea how i could stop the makescript from stripping out the debug-symbols?
re. stripping out the debug-symbols
what you mean?
in what way is the build stripping out the debug-symbols (provided you did
./configure --enable-debug... to start with) ?seeya
re. behaviour of creating takes
done.
the Clip/Take/Range... dialog input range values are now properly sanitized... svn trunk r4148 (aka. qtractor v0.6.3.27).
hth.
cheers
sanitized form rev introduced bug
The new revision introduced a evil bug. After recording, my playhead is jumping back and forth. Makes it unusable for some time after recording.
re. sanitized form rev introduced bug
Sorry, from looking at the changes, it's unlikly the revision introduced that behavior. It tuned out it was the '--enable-debug' option i added to my build script. Any ideas why that's happening?
re. playhead jumping back and forward after recording
that is strange no doubt.
what else jack transport client is there playing around while recording?
puzzled.
re. playhead jumping back and forward after recording
I just recongnized, that qtractor spits out like hundreds of those
'qtractorMainForm::audioSyncNotify(428032)
qtractorMainForm::audioSyncNotify(0)'
messages on STDOUT after i stopped recording and the playhead starts jumping around. Don't know if that helps. There are no other jackclients which are somehow related to the transport information.
re. behaviour of creating takes
Very good solution, that the selection-box simply shows no takes and the ok button stays disabled until a valid choice is made. On more thing i found. If you set a range in the middle of a clip and create takes from it, the clip gets splitted into two clips. The latter one is showing the 'correct' takes behaviour, but the first one also pretends to hold the same takes as the later one, which is not the case. If you delete the later one, you can still select takes on the first one which doesn't do anything. If you do not delete the second clip, you can change the takes of the second one, by choosing a take from the first ones take list. Also, if you move the second clip to another position of the track and change the take of the first clip, it gets restored to its original position in the track. I'm not sure, if splitting the clip by choosing a takes range in the middle of a clip is a intended behavior. The latter one, described above i would suppose isn't.
re. behaviour of creating takes
If you set a range in the middle of a clip and create takes from it, the clip gets splitted into two clips.
that is intended behavior. or iow. is working as designed, as originally at least :).
the first split clip is so called the clip-head and remains the same whenever you switch/select takes; the second ones, then called clip-takes are just that, they represent the folded clip takes---these are the ones you may switch/select in a circular basis, while the the clip-head stays put.
as a matter of fact, if you edit or change around the clip-head or any of the clip-takes you'll be destroying the taken information memory, so to speak; like you're committed to the one you are editing (becoming the definitive take, as the chosen one, thereafter:)). as long you don't touch the clip segments, either the clip-head or clip-takes, the information will get saved to the session file. of course, the actual media file that is represented by the clips, either in take fold or not, is not ever modified. as usual in good old non-destructive fashion :)
now, you can argue that the clip-head may be showing a probably incorrect label as "(Take N)" instead of just "(Take 1)", whenever you actually have selected the Nth clip-take (N > 1). might be that the big problem? :))
hth.
cheers
Hm, i don't understand, why
Hm, i don't understand, why one would use takes in that way. From what i understand so far, the clip-head as well as the the created takes-clip point to the same original file(as supposed in non destructive editing). But what i don't understand is, when i have created cliphead and takes that way, i can't do anything with them. They have to stay at the same point in time where they once have been created, otherwise i won't be able to choose from the different takes as this will bring them back to their original position anyway. That behavior feels really odd and unpredictive to me.
But to be honest, setting a takesrange at the middle of a clip would not be something that i would have come up with in a normal working situation
as i couldn't image what that would do to the clip. It's just something i came across due to heavily testing your feature.
The behavior that i would have expected for creating takes from a clip with a range set in the middle of it would be:
I simply doesn't understand why the cliphead as well as the takesclip must stay at the very same position otherwise i loose the abillity to cycle through the takes..
re. behaviour of creating takes
re. i could use the cliphead as well as the takesclip independent from each other (means move them to any point of any audiotrack i want them to, without loosing the abillity to cycle through the takes)
you can. ther's nothing stopping you to copy and paste them around. that's perfectly ok. what you can't do, without loosing the take state information, is moving or cutting the clip-head or clip-takes themselves. that's right, they must stay put in the so called "taken" location and time-line extent. if you're moving or slashing them around they loose their "taken" status.
dura lex sed lex
hope you understand my english ;)
cheers
re. behaviour of creating takes
Yeah, but why is that? Is it just a technical thing, a limiting factor by the internal implementation or is it really intended behavior? And if it's intended, i don't understand the intention though :) I actually CAN move the cliphead as well as the cliptakes around without loosing the takes information. But if i try to switch to another take, the moved takesclip magically jumps back to it's previous position on the track. What i'm trying to outline here is, that from the point of view of a user, who don't know anything about the implementation or maybe the thoughts of the developer, it is simply hard to understand, why the heck, the clips is jumping back as soon as he tries to change to another take(at least, that's what i expirienced). I will try to extend the docs regarding this point, but to me it seems a bit weird to write '...but don't try to move the takesclip nor the cliphead anywhere, otherwise it will jump around if you select another take.'. Sorry, maybe i'm just exorbitantly stupid... :)
re. behaviour of creating takes
as said, it's working as designed::a clip take state set only makes sense on the location and extents on where it was originally defined, either by loop-recording or simulated by the Clip/Take/Range... form.
if you change any of the clip take range set conditions, by moving, resizing or cutting the affected clip(s), then the clip take state information is scrapped, having the resulting clip(s) its normal use and behavior thereafter. of course you can undo the edits and recover to the previous state (ie. take range location). but one thing to retain is that take state information is fixed to the former location and range its was, taken,
hth.
cheers
Add new comment