[PD] "musical" timing, something like Max´s "metrical timing Transport" and [metro 16n]

[Ingo]

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 at 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