synchronise 2 metro in a same patcher

Jan 6, 2008 at 10:00am

synchronise 2 metro in a same patcher

#35232
Jan 6, 2008 at 11:21am

#119916
Jan 6, 2008 at 12:16pm

like mikhail said

#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;

#119917
Jan 6, 2008 at 5:08pm

#119918
Jan 7, 2008 at 1:46am

You can also take the plunge into msp timing objects. Definitely recommended if you’re interested in accuracy. Phasor~ and rate~ would be two objects useful for your current situation. As a pre-MSP Max user, I’ve found it helpful to build a metro-like abstraction based on phasor~.

#119919
Jan 7, 2008 at 3:52am

[setclock] is your friend !

fxw

#119920
Jan 16, 2008 at 3:45am

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

#119921
Jan 16, 2008 at 3:28pm

This has the same problem as metro. Try this…

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

#119922
Jan 16, 2008 at 6:05pm

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.

#119923
Jan 16, 2008 at 6:45pm

Again, I’ll point to pulse by James McCartney and my own pulsemetro
available on my web page below. These were created to address the problems
with metro, counter and tempo.

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

#119924
Jan 16, 2008 at 7:31pm

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


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

#119925
Jan 16, 2008 at 9:16pm

Yes! I had forgotten metro~. Add it to my list of favorite tickers.

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

#119926

You must be logged in to reply to this topic.