LPX klopfgeist playback gradually slows down

I'm trying to recreate an existing song, using its recording as the basis for tracking. I tapped a MIDI percussion pad to create a file of on-the-beat notes, and used those notes to beat-map the tempo. Using the klopfgeist as the click-sound, when I play the song and the beat-track together they slowly diverge in timing. In less than two minutes there's a subtle but definite delay in the click-track relative to the original song. By 2:30 this delay becomes obvious, and continues to get longer as playback continues uninterrupted. However, if during playback I move the playhead by clicking on another point on the timeline, playback instantly becomes synchronized. Playback is also in-sync regardless of where I begin it in the song. The delay appears to be cumulative, and only becomes perceptible after 90-seconds or so of continuous playback.

 

I've examined and modified settings/prefs that seem pertinent, to no avail. 

 

Anyone have an insight into what might be the origin of this delay?

 

Thanks.

How did you beat map the recorded notes?

 

When successfully beat mapping your notes you should see them end up exactly on the grid, for the whole song. If the notes are off the grid, even if it's 2:30 into your song, then surely you can see them being off the grid, and beat map them to make them fall on the grid?

I don't seem to have gotten this across clearly. The notes I input determined the beat grid; they were the data used in "Beats from Region." The notes are where they're supposed to be on the grid, they just aren't playing back properly. If I knew how to attach an image, you'd see that they're all on an evenly spaced grid. Anywhere I start the song the playback is in-sync for about a minute-and-a-half before the clicks and song become perceptibly out-of-sync. After the delay becomes evident if I reset the playhead anywhere else, everything is instantly in-sync again. It's only during longer playback that this delay becomes apparent. Whatever is going on, the grid doesn't have much to do with it.

The reason I don't follow you is that:

1) The Klopfgeist always plays on the grid.

2) After beat mapping your performance, it is on the grid.

3) That should mean that both play in perfect sync.

 

The best for you would be to attach your project here: control-click the project file in your Finder and choose Compress to create a .zip file. Then click the Full Editor & Preview button at the bottom of this thread, click the "Attachments" tab at the bottom of the reply box and attach the .zip file here.

"3) That should mean that both play in perfect sync."

 

I couldn't agree more – they should play in perfect sync. The project is attached - IF the zipping process worked. The song file itself was 10MB, and I find it hard to believe it compressed down to less than 1MB. We'll see. Presuming it zipped and unzipped properly, let it play without interruption. On my system the divergence in the song and click-track becomes noticeable at about 70-seconds, and is in-your-face after two minutes. If you start the song at 70-seconds - or anywhere else - sync starts out fine. If you let the song run until the divergence is obvious and then - without stopping playback - click on the timeline to relocate the playhead, the song is instantly in-sync again. Creating a beat-track manually like this should permit me to avoid the inhuman sterility of a machine-created click track; that's what I was trying to achieve. You should also know that until I actually execute the "Beats from Region" command, the manual beats and song tracks play in-sync from end to end. It's only after I perform the beat-mapping that they diverge.

Might 2-1 copy.logicx.zip

The problem is that I have your project but not the song file. So all I can hear is the Klopfgeist, which is in time with the grid.

As the MIDI track that triggers the klopfgeist consists of the notes that were used to map the grid, it follows that they're in time with it. I used a 10MB MP3 file as the source audio. With the audio files that Logic creates when I save and zip the project folder it occupies over 80MB. Transferring that file to this board is flatly impractical. Unless there's some other workable method to accomplish that transfer, or to shrink the files, I'm at an impasse. However, if this is indeed a replicable phenomenon, then anyone should be able to reproduce it. This is all I did:

 

1  create a new project with an audio track

2  drag the source audio to that audio track -- I used an MP3 of Stephen Bishop's "It Might Be You"

3  create a software instrument track

4  record MIDI notes on a percussive pad controller in-time with the song as the source audio was playing

5  assign the klopfgeist as the MIDI track's instrument

 

Auditioning the two tracks at this point demonstrated that they were synchronized to the extent that I was capable of entering accurate notes, and that they maintained the same degree of synchronization over the entire duration of the audio source. All the notes were faithfully reproduced as I had entered them.

 

6  I selected the MIDI region and ran the "Beats from Region" command under the global menu using the "1/4 note" popup choice, as that was the tempo I had tapped on the percussive pad, four beats per measure.

 

After a minute or so of playback the resulting tracks diverged perceptibly in timing, and this divergence increased over the uninterrupted duration of the audio source. The klopfgeist became more out-of-sync as playback continued. If playback was stopped, or if the playhead was reset to a different position while the tracks were playing, sync was restored. I have achieved the same result three separate times using the above process. Anyone else ought to experience the same outcome if they follow the same procedure - unless the problem originates with my system, not Logic.

As the MIDI track that triggers the klopfgeist consists of the notes that were used to map the grid, it follows that they're in time with it.

My point exactly: at least that part makes sense.

My point exactly: at least that part makes sense.

It made sense the first time I said it, in the second sentence of the original post. In your responses you assumed I was using the klopfgeist on a machine-created click track, in which case it would always play on the grid, as you stated. But I wasn't doing that. In fact, that's precisely what I was trying to avoid by establishing a non-machine click track in the first place. People are not machines, and they don't offer up pristinely timed performances. IMO, that's a big part of what makes human playing interesting and why we prefer it over mechanical stuff. I was trying to establish a humanized click track as the basis for tracking that would follow as I recreated the song. For some reason it doesn't work, and that makes no sense at all to me. Either Logic somehow alters the MIDI file or the audio in the beat-mapping process, or there's some timing glitch in my system that manifests itself gradually. Creating a non-machine click track is a good idea in theory; it just doesn't work in practice, at least using Logic on my system. I'm eager to know why, but am just as much in the dark as ever. BTW, I selected "Protect MIDI" during one of the "Beats from Regions" iterations, and it made the problem much, much worse. The song and the manual click track were immediately out of sync and never got better. Just something else that doesn't make any sense to me.

Try SMPTE lock your recorded midi region maybe ?

That was a good idea, JakobP. I was unaware of that command, and had to enable the Advanced Editing option of Advanced Menus to use it. Short story: it worked on the manually entered MIDI file, which now plays as accurately as it did before beat-mapping. I'm still in the dark about WHY a track's time code might drift, but this appears to be a solid work-around. On the down-side, I listened to the metronome click - which presumably follows the beat-map - for the first time ever just after I tried your suggestion. Toward the end of the song the metronome click was out-of-sync. Not as bad as the manual click track before locking it, but definitely not in-sync with the source audio. Fascinating. The fun in digital audio just never ends.

 

Thanks for the suggestion. Now I have to decide if it's still worth the trouble to figure out why there's a timing problem, at all.

...I'm still in the dark about WHY a track's time code might drift, but this appears to be a solid work-around....

 

Thanks for the suggestion. Now I have to decide if it's still worth the trouble to figure out why there's a timing problem, at all.

The midi region is only following the tempo changes too, I guess. 

Regarding the timing problem at the end, maybe you have some tempo events left from the last attempt ? 

Regarding the timing problem at the end, maybe you have some tempo events left from the last attempt ? 

No event remnants, so that's not the explanation. The project is simplicity itself: two tracks, one audio, one MIDI. If I SMPTE lock the tracks, they play in-sync. If I beat-map from the MIDI file Logic's metronome loses sync gradually, much as the non-SMPTE-locked MIDI file did. Doesn't matter if I beat-map before or after SMPTE lock - the gradual timing degradation is present in both conditions. I thought my FireWire interface might be the source, so I explored changing its settings, and even switched to the MacPro's built-in sound processor. Doesn't matter, the results were indistinguishable. I'm left with the probability that it's a result of Logic's processing. According to Joe Albano of Ask-Audio, Logic Pro X version 10.2.1 introduced some under-the-hood changes in its beat-mapping algorithm (see https://ask.audio/articles/beat-mapping-in-logic-pro-x). Since I used to perform this manual-click-track routine without encountering any playback difficulty, I suspect that whatever beat-map changes were made are responsible for this gradual out-of-sync playback. It'd be informative if you or someone else would attempt to replicate the problem on your system. If you produce the same result, that would greatly increase the likelihood that Logic is the source of the timing drift. In that case Apple needs to be advised of the situation.

Spent half-an-hour this AM trying to replicate this problem on another MacPro system - this time an eight-core 3,1 with 16GB RAM, running Logic 9.1.7 (1700.57 64-bit) under OS X 10.6.8 (10K549). Used the same source audio file and percussive MIDI controller as in the previous setup.

 

In short, no timing problem exists in the system described above. The "Beats from Region" function produces an accurately synchronized metronome click, and the MIDI region used to create the grid plays back in-sync with the original song file, both over the entire duration of the song. This is consistent with my experience using this technique in the past without difficulty.

 

It seems highly probable, therefore, that the timing problem is a result of programming changes in version 10 of Logic Pro X.

For what its worth, I can't make it work in LPX 10.0.7 either. The notes in the "guide-region" gradually drifts behind. Try this : 

1. Record about 30 seconds of 1/4 notes and smpte lock the region. 

2. Beatmap using "Beats from Region" 

3. Open event list; noted should be "snapped" to the grid, but drifts behimd here...

JakobP, how are you making that determination from the data displayed in the Events list?

This is what I get. Notice the position being spot on the first bar, and then slowly drifting behind: 

The 4th column in the Position display represents ticks. The numbers in that column become progressively greater, when they should be precisely the same after beat-mapping. That's what you're saying, correct?

 

I don't see the same results on my system. After I beat-map a MIDI file, the Event-list notes all display a "1" in the Position-ticks column, which is as it should be. However, the lengths of the notes - displayed in the Length/Info column - are all slightly different from one another, where before they were beat-mapped they all displayed the same lengths. That was by design, as I restricted them all to the same velocity and length. The beat-mapping process evidently alters their lengths, some by as much as 60-ticks. This happens whether the track is SMPTE locked beforehand or not. I have to wonder if, over the length of the source audio file, the cumulative effect of those length alterations might be the source of the timing drift.

 

Curiouser and curiouser. (Hat tip to Alice in Wonderland.)

The 4th column in the Position display represents ticks. The numbers in that column become progressively greater, when they should be precisely the same after beat-mapping. That's what you're saying, correct?

 

I don't see the same results on my system. After I beat-map a MIDI file, the Event-list notes all display a "1" in the Position-ticks column, which is as it should be. However, the lengths of the notes - displayed in the Length/Info column - are all slightly different from one another, where before they were beat-mapped they all displayed the same lengths. That was by design, as I restricted them all to the same velocity and length. The beat-mapping process evidently alters their lengths, some by as much as 60-ticks. This happens whether the track is SMPTE locked beforehand or not. I have to wonder if, over the length of the source audio file, the cumulative effect of those length alterations might be the source of the timing drift.

 

Curiouser and curiouser. (Hat tip to Alice in Wonderland.)

Yes, the ticks increases, but they shouldn't. I tried some more, and realized that it works here if I don't smpte lock, i.e. no "drifting" occurs, all notes on grid. Strange. Regarding the length change you observe, I don't think the notes really have changed in length, the displayed length of a note depends on the tempo, right ? So if yoiu have a note that plays for a second, it will display different length depending on the tempo of the project, see ? since your tempo differs all the time, the displayed note length will also differ.

I understand your reasoning. Whether it's accurate or not, I don't know. The notes I entered were all the same length, but had definite gaps between them. There's no compelling reason to alter their lengths, since they never came close to overlapping. Your explanation may be correct. Nonetheless, the changes in length still seem suspicious to me given that the primary problem is one of timing.

 

It didn't matter on my system whether I SMPTE locked the MIDI track or not. The notes were all precisely on the first tick in their respective positions in either case. The most obvious difference in our setups is that we're running different versions of Logic. I'd bet that's the origin of our different beat-map results.

 

Whatever the case, I still don't know why there's a timing issue in the first place. It doesn't exist in version 9; it shouldn't in version 10. But it does.

I tried some more, and realized that it works here if I don't smpte lock, i.e. no "drifting" occurs, all notes on grid.

The notes being on the grid do not mean they're in-sync with their source file. They SHOULD be in-sync with the audio file to which I was listening when I tapped them, and the fact that they're not - at least on my setup - is the crux of the problem.

A 30-second file is too short for the problem to become manifest on my system. In all of my iterations there was no perceptible drift for the first minute or so. After 90 seconds it was noticeable, after 3 minutes it was so far out of sync that it was hard to listen to it. Whatever else that may be, it's not what's supposed to happen, and it didn't happen in earlier versions of Logic Pro.

I've attached an MP3 of the playback on my system after I beat-map the grid from my MIDI file. The MIDI file is panned hard-left. I couldn't pan the metronome click, so it's on both sides. The source audio file is audible but just barely, so the MIDI clicks and metronome are more discernible. As you listen to it, you'll hear that the two click tracks are in-sync at the beginning. They gradually drift apart and become noticeable, to me, at about 70-75 seconds. After two minutes the MIDI click obviously occurs ahead of the metronome click. I let the playback continue until 3:22 at which point I reset the playhead back about 20 seconds, which instantly brings everything into sync. This is the audio drift I'm talking about, and anybody can hear it - IF the audio file is sufficiently long for the problem to become perceptible.

Homina1.mp3.zip

Just a thought, in the region inspector for your audio region, make sure you don't have "Follow tempo and pitch" selected ? 

 

Wrote this before your last post, regarding the length change of midi notes: 

Try this: 

1. Empty project with one software instrument track, set the tempo to 60 bpm. 

2. Create a region with a note in it at 1.1.1.1, open the event editor and make sure the note length is 0 1 0 0, this now represents 1 second. 

3. option-drag your track down to copy it, and smpt lock it's region. 

4. Change tempo to 120. 

5. Compare the length of the notes in both regions. The length in beats (0 1 0 0) is kept in the unlocked region, and the length "in seconds" is kept in the smpt locked one.

Listened to your mp3, and if your midi notes (and tempo events) are on grid and the metronome plays like that, that's crazy ?!? This seems unrelated to the audio file/region though ?

Regarding your exercise, the locked SMPTE note exhibits twice the duration in the 120 BPM condition, while the original note/track remains the same. I presume that's what you expected to see.

 

The MIDI notes in my project are precisely on the grid since they were used to create the grid. You evidently heard the disparity between the manual click-track and the metronome in my MP3 file. Whatever this phenomenon is, it's real. And it effectively screws up tracking based on a user-defined beat-grid - at least if the project is long enough for the drift to become perceptible.

 

The "Follow Tempo and Pitch" command doesn't appear in the audio track's inspector. All advanced tools are enabled.

 

A partial screen-capture is attached, of the beat-grid centered at about 2:30, long enough for the drift to have become noticeable. You can see that both the MIDI notes and the tempo events are precisely in line with the evenly spaced grid, just as they are supposed to be. This is the exact project that you heard on the MP3.

 

"Crazy" is an apt description for whatever this is.

Might2min.jpg.zip

Regarding your exercise, the locked SMPTE note exhibits twice the duration in the 120 BPM condition, while the original note/track remains the same. I presume that's what you expected to see.

What I tried to show you was that with the smpte locked region the duration of the note is still 1 second, while the "original" note is now half a second in duration.

I took a look at this issue and have found a pretty severe bug related to realtime MIDI playback and tempo changes.

The condition is worsened by using the Multithreaded preference: Playback & Live Tracks.

 

• The Multithreaded preference Playback Tracks starts to behave erroneous at about 200 tempo changes.
  
• The Multithreaded preference Playback & Live Tracks starts to behave erroneous at about 100 tempo changes.

 

Audio is not affected.

Offline accuracy is not affected.