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:
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.
Pages
Add new comment