Main menu
You are here
Copy/Paste midi clips on a changed tempo (or zoom/unzoom)
Hi,
This thing (bug?) happened to me a few times before, and I couldn't repeat it, but now I can describe it precisely.
Example:
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
or
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
VM
update
Ok, I remove the tempo change from the song, copy/paste the first 10 bars into the second 10 bars, add the tempo change on the 11th bar but the pasted content is still out of sync. The display of the clips is fine, but the playback is out-of-time
Or, I copy/paste the first 10 bars in to the changed tempo part of the song, and manually, one-by-one, adjust the length of each clip and quantize each clip. Now, the midi notes on the clip are shown in the right place, every clip is just one bar long, but during playback, the track plays in the 'old tempo'. A bit strange, as I can see the midi notes on the proper place, but when the head moves over them, it plays them slightly later, as the clip was not being quantized or edited.
Re: Copy/Paste midi clips on a changed tempo (or zoom/unzoom)
ACK! Good catch!
Please confirm whether the playback related out-of-sync trouble still applies after you reload (re-open) the session altogether, ie. after you save, close and open it again. Question is, does it indict a temporary bug that only happens in-flght while right after making some changes, specially if those changes are made on the tempo map structure, or is it horrifyingly permanent ?
No sweat. This one has been promoted to the very first top priority on my desk, as is one hell of a good and nasty bug report :P
Keep them coming!
Yes, it does stay like that
Yes, it does stay like that after re-opening Qtractor. Both in the zoom and changed tempo options. It seems it follows the 'graphic' logic, as opposed to the 'bar' logic.
I am afraid, it is "horrifyingly permanent". I even restarted the computer, just in case, but no joy, the bars are shifted permanently.
"..Keep them coming!..." Off to a holiday for a couple of weeks. Back mid-April.
Re: Copy/Paste midi clips on a changed tempo (or zoom/unzoom)
Got it.
This is all just annoying and you might say plain wrong. What's actually happening is that the material that is stored in the clipboard (via copy) takes time reference as from its original position. Big problem is that base references are temporarily stored in sample and/or graphic units, frames or pixels respectively. Now, when you try to paste that material onto a new location, things get wrong if that new location has a different tempo from the original one or the zoom level got changed in the meanwhile. Bummer!
I'll try to cope with this in the next weeks. Until then, you'll get best results if you don't paste across tempo nor (horizontal) zoom changes ;)
Cheers.
Zoom = Sync issues. Then crash on export
Hi Rui,
I've had some time this week to play around with the latest CVS version. I was attempting to edit two files together, using two tracks. Track one 's clip starts at the beginning, while track two's clip begins between bars 64 and 65, and track one's clip slightly overlays where track 2's clip starts.
While zoomed in tightly, the edit point is perfect, well it becomes perfect after playing from bar 60-70, but at first, it's not. Each time I play that range, it gets closer until about the third time, then it's perfect from then on. Now, once I zoom out, the edit is no longer perfect, but off quite a bit. Zoom back in, and it's fine again.
Next, when I go to export the track, qtractor segfaults exactly at the edit point.
If I drag the track 2 clip up to track 1, it will render it out without crashing. However, the resulting file's edit point is waaaay off.
The two files in being used here are .mp3 format, and probably not the same bitrate. Could that have something to do with it?
Thanks,
Lexridge
Tried again
Rui,
I just converted both of the mp3 files to .wav format, and I'm still getting the same results....so it's not an mp3 issue.
Lexridge
Re: Zoom = Sync issues. Then crash on export
Hi Jim,
Can you be a bit more specific on this? Is it the audio playback that gets out of sync or is it the graphical waveform display that gets a bit skewed through zooming ? The latter is indeed an expected artifact, the former is pretty serious and intolerable.
Re. crash on export, I'm yet failing to reproduce that and oh, did I try. Maybe there's something you missed to mention. Anyway, please, take the chance to grab a crash stack-trace. It's a recent feature, have a try... ;)
nb. Stack traces are now automagically spitted out on a debug build (cf.
./configure --enable-debug) or can be enabled explicitly (--enable-stacktrace); no need for post-mortem core-dump trickery anymore; stack/back-traces should appear on terminal console output or written to the messages log file if enabled (as in View/Options.../Display/Logging).Seeya
Same issue??
Hey Rui, sorry to revive an old thread but I'm having a similar issue and it sounds like it might be related to this. I created a song using 90bpm tempo across the song. I then inserted some tempo changes using the tempo map window and now it looks like this: Bar 1 90bpm, bar 18 100bpm, bar 58 90bpm.
Everything looks okay visually but when playing something between bars 18 and 57, it sounds out of sync... :(
Would it help if I send you my Qtractor project?
Re: Same issue??
yes, please. send me the simplest session where you can isolate the symptom (in .qtz format)
cheers
Here it is.
I made it as simple as possible:
http://public.elsoftwarehamuerto.org/ZenaidaDebug.qtz
Please notice the following:
* Everything before bar 21 sounds fine. After that, it's out of sync (turn the metronome on).
* If you remove the tempo mapping on bar 21, you can then set the tempo on bar 1 to whatever you want and everything will sound just fine.
Also, look at this screenshot:
http://public.elsoftwarehamuerto.org/QtractorScreenshot.png
This happened when copy-pasting a clip from the 100bpm region into the 90bpm region.
Version info:
Version: 0.5.3
Build: Jan 4 2012 15:14:13
VeSTige header support enabled.
LV2 Plug-in support (liblilv) enabled. (NEW)
LV2 Plug-in UI instantiation support (libsuil) enabled. (NEW)
Re: Here it is.
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 0.5.4.5 (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? :)
seeya
The flac file is just part of
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!
RV.
Not having much luck with new traces
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:
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.
cya,
Lexridge
Re: Not having much luck with new traces
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.
BBL.
[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.
Finally got a stacktrace
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:
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.
Lexridge
Re: Finally got a stacktrace
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 0.3.4.9+)
Something to hand to you
Rui,
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.
Lexridge
Re: Something to hand to you
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.
Cheers.
You are correct, as usual
Rui,
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,
Lexridge
Re: export samplerate conversion crash
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...
BBL
[UPDATE:] A fix to this issue has sneaked into CVS (qtractor-0.4.0.1289+). Please, check it out, as (your) time permits.
Mostly fixed
Hi Rui,
Qtractor no longer crashes at my edit point, however, while jackd is running at 48k, the exported track contains one second of audio, one second of silence, and so on. If I set jackd back to 44.1k, all is well. I'm just now getting today's CVS, so I will try that again later.
Also, I noticed you got rid of the dual replace requester. :)
EDIT [Today's CVS seems to do mostly the same thing. Is this export dependent on latency, because ATM, my latency is set to 1024/42ms, but if latency were the problem, I'd suspect it would also do it at 44.1k.]
Thanks,
Lexridge
Re: Mostly fixed
That is all terribly strange. I've been testing export in several situations and scenarios, wrt. period sizes, sample-rates and even kernels and boxes (32/64bit) and all seems and goes smooth, not a glitch nor that dreaded silence gaps you report on the exported audio file.
Will try to look at it later, maybe a bigger hammer ;)
Cheers
nm, it's working fine
Rui,
It is indeed working. The problem was the I was trying to play the exported .wav in VLC. Apparently VLC cannot play back 24bit wav files worth a crap. Everything else plays it fine.
Thanks again,
Lexridge
RE: nm, it's working fine
I wonder if "working fine" is a prank... hope so.
happy April Fools' day :))
Add new comment