synchronise 2 metro in a same patcher


    Jan 06 2008 | 10:00 am

    • Jan 06 2008 | 11:21 am
    • Jan 06 2008 | 12:16 pm
      like mikhail said
    • Jan 07 2008 | 1:46 am
      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~.
    • Jan 07 2008 | 3:52 am
      [setclock] is your friend !
      fxw
    • Jan 16 2008 | 3:45 am
      Is this Solution is the best for accuraty the tempo?
      max v2;
      Thanks for your're answer
      Nicolas
    • Jan 16 2008 | 3:28 pm
      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
      www.timara.oberlin.edu/GaryLeeNelson
    • Jan 16 2008 | 6:05 pm
      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.
    • Jan 16 2008 | 6:45 pm
      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
      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
    • Jan 16 2008 | 7:31 pm
      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
    • Jan 16 2008 | 9:16 pm
      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
      www.timara.oberlin.edu/GaryLeeNelson