#P button 246 178 15 0;
#P button 280 177 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 246 141 32 196617 sel 1;
#P toggle 246 113 15 0;
#P toggle 280 84 15 0;
#P newex 280 114 58 196617 metro 120;
#P connect 0 0 2 0;
#P connect 0 0 4 0;
#P connect 1 0 0 0;
#P connect 3 0 5 0;
#P connect 2 0 3 0;
#P window clipboard copycount 6;

fxw

max v2;
#N vpatcher 214 240 1012 794;
#P toggle 98 213 15 0;
#P window setfont “Sans Serif” 9.;
#P number 162 130 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 98 249 74 196617 clocker 1000;
#B color 5;
#P flonum 162 215 61 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 162 194 53 196617 * 60000.;
#P newex 162 175 31 196617 !/ 1.;
#P button 98 273 15 0;
#P comment 157 109 78 196617 Tempo in BPM;
#P comment 76 185 68 196617 Start / Stop;
#P connect 8 0 6 0;
#P connect 6 0 2 0;
#P connect 7 0 3 0;
#P connect 3 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 6 1;
#P pop;

Thanks for your’re answer

Nicolas

Set the tempo to 6.
Type 240 into the tempo number box at the top BUT wait until the bang at the
bottom fires. Press return to pass the 240 through. Note that the bang at
the bottom does not immediately begin firing at 240. It waits until 10
seconds pass (mm=6) before stepping off at mm=240. Short message, updates
to tempo do not take effect until the end of the current delay period.

On 1/15/08 10:45 PM, “Safnight” wrote:

>
> Is this Solution is the best for accuraty the tempo?
>
> max v2;
> #N vpatcher 214 240 1012 794;
> #P toggle 98 213 15 0;
> #P window setfont “Sans Serif” 9.;
> #P number 162 130 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P newex 98 249 74 196617 clocker 1000;
> #B color 5;
> #P flonum 162 215 61 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 162 194 53 196617 * 60000.;
> #P newex 162 175 31 196617 !/ 1.;
> #P button 98 273 15 0;
> #P comment 157 109 78 196617 Tempo in BPM;
> #P comment 76 185 68 196617 Start / Stop;
> #P connect 8 0 6 0;
> #P connect 6 0 2 0;
> #P connect 7 0 3 0;
> #P connect 3 0 4 0;
> #P connect 4 0 5 0;
> #P connect 5 0 6 1;
> #P pop;
>
>
> Thanks for your’re answer
>
> Nicolas

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

Otherwise: rule #1 for scheduling in Max is “use one master metro and subdivide everything else.”

That still leaves Gary’s beef w/metro & Co., which is a very real issue. OTOH, there are now surely existing patches that rely on metro’s latency when changing tempo.

I’ve written code for changing tempo that changes from extremely slow to extremely fast by doing the follow on receiving a tempo change:

1) Calculate proportion of inter-beat time remaining before next beat (deltaTRemaining)
2) Calculate multiply that by (deltaTNew/deltaTOld)
3) Cancel existing scheduled event and schedule a new event at the time calculated in step 2. Once that event occurs all following events are scheduled at intervals of deltaTNew (which by now is stored as an object member).

This is tedious but doable (it works effectively in lp.frrr~). However, to add this approach to metro it would, I think, also need to be a user flag to determine whether to use the old or the modified behavior in order to support backwards compatibility.

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

On1/16/08 1:05 PM, “Peter Castine” wrote:

>
> You may want to look at Eric Lyon’s paper “A Sample Accurate Triggering System
> for Pd and Max/MSP” and the related objects he’s released.
>
> Otherwise: rule #1 for scheduling in Max is “use one master metro and
> subdivide everything else.”
>
> That still leaves Gary’s beef w/metro & Co., which is a very real issue. OTOH,
> there are now surely existing patches that rely on metro’s latency when
> changing tempo.
>
> I’ve written code for changing tempo that changes from extremely slow to
> extremely fast by doing the follow on receiving a tempo change:
>
> 1) Calculate proportion of inter-beat time remaining before next beat
> (deltaTRemaining)
> 2) Calculate multiply that by (deltaTNew/deltaTOld)
> 3) Cancel existing scheduled event and schedule a new event at the time
> calculated in step 2. Once that event occurs all following events are
> scheduled at intervals of deltaTNew (which by now is stored as an object
> member).
>
> This is tedious but doable (it works effectively in lp.frrr~). However, to add
> this approach to metro it would, I think, also need to be a user flag to
> determine whether to use the old or the modified behavior in order to support
> backwards compatibility.
> –
> Peter Castine
> –
> Peter is in dire need of a new Facebook tagline. Not to mention a new .sig

my metro~ abhaXion, which is based on a phasor~ naturally doesn’t show
this problem. Frequency changes of MSP oscillators are immediate…

It has an additional BPM input by the way…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

On 1/16/08 2:31 PM, “Stefan Tiedje” wrote:

> Peter Castine schrieb:
>> That still leaves Gary’s beef w/metro & Co., which is a very real
>> issue.
>
> my metro~ abhaXion, which is based on a phasor~ naturally doesn’t show
> this problem. Frequency changes of MSP oscillators are immediate…
>
> It has an additional BPM input by the way…
>
> Stefan

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson