You are here

Copy/Paste midi clips on a changed tempo (or zoom/unzoom)


This thing (bug?) happened to me a few times before, and I couldn't repeat it, but now I can describe it precisely.

1. song starts in 120 bpm tempo (4/4)
2. midi track (drums) created and kick recorded for 1 bar
3. that bar is then copied and pasted 9 times (ctrl+shift+V)
4. tempo change 11th bar to 130 bpm
5. copy first 10 bars of midi track, paste into next 10 bars
6. pasted midi is out of sync, as pasted length of separate midi clips is now longer than the length of first 10 midi clips

Similar scenario:
Steps 1 to 4 as before
5. copy first bar only
6. paste it anywhere after the 11th bar
7. notes are in perfect sync (place), but length of clip is slightly longer then bar itself

All this because when tempo is changed, Qtractor adjusts the view and makes the bars with faster tempo a bit shorter in length, which is logical.

But then the pasted midi bars should also auto-adjust their length.

This is really important in two scenarios of making a song.
1a. drums are created and edited per bar for the first half of song
1b. tempo is slightly faster in second half of song
1c. complete drum arrangement is just copied into second part of song
2a (especially in folk music) same drum pattern, but tempo gets faster every bar (usually end of song)

Similar to this is another copy-paste error which I get from time to time:
1. copy a few tracks (audio/midi)
2. zoom or unzoom
3. paste

The shape and notes of the pasted material keep their previous zoom-state shape (thus totally out of sync)

As I said, this doesn't happens always, but 50% of time I would say


rncbc's picture

re. ZenaidaDebug.qtz

- weird. i don't seem to hear or see anything wrong on it. bars 1-20 on 90bpm, bar 21 and beyond on 100bpm. check--it sounds as i would expect... though i'm testing it with (svn trunk)... let's hear what happens with old 0.5.3... well, this is terrible but i can't see what's wrong with it either. can't hear what's actually going out-of-sync, as you say :(

- now, i also heard of this audio file listed in there (Zenaida2.flac)... are you expecting it to follow the tempo changes set on the timeline? eh, wrong! it won't. at least automagically :). dunno if it's of concern here, but you might reckon there's this automatic-time-stretching option feature (see View/Options.../Audio/Automatic time-stretching) but fortunately or not, it only applies when turned on :) and more importantly then it only regards to the tempo (bpm) at the start of the audio clip. only. iow, intertwined tempo changes do *not* apply there yet.

am i going out of range? :)


The flac file is just part of a track I removed before uploading the file for you so no problem there.
That's weird that you don't get the same issue... I'll try re-creating my project and see what happens.
Thanks a lot for checking!

Hi Rui,
First, regarding the sync issue, it's not the graphical skewing I'm talking about...but indeed the audio playback cut point sync between clips and/or tracks.

As far as the debugging goes, I'm not having good luck at all making these new backtraces work thru the --enable option. First, I did the stacktrace, and it worked, copied it to the clipboard. Next, I rebuilt it with --enable-debug, and while running that, the system locked thus taking out my stacktrace clipboard as well (this lockup could be the result of my running a 2.6.29RT kernel, so don't panic on that one ;).

After a reboot, I run qtractor again, using the same debug compile, and got some output, not real verbose IMO. I saved that output in case of a repeat lockup. Recompiled again, this time back to the stacktrace, and I simply cannot get it to output anything now. It worked once, but never again so far, while still crashing in the same place. It only reports a SegFault.

Anyway, here is the debug output:

00:35:39.358 Audio connections change.
00:35:39.370 MIDI connections change.
00:35:44.070 Session closed.

See, not much there.

Anyway, regarding the other issue of lost sync. I'm not too worried about lost sync visually, the sync is off in the audio-engine.

00:35:44.082 qtractorMainForm::loadSessionFile("/home/hines_j/Audio/qtractor/LucidDreams.qtr", 0)
00:35:44.809 Open session: "/home/hines_j/Audio/qtractor/LucidDreams.qtr".
00:35:44.815 qtractorMainForm::updateSession()
00:35:45.076 Session started.
00:35:45.080 qtractorMainForm::viewRefresh()
Enhanced3DNow! detected
SSE2 detected
00:35:45.466 MIDI connections change.
qtractorAudioBus[0x8606ae8]::updateConnects(1): jack_connect: [system:capture_1] => [Qtractor:Master/in_1]
qtractorAudioBus[0x8606ae8]::updateConnects(1): jack_connect: [system:capture_2] => [Qtractor:Master/in_2]
qtractorAudioBus[0x8606ae8]::updateConnects(2): jack_connect: [Qtractor:Master/out_1] => [system:playback_1]
qtractorAudioBus[0x8606ae8]::updateConnects(2): jack_connect: [Qtractor:Master/out_2] => [system:playback_2]
qtractorAudioBus[0x860f728]::updateConnects(2): jack_connect: [Qtractor:Metronome/out_1] => [system:playback_1]
qtractorAudioBus[0x860f728]::updateConnects(2): jack_connect: [Qtractor:Metronome/out_2] => [system:playback_2]
00:35:45.672 Audio connections change.
00:35:55.115 qtractorMainForm::transportPlay()
qtractorAudioBuffer[0x8654588]::inSync(0, 1024) (0)
qtractorMidiEngine::drift(): iAudioTime=29 iMidiTime=0 (29) iTimeDrift=29
00:35:55.870 qtractorMainForm::transportPlay()
00:35:58.725 qtractorMainForm::trackExportAudio()
00:36:06.579 Audio file export: "/home/hines_j/Audio/qtractor/LucidDreamsFinalMix.wav" started...
qtractorAudioBuffer[0x8654588]::seek(0) pending(0, 0) wo=164863 ro=36864
qtractorAudioBuffer[0x8654588]::inSync(0, 1024) (0)
qtractorAudioBuffer[0x8611398]::inSync(0, 440) (0)

Sorry, I know there's not much there to go on, but until I figure out why the stacktrace is not "taking", I can't do better, unless the gdb method still would work. It's getting too late...and can't think. More tomorrow hopefully.


rncbc's picture

The new traces are in fact handed in-flight through gdb and spitted out to standard output. Now, it depends on whether the Capture standard output _and_ Messages log file options are set (in View/Options.../Display), you should get the crash stack-trace on the log file. Otherwise it is thrown to stdout which might get hanged up if you're not watching/capturing it (eg. you did not start qtractor from the console command line).

Did you say that your system is locking up as bad? Is it occurring during the export operation? There's at least a couple of reports. that vaguely relates to ardour2 being hung when exporting sessions, which points me to jackd freewheel mode. Maybe it's a 2.6.29-rt1 sidekick, whatever. I'll try with this latest available PREEMPT_RT kernel patch and see if suspicions are sustainable.


[UPDATE:] Happily running 2.6.29-rt1 now and export on both Ardour and Qtractor is all green lights. Scrap that jackd freewheel mode suspicion to being just rubbish.

Hi Rui,
I most always run qtractor from the console, especially when troubleshooting.
Anyway, I just re-built it with both --enable-debug and --enable-stacktrace. Here is the console output:

[hines_j@garage qtractor]$ ./qtractor
Warning: no translation found for 'en_US' locale: /usr/share/qt4/translations/qt_en_US.qm
Warning: no translation found for 'en_US' locale: /usr/local/share/locale/qtractor_en_US.qm
*** glibc detected *** ./qtractor: malloc(): memory corruption (fast): 0x08c04e40 ***
======= Backtrace: =========
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0          [vdso]
00111000-001f1000 r-xp 00000000 08:01 22146825   /usr/lib/
001f1000-001f5000 r--p 000df000 08:01 22146825   /usr/lib/
001f5000-001f6000 rw-p 000e3000 08:01 22146825   /usr/lib/
001f6000-001fc000 rw-p 001f6000 00:00 0
001ff000-00204000 r-xp 00000000 08:01 36110785   /usr/lib/
00204000-00205000 rw-p 00004000 08:01 36110785   /usr/lib/
00205000-00207000 r-xp 00000000 08:01 22152854   /usr/lib/gconv/
00207000-00208000 r--p 00001000 08:01 22152854   /usr/lib/gconv/
00208000-00209000 rw-p 00002000 08:01 22152854   /usr/lib/gconv/
00209000-0020e000 r-xp 00000000 08:01 24674777   /usr/lib/qt4/plugins/imageformats/
0020e000-0020f000 rw-p 00005000 08:01 24674777   /usr/lib/qt4/plugins/imageformats/
0020f000-00215000 r-xp 00000000 08:01 24674778   /usr/lib/qt4/plugins/imageformats/
00215000-00216000 rw-p 00005000 08:01 24674778   /usr/lib/qt4/plugins/imageformats/
00216000-0021f000 r-xp 00000000 08:01 24674779   /usr/lib/qt4/plugins/imageformats/
0021f000-00220000 rw-p 00008000 08:01 24674779   /usr/lib/qt4/plugins/imageformats/
00220000-00225000 r-xp 00000000 08:01 24674780   /usr/lib/qt4/plugins/imageformats/
00225000-00226000 rw-p 00004000 08:01 24674780   /usr/lib/qt4/plugins/imageformats/
00226000-00229000 r-xp 00000000 08:01 24674781   /usr/lib/qt4/plugins/imageformats/
00229000-0022a000 rw-p 00002000 08:01 24674781   /usr/lib/qt4/plugins/imageformats/
0022a000-0022e000 r-xp 00000000 08:01 24674782   /usr/lib/qt4/plugins/imageformats/
0022e000-0022f000 rw-p 00003000 08:01 24674782   /usr/lib/qt4/plugins/imageformats/
00230000-00274000 r-xp 00000000 08:01 36110915   /usr/lib/
00274000-00276000 rw-p 00043000 08:01 36110915   /usr/lib/
00276000-002a8000 r-xp 00000000 08:01 22146810   /usr/lib/
002a8000-002aa000 rw-p 00031000 08:01 22146810   /usr/lib/
002aa000-002ac000 rw-p 002aa000 00:00 0
002ac000-002b6000 r-xp 00000000 08:01 10715244   /lib/
002b6000-002b7000 r--p 00009000 08:01 10715244   /lib/
002b7000-002b8000 rw-p 0000a000 08:01 10715244   /lib/
002ed000-00309000 r-xp 00000000 08:01 36110621   /usr/lib/
00309000-0030a000 rw-p 0001b000 08:01 36110621   /usr/lib/
0030a000-00356000 r-xp 00000000 08:01 36110695   /usr/lib/
00356000-00359000 rw-p 0004b000 08:01 36110695   /usr/lib/
00409000-00462000 r-xp 00000000 08:01 22124976   /usr/lib/
00462000-00463000 rw-p 00059000 08:01 22124976   /usr/lib/
00463000-00468000 rw-p 00463000 00:00 0
004dd000-004e8000 r-xp 00000000 08:01 36113543   /usr/lib/
004e8000-005d6000 rw-p 0000b000 08:01 36113543   /usr/lib/
0061c000-00639000 r-xp 00000000 08:01 36110786   /usr/lib/
00639000-00647000 rw-p 0001c000 08:01 36110786   /usr/lib/
006b1000-006c4000 r-xp 00000000 08:01 22125399   /usr/lib/
006c4000-006c6000 rw-p 00013000 08:01 22125399   /usr/lib/
006c6000-006ce000 rw-p 006c6000 00:00 0
006d0000-006de000 r-xp 00000000 08:01 22125398   /usr/lib/
006de000-006df000 rw-p 0000d000 08:01 22125398   /usr/lib/
006e1000-006e8000 r-xp 00000000 08:01 36110909   /usr/lib/
006e8000-006e9000 rw-p 00006000 08:01 36110909   /usr/lib/
007e6000-007fc000 r-xp 00000000 08:01 36110834   /usr/lib/
007fc000-007fd000 rw-p 00015000 08:01 36110834   /usr/lib/
007ff000-00809000 r-xp 00000000 08:01 36113542   /usr/lib/

Anything useful here?

[EDIT] Something maybe worth mentioning, after qtractor crashes on the export, qjackctl reports RTle+02% on its display, and I have to stop jack and restart it or qtractor can never connect to it again.


rncbc's picture

Re. Anything useful here?
- not that much :/ that is a glib generated backtrace which implies that there's something hideous like a memory leak or dangling pointer bug lurking beneath. Any chance on reproducing all this trouble with something you can hand over to me?

Re. qjackctl reports RT 1e+02%
this is normal status bahavior; exporting audio in qtractor (as in ardour) does make use of this jackd freewheel mode which is supposed to run the whole thing without any sort of real-time constraints and thus, pure CPU, DSP processing is the limit.

BTW, 1e+02% stands for 100% in non-scientific notation (1e+02 is short for 1 * 10^2 = 100 ;) this visual glitch has been solved in CVS (qjackctl

I can gzip both .wav files and the project file and give you an ftp site in which to retrieve them, if that would work for you. However, the file size will be ~120MB. If this is alright. I will start gzipping them up and email you the ftp link.


rncbc's picture

Ok, I've bite the bullet.

It's a (lib)samplerate related issue: both audio files are in 44k1 and your jackd is running at 48k nominal, so that playback (and export) takes the extra step in making the rate conversion on-the-fly. Somehow, there's still an damn bad old bug in there, in qtractor, that deserves to be tamed.

Please confirm that all is fine when you start jackd with -r44100.

One other thing: whenever qtractor segfaults while in export, it will leave jackd running in freewheel mode, which besides making qjackctl show a cryptic 1e+02% (=100%) DSP load figure, it is pretty useless and brain dead for all else and normal things. Restart jackd and that's it.


Yep, it works at 44100. I kinda surprised I didn't think to try changing the samplerate in jack. Guess I just got used to auto rate conversion just working. That could very well explain the slight differences in the edit point I was hearing as well.

Also, I'm sure you noticed during your export, qtractor asks twice if you want to overwrite the existing file (uh, only if the file exists, obviously, so you may not have noticed unless you tried exporting my project more than once). No biggie, just thought I'd point that tiny one out too.

Anyway, I'm a bit surprised that qtractor needs jack for export functions, since no audio playback occurs during an export. Oh well, so be it. :)

Thanks again,

rncbc's picture

A fix is being cooked at this very moment, that addresses this issue.

In fact, clips that need down-samplerate conversion will corrupt memory (buffer overflow) when export reaches the end of file/clip. Ugly serious bug, ouch! The (not) funny part is that this bug was lurking there for ages...


[UPDATE:] A fix to this issue has sneaked into CVS (qtractor- Please, check it out, as (your) time permits.


Add new comment