You are here

can't open session

Hello, I have a .qtr file which I was working on and which I can't open anymore, qtractor brings up the window and after about 1 second exits printing "Aborted". I get this with 0.5 and svn, I even tried running ./configure with --disable-lv2 since from past posts this seemed to solve the issue sometimes... but still it aborts.

Forums: 
rncbc's picture

build for debugging (./configure --enable-debug), start qtractor from command line and watch for any stack-trace output on the terminal console. paste it somewhere i can find later. also of great forensic interest is a pristine copy of the suffering .qtr file.

seeya

ok, built with --enable-debug=yes and with --enable-jack-session=no (I'm using jack 0.118 due to a bug in seq24 with newer versions - but I got this behaviour also with jack 0.121.2), and here's what I get.

you can get the incriminated file here

rncbc's picture

can't access pastebin atm. sorry. but does it sound/look related to some insert plugin like this stacktrace i could manage to reproduce?

Thread 5 (Thread 0x7f858c88d700 (LWP 3703)):
#0  0x00007f859db5ee6d in waitpid () from /lib64/libpthread.so.0
#1  0x0000000000433d3b in stacktrace (signo=11) at qtractor.cpp:302
#2  <signal handler called>
#3  0x00007f859d0ee58b in memcpy () from /lib64/libc.so.6
#4  0x000000000048f66b in qtractorInsertPlugin::process (this=0x1149bf0, ppIBuffer=0xe3c6a0, ppOBuffer=0xe46d50, nframes=1024) at qtractorInsertPlugin.cpp:367
#5  0x000000000051234c in qtractorPluginList::process (this=0x1149070, ppBuffer=0xe3c6a0, nframes=1024) at qtractorPlugin.cpp:1397
#6  0x00000000004451bc in qtractorAudioBus::process_prepare (this=0x1148e40, nframes=1024) at qtractorAudioEngine.cpp:2159
#7  0x000000000044048f in qtractorAudioEngine::process (this=0xa96c30, nframes=1024) at qtractorAudioEngine.cpp:751
#8  0x000000000043f048 in qtractorAudioEngine_process (nframes=1024, pvArg=0xa96c30) at qtractorAudioEngine.cpp:138
#9  0x00007f85a40923e7 in jack_client_thread_aux (arg=0xd06f40) at client.c:2055
#10 jack_client_thread (arg=0xd06f40) at client.c:2123
#11 0x00007f859db56a3f in start_thread () from /lib64/libpthread.so.0
#12 0x00007f859d14067d in clone () from /lib64/libc.so.6
#13 0x0000000000000000 in ?? ()

cheers

EDIT: the issue seems to be caused mainly by inserts on input buses only. tracks and output buses inserts seems to go all the way just fine. i won't tell that's your mistake, as there's certainly a crash-bug in there that i must look closer ntl. however, i'm feeling afraid to ask why you thought to insert standalone jack applications on input buses? wouldn't it be preferable to record all raw signals and then process it later on demand, like inserted on a track or even on output buses instead? k. you're using guitarix so you probably really want to record your guitar after fx- nice. then why you don't connect the output of those processors to qtractor inputs instead of making it an insert? oh- i see, you want to save the whole session connections through qtractor facilities. is that it? ah. how we all need a real good session management these times :)

EDIT 2: if you your session to load, please try to edit the .qtr by hand. fire up your favorite text editor and look for any of these xml entries:

<plugin type="Insert">

then, under each one of those, look after these:

<activated>1</activated>

and substitute that by this

<activated>0</activated>

save and you should be fine now. until next time ;)

hth.

rncbc's picture

may be fixed now: svn rev.2352+ (qtractor 0.5.0.20+)

test && tell
cheers

Rui, as babarosa was saying in another thread, your devotion to this project really deserves some credit :) it's one of the most active linux audio projects and as far as I can tell you're the only main coder. latest svn is opening the file without problems (so I guess the stacktrace I was getting was similar to yours, though I'm not really able to tell).

Regarding the use case, the inserts on the tracks were not to external jack-applications, but to qtractor busses. What I wanted to do was create a Reverb bus, a Distortion bus and so on, each with certain ladspa effects in their inserts, and then for each other track/bus decide how much signal to route to each of these buses. So if I have two audio tracks, for each I can decide how much of it goes "clean" and how much gets routed through the "Distortion" bus.

So last week I was tampering around with this, and I can't really remember now what I came up to. IIRC the "Aux Send" function, which I presume is there to do exactly this, didn't satisfy me because I couldn't "split" the signal, like I can do with the "Insert" thing (which presumably is there for external jack apps) - with that I can decide independently on how much signal goes to the bus and how much bypasses it.

I tried reopening now the project, and I found that on the "Distortion" and "Reverb" busses I can move the ladspa insert plugins on the output busses, and it still "works". But instead on the other tracks/busses in the mixer, those which I want to route to Distortion and Reverb, the inserts to those busses have to be in the inputs; if I move them in the outputs I get only "clean" sound, i.e. like if the "Send Gain" was set to 0. But I guess that is allright and how it is supposed to be...

BTW, I found a potential bug: if I have an insert on a bus/track to route the sound somewhere else, with "Sends" and "Returns" properly connected, and I move this insert (by drag and drop and then select "Move here") to another bus/track, the "Sends" and "Returns" connections are lost. Don't know if it's intentional but it would seem more intuitive to me if the connections were preserved.... otherwise one would just create another Insert instead of moving this.

rncbc's picture

yep. connections aren't restored when moving insert plugins (sends/returns) across tracks or buses. you see, the jack port names will change so... well, it just drops the connections altogether and that's a fact---even undo/redo won't get it back after a move :( i'll see what i can do about that but... no promises :)

otoh, the brand new "aux send" (pseudo-)plugins might be exactly what's needed to fork the signal across two output buses: one is the regular track output and the other is the target of the so called "aux-send" with its own gain control. think again, it might be exactly what you want ;)

cheers

ok, I'll have a better look at it

Add new comment