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?

rncbc's picture

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? :))


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:

  1. the clip gets splitted
  2. the cliphead is just an instance from the original file that gets trimmed down to the point where i set the startpoint of the takesrange
  3. the cliptakes are an instance of that original file with an offset set to the startpoint of the begin of the takesrange
  4. 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)

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..

rncbc's picture

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 ;)


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... :)

rncbc's picture

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,



Add new comment