Hi there,

I'm building a DJ patch - the whole thing is nearly complete apart from one final problem - accurately setting the playback speed of tracks.

For example, to mix a track at 145 bpm into a track at 146 bpm, you need to increase its playback speed by about 0.7% - playing the track back at a speed of 1.007.

I noticed I couldn't match the two tracks when applying this increase. I wanted to test what was going on by taking the analog output of my soundcard and feeding that into another soundcard which was recording the input in logic (both 44.1khz). I then ran bpm tests on the recorded full tracks using Mixmeister bpm detector (its really accurate!).

What I found was a 145 bpm track was actually being played back at 144.68 bpm, at a play speed of 1. It should have been 145. And when I increased the speed by 0.7% (1.007) the resulting bpm was 144.89, only a 0.145% increase [from 144.68 to 144.89]...

I then reset to 1 playback speed and rerecorded it, it returned to 144.68 - at least it is consistent!

I then set the playback speed to 1.014 (should have been about 2 bpm increase from 145 - 147) and the bpm read 147.69. That's a 2.038% increase [from 144.68 to 147.69], not 1.4%.

Another 145 bpm track gave a reading of 144.71 at playback speed of 1, then 145.67 at playback speed of 1.007. Quite confusing!

Any insight into this problem would be really appreciated! A simplified version of the DJ patch is attached.

Thanks in advance!

http://www.pdpatchrepo.info/hurleur/playSpeedTest.pd

Hi Architekt,

to tell it with words (tell me if I'm wrong), you drive your ramp generator with a 'heartbeat', which is itself triggered by a [metro 1]. Each new heartbeat tells the ramp to ramp up at 45° for 1ms, and all these 44.1 samples ramp chunks operate as a counter sending the calculated index that has to be passed to your tabread4~'s. The counter is reset by a simple [sel 1] test.

I played around with pretty close variants of this scheme recently, and came to your very conclusion : it seems impossible to maintain mathematical time precision when triggering audio objects with non-audio objects. But it plays and sound as expected and could be judged satifactory form some purposes. But only in appearance.

Non-audio obects are meant to be 'refreshed' every audiobuffer size, generally 64. This means, if I don't make a mistake, that messages will be actually sent with a delay that can be in the worst case of 63 samples. I see it as a 'pd cpu clock'. A jitter in this delay between the 'pd cpu-clock' and the audio processing would not be compatible with time accuracy. This is just my interpretation, I'm not sure of it !.
The 'heartbeat' [metro 1] object is a non-audio object too, but is maybe different from other non-audio objects, I never dig it. Maybe it has a better accuracy ? Nevermind, I'm loosing the thread here

Maelstorm advised me some day to play with [rpole~ 1] objects. It is just an accumulator that makes audio ramps easy, and can be passed to an [expr~] to take the modulo of the sample size. The only problem is that when time grows up the [rpole~] can reach 16bit float precision limit, and resetting it will make a click.
That's why [phasor~] exists, but even if changing its frequency at audiorate works, a new problem arises : how do you loop with that ? In fact you can make an [expr~] if statement that detects the end of sample index, but as the only way I know to clear an [rpole~] is a MESSAGE, our problem comes again : looping slightly delayed.

Ok I htink I've been too long, cheers,

Nau

Hello mates:

@nau said:

[...]
That's why [phasor~] exists, but even if changing its frequency at audiorate works, a new problem arises : how do you loop with that ? In fact you can make an [expr~] if statement that detects the end of sample index, but as the only way I know to clear an [rpole~] is a MESSAGE, our problem comes again : looping slightly delayed.
[...]

Nau

I didn't try this yet but, how about using [poke~] object driven by a phasor? I read not long ago that it can be used to address tables with "audio speed" signals. Just a self brainstorming.
All the best.

Sumidero

[phasor~] ... ... how do you loop with that ?

I don't see what the problem is? You can easily loop several samples of the same (beat) length with a single phasor. Calculate the phasor's freq using the intended bpm. Beyond that, if you want to use a one-bar sample with a 2-bar one and a 4-bar one; use a phasor whose period is four bars, then [*~] and [wrap~] it to get it to the ramp to the appropriate lengths. Am I missing something?

@nestor said:

[phasor~] ... ... how do you loop with that ?

I don't see what the problem is?

Indeed, now you tell me I think I said a stupid thing. Got too far in the late night

Thank you

Nau

Hi Architekt,

as this patch is part of your final year engineering project, maybe could you be interested in an antialiasing dissertation. I opened a topic about it here : http://puredata.hurleur.com/sujet-7208-table-lookup-antialiasing-sound-quality-preservation-strategy .

This is easy to implement, but needs 16x upsampling so it pushes cpu a bit, this is aprice to pay to preserves the quality of the sound. However I found that when you 'scratch' a file with antialiasing it introduces slight time distortion with respect to the non-antialiased scheme. This doesn't happen at constant speeds, but when transients in the command (speed) occur. This is very small, like 0.2% (but who can put a figure on it ?), and I never considered it a problem, as this deals with scratching and in this context I prefer sound quality to anything else.

When sound is scratched you can of course save it into a table and using [rpole~ 1 ], and superimpose markers that show time stretching induced by the command (I use to recall speed automation curves statically, not live). Just think about a strip of elastic fabric left free on a table. Draw the original waveform on it, and draw n divisions of equal size. Then stretch and wrinkel it as the automation goes...
Of course visualization is impossible to do when audio is playing. Sliders can show play head positions in either original and 'scratched' tables.

I use Maelstorm's [waveform.mmb], and it is a delight.

Nau

http://www.pdpatchrepo.info/hurleur/varispeed.png