I have lots of midi-tracks with synth-plugins that output to an audio bus. Let's call these buses instrument busses. Their output goes to master in.
Then I'd like to have 2 buses with a reverb plugin (C* plate 2x2) with different settings. Let's call these buses effect buses. Their output goes to Master in as well.
Using only only one effect bus (by several instrument buses) works fine.
Using the 2nd effect bus doesn't work and loading this saved session crashes Qtractor immediately.
The difference between the qtr-file that can be loaded (instrument tracks only use the 1st effect-bus) and the qtr-file that crashes Qtractor (one instrument track uses the 2nd effect bus) is only
< <config key="audioBusName">G Rev1</config>
-
> <config key="audioBusName">G Rev2</config>
As far as I tested the same thing happens when I use an insert-send instead of an aux-send.
hard to reproduce, yet.
would you rebuild qtractor for debugging (./configure --enable-debug) and run src/qtractor from a terminal/console, load the crashing session file and catch the gdb crash-backtrace that gets dumped on output?
also, i'd ask/suggest whether you can make to crash it with a simpler and bare minimal session setup and check whether a crash occurs on the same spot by reading on the crash-dump backtrace.
keep trying and removing simple elements (plugins, clips, tracks, etc.), one by one, one step at a time, until you end with a loadable session which have 2 aux-send inserts in the same track that doesn't crash on load.
nb. use different filenames or incremental backups each time you save for next trial.
when done, attach here the "minimalistic" session file that may reproduce the crash.
hth.
cheers && thanks
Hi Rui, I could save a minimalistic file with no plugins, only 2 audio- und 2 "effect"-buses that lets Qtractor 0.5.10 (compiled on my 64 Bit Xubuntu 12.04 LTS) crash.
I'll be willing to recompile Qtractor with debugging enabled but I think if ths file lets your Qtractor crash as well then that's not needed.
Best regards
Holger
thanks. that got it squared alright.
fix already commited to svn trunk [r3470] aka. qtractor 0.5.10.17.
cheers
Related
Commit: <Commit _id='5181bb35a02bb134b2580972:3470' tree_id='861ea8da12a3e16325ac536e3ea32c4c8f31fe91' committed=I{'date': datetime.datetime(2013, 9, 15, 17, 56, 14, 934000), 'email': '', 'name': 'rncbc'} authored=I{'date': datetime.datetime(2013, 9, 15, 17, 56, 14, 934000), 'email': '', 'name': 'rncbc'} message='- Fixed a sure crash bug exposed when processing of aux-send\n plugins when inserted too early on audio input buses chain\n (after a ticket report by Holger Marzen, thanks).' parent_ids=I['5181bb35a02bb134b2580972:3469'] child_ids=I['5181bb35a02bb134b2580972:3471'] repo_ids=I[ObjectId('5181bb35a02bb134b2580972')]>
No crash anymore. Good job!
Using insert-send now works like a charm.
Using aux-send now doesn't crash anymore but only the 1st effect-bus receives the signal. The 2nd doesn't get any signal when I direct the aux-send to it.
There must still be some bug hidden in the aux-send code.
I tested it more thoroughly:
aux-send in the in-part (left) to 1st effect-bus and aux-send in the out-part (right) to the 2nd effect-bus works
if aux-sends to the 2 effect-buses are both in the in-part (left) or both in the out-part (right) then only the first used effect-bus gets a signal.
And one more test: Doing the same with insert-sends works. But this is not the desirable way because it adds mixer strips in the left part of the mixer and they are labelled "insert" and not like their destination.
problem seems to happen only on aux-sends that route to audio output buses that are created/listed after the input buses on which they are inserted.
maybe fixed now on svn trunk [r3479] aka qtractor 0.5.10.20+.
cheers
Related
Commit: <Commit _id='5181bb35a02bb134b2580972:3479' tree_id='058b9abf7dc60adb748deae72b6663a13547e801' committed=I{'date': datetime.datetime(2013, 9, 19, 19, 0, 46, 61000), 'email': '', 'name': 'rncbc'} authored=I{'date': datetime.datetime(2013, 9, 19, 19, 0, 46, 61000), 'email': '', 'name': 'rncbc'} message="- A primeval processing bug has been sorted out: aux-sends to\n audio output buses that just appear to be after the input\n bus where they're inserted were being left muted and silent\n (on a ticket follow-up by Holger Marzen, thanks)." parent_ids=I['5181bb35a02bb134b2580972:3478'] child_ids=I['5181bb35a02bb134b2580972:3480'] repo_ids=I[ObjectId('5181bb35a02bb134b2580972')]>
Last edit: Rui Nuno Capela 2013-09-19
It is fixed. Thank you.
I was too fast. It works when putting the aux sends in the "in"-part (mixer's left side) of the bus. It's still not fixed in the "out"-part (mixer's right side).
aux-sends that are inserted on output buses might work depending where the destination ouput bus appears wrt. the one which is source, concerning the internal bus create/processing order (as seen on View/Buses... listing top-to-bottom and on mixer layout, left-to-right).
i am sorry, but this isn't quite fixable atm. and must be as is--aux-sends weren't really made to be inserted on buses anyway; although input buses are ok now. output buses are certainly prone to undefined/partial behavior wrt. aux-sends inserts,
see, it's like the old chicken-and-egg problem when you think that you may have aux-send spaghetti with forward/backward loops and what not :).
cheers
Last edit: Rui Nuno Capela 2013-09-20
OK, thanks. Then this ticket could be closed since the crash has been fixed. But then Ticket #70 should stay alive. I could live fine with aux sends in input buses if they were post fader.