Hi Everyone,

In the last year I have recorded a few tracks using Pure Data and I am exporting them into Logic to mix them. I notice that the BPM tempo wavers. For example, if I have a tempo of 150 bpm, when I export the tracks to Logic it might have a tempo of 149.82 for a few bars, then 149.91, then 149.81, etc. it always goes a little slower in a seemingly random way. Over the course of a large number of measure it is way off the tempo. I know this because I have a kick drum pattern that always attacks on a certain beat and I can see it’s off.

I have heard a few other people mention this issue, but it has never really been an issue for me until now. Does anyone have any strategies for dealing with this? I am sequencing a few elements and I want them all to be in sync, drums, a bass part, etc. And all the various drums themselves, like a kick drum, snare drum, hi hat, etc.

I am using regular metro objects all starting from a single message that is sent to the different metronomes. Should I try and use all audio rate timing or something similar?

It is not easy to notice the tempo wavering by listening, but sometimes I think I can notice it too, and it’s sort of weird rhythmic feel as well.

Thank you in advance for any advice.

@nicnut I would expect that you should use a single fast [metro] and counters to subdivide rather than multiple metronomes. But although there will be variations in tempo because of control rate messaging between 64-sample blocks (up to 1.45msecs late for any given trigger) there should not be a slippage in the longer timeframe if you use a single "master" [metro].

From long ago.....
"If you run pd -noaudio, you will find that the timer error becomes much less, but of course then Pd will not generate audio. There is a discussion on lowering latency in the release notes for version 0.33 that may be helpful. Try reducing the block size, the sleep grain, or try running in stream mode."

You could increase the accuracy of each audio sample playback time using [vline~]........ which will schedule a start between samples. You would need an offset from the base tempo to give [vline~] a time to set...... so running a sort "pre-roll" for the track.

Dedicated DAW's written in assembly language don't have the problem of course......
David.

@whale-av ok thank you for the suggestions. I tried recording again last night and had a little more success. I tried having the main metronome everything is based on go at a much faster rate and everything that relies on it will subdivide off that. I'll keep experimenting with this. I'll look into vline~ too.

@nicnut Is it too late to put all the rhythmic triggers in Logic as MIDI, and then just use Pd as a software synth? If the notes are generated algorithmically so you can't do that, then maybe you can record the notes as MIDI into logic, quantize them, then do my previous suggestion? I'm probably way off base.....

@jameslo Hey. I think I'd like to try and keep all the timing in Pd. It's a project with lot's of algorithmically generated rhythms and I don't want to lose that aspect of i. I want to use Logic just to mix and arrange everything. But thank you for the suggestion.

@nicnut I ran into this issue once before trying to beat match a loop with a recording of live musicians, and a friend suggested "warping" in Ableton Live. In the end I didn't need it, but your problem reminded me of that suggestion. By all means rework Pd to do the right thing, but this could be your insurance.

@jameslo

i am doing something similar. The beat wavering is really only noticed over long time periods, like longer than 2 minutes. What I am working on now has a fast bpm, 154 and my metro is counting 16th notes of that, so it's pretty rapid. I am getting almost no beat wavering that I can see with this. But I did make some loops and i am over dubbing using Ableton, sending Pd audio into Live. So far everything is good.

@nicnut

Instead of relying only on [metro]
with it's control rate resolution swing

for a steady clock,
without testing, I'd say
-----LATE EDIT: THE FOLLOWING IS NOT NECESSARY:---------
calculating with the output of
[realtime]
or a sample-counter and [samplerate~]
or [timer]
a message
for [vline~]

should do the trick.

Composing the delay-time-message for [vline~]
by substracting the expected exact time
from the actual time ( at block boundary )

----USING [vline~] WITH ANYTHING (LIKE [metro] JUST WORKS-----

There are many ways to build messages and trigger [vline~] accurately.
Am interested in what you come up with!

Also the time-stamping t3 objects in the iemlib could help!