I don't have an exact plan on how to do this without spending a lot of time finding the most effective way for getting the accurate sample positions. Maybe someone else has done that before.
However, in your particular case I would simply use midi clock from Ableton to sync the two. That looks much easier.
If your timing resolution is a maximum of 24 clocks per quarter note you don't have to do anything. Just trigger the Pd sequencer steps from the incoming midi clock.
If you need a higer resolution you could simply use a [timer], [cputime] or [realtime] to check the time from one clock to another and use that for subdividing for higher resolutions.
As in the example below with 120 BPM and 500 ms per beat each midi clock would have a resolution of 20.83333... ms (500 / 24). Using a resolution of 96 / quarter note you would have to divide this by 4 which comes out to 5.208333... ms.
(BTW, you can see already from the 5.2083333333... ms that the time you would have to enter for the metro would render a tempo that is slightly off!)
Syncing to midi clock would allow you to follow the tempo that is programmed in Ableton without having to worry about calculating the duration of each clock.
In Pd use [midiin] and [route] or [select] to get F8 (hex) = 248 (decimal). This is how to get the clock time of 96 clocks / quarter note:
[midiin] | [sel 248] | [t b b] | | [timer] | [/ 4]
Don't start interpolation until the second incoming clock (or provide a usable value before the first clock is coming in). I.e. when starting jump from 0 to 4 and then increase by 1.
Check out the midi specs for additional features like song pointer or midi timecode (which has nothing to do with midi clock), etc.
Ingo
Thanks Ingo, I must do the testing. In fact Im recordind de midiout to Ableton Live. "recalculating the position from time to time and resyncing to the absolute sample position might be necessary" how can I do this? did you see my patch? im working with something lika a "master" metro and a couple of "slave" metro objetcs that control a particular sequence.
2013/3/21 Ingo ingo@miamiwave.com:
I would assume that the rounding errors of metro would make the tempo
drift
after a while - depending on the speed.
Using the sample rate would be more accurate.
In order to insure that the rounding errors are not influencing the the position after a long time recalculating the position from time to time
and
resyncing to the absolute sample position might be necessary.
However, such an accuracy would only be needed if the music is to be
synced
to anything external like a DAW, I guess.
Ingo
If you mean milliseconds to bpm and vice versa:
minute = 60,000 ms;
bpm * ms = 60,000;
bpm = 60,000 / ms;
ms = 60,000 / bpm;
[120
| [t b f] | / [60000( | / [/ ] | [500 \Send this to the right inlet of [metro]. Then connect a counter [int ]/[+ 1]/[% 16] (outlet of the modulo to right inlet of [int]) to the outlet of [metro]. That then counts from 0 to 15 with an interval of 500 ms.
--Funs
Sorry I just noticed this shoul have been [midirealtimein] instead of [midiin]. Like this:
[midirealtimein] | [sel 248] | [t b b] | | [timer] | [/ 4]
Ingo
I don't have an exact plan on how to do this without spending a lot of time finding the most effective way for getting the accurate sample positions. Maybe someone else has done that before.
However, in your particular case I would simply use midi clock from Ableton to sync the two. That looks much easier.
If your timing resolution is a maximum of 24 clocks per quarter note you don't have to do anything. Just trigger the Pd sequencer steps from the incoming midi clock.
If you need a higer resolution you could simply use a [timer], [cputime] or [realtime] to check the time from one clock to another and use that for subdividing for higher resolutions.
As in the example below with 120 BPM and 500 ms per beat each midi clock would have a resolution of 20.83333... ms (500 / 24). Using a resolution of 96 / quarter note you would have to divide this by 4 which comes out to 5.208333... ms.
(BTW, you can see already from the 5.2083333333... ms that the time you would have to enter for the metro would render a tempo that is slightly off!)
Syncing to midi clock would allow you to follow the tempo that is programmed in Ableton without having to worry about calculating the duration of each clock.
In Pd use [midiin] and [route] or [select] to get F8 (hex) = 248 (decimal). This is how to get the clock time of 96 clocks / quarter note:
[midiin] | [sel 248] | [t b b] | | [timer] | [/ 4]
Don't start interpolation until the second incoming clock (or provide a usable value before the first clock is coming in). I.e. when starting jump from 0 to 4 and then increase by 1.
Check out the midi specs for additional features like song pointer or midi timecode (which has nothing to do with midi clock), etc.
Ingo
Thanks Ingo, I must do the testing. In fact Im recordind de midiout to Ableton Live. "recalculating the position from time to time and resyncing to the absolute sample position might be necessary" how can I do this? did you see my patch? im working with something lika a "master" metro and a couple of "slave" metro objetcs that control a particular sequence.
2013/3/21 Ingo ingo@miamiwave.com:
I would assume that the rounding errors of metro would make the tempo
drift
after a while - depending on the speed.
Using the sample rate would be more accurate.
In order to insure that the rounding errors are not influencing the the position after a long time recalculating the position from time to time
and
resyncing to the absolute sample position might be necessary.
However, such an accuracy would only be needed if the music is to be
synced
to anything external like a DAW, I guess.
Ingo
If you mean milliseconds to bpm and vice versa:
minute = 60,000 ms;
bpm * ms = 60,000;
bpm = 60,000 / ms;
ms = 60,000 / bpm;
[120
| [t b f] | / [60000( | / [/ ] | [500 \Send this to the right inlet of [metro]. Then connect a counter [int ]/[+ 1]/[% 16] (outlet of the modulo to right inlet of [int]) to the outlet of [metro]. That then counts from 0 to 15 with an interval of 500 ms.
--Funs