Metro/Tempo random stopping problem


    Jul 29 2006 | 1:33 am
    Ive been working on a rather complex live performance environment, and ive noticed every once and a while, the metronome will just stop banging and I have to turn it off and back on (just the metro). I want to make this patch fully generative, and run it as an installation, but I need to be able to trust that it wont just stop one day. How can i fix this strange problem.. Ive tried tweaking the performance settings.. is there something in particular I need to set?
    Thanks in advance.

    • Jul 29 2006 | 7:29 am
      Strange problem, could be something to doing with a scheduler error. Could try the external qmetro (available at http://jamoma.org/) or if you are working with jitter the built in qmetro. That will wait to send other bangs if nessisery and ensures that you're patch shouldnt flood. T
    • Aug 04 2006 | 8:02 pm
      I may be having a similar problem.
      I have four metros, two at 10 bps and two at 1 bps rates. It is not a terribly complex patch, but it does involve some serial I/O and eight channels of audio playback and mixing. After *approximately* 72 hours of nonstop operation, the metros quit banging. Not all at the same time. Simply turning them off and on makes them go for another several days.
      This patch is currently running in a museum in Tokyo, and I can duplicate the problem on a similar test rig at home. Max 4.5.7, Mac Mini running OS 10.4. I could update the OS but the weird thing is, the same system and patch ran in London for several months with no reports of this error.
      I would be extremely grateful for any clues.
      thanks!
      Alex Stahl
      On Jul 28, 2006, at 6:33 PM, Nicholas C. Raftis III wrote:
      > > Ive been working on a rather complex live performance environment, > and ive noticed every once and a while, the metronome will just > stop banging and I have to turn it off and back on (just the > metro). I want to make this patch fully generative, and run it as > an installation, but I need to be able to trust that it wont just > stop one day. How can i fix this strange problem.. Ive tried > tweaking the performance settings.. is there something in > particular I need to set? > > Thanks in advance. > -- > ~* www.Axiom-Crux.net *~
    • Aug 05 2006 | 9:01 am
      hello,
      I've seen similar 'clock death' with snapshot~ and qmetro, but could never narrow it down. None of the patches had anything special, only non-standard external was bark~(which likes to hang max if you close the patch while audio is on, at least on my pc). My workaround was easy, since none of these patches needed precise timing: I added few additional, very slow metros that restarted problematic ones every few seconds, and it worked nice(since they newer died at the same time).
      best, nesa
    • Aug 05 2006 | 4:38 pm
      Ive seen something similar with my patch with a single qmetro slaved to a setclock via clocker. If I stop the main clocker, I sometimes cant restart it or the qmetro. Ive never been able to narrow it down - but it happens very randomly and not often enough for me to have dealt with testing it. Re-instantiating clocker will sometimes do it, other times I actually have to re-open my main patch.
      No clue if its the same problem, but its very intermittent, and doesnt 'make any sense'...
      v a d e //
      www.vade.info abstrakt.vade.info
      On Aug 5, 2006, at 5:01 AM, nesa wrote:
      > hello, > > I've seen similar 'clock death' with snapshot~ and qmetro, but > could never narrow it down. None of the patches had anything > special, only non-standard external was bark~(which likes to hang > max if you close the patch while audio is on, at least on my pc). > My workaround was easy, since none of these patches needed precise > timing: I added few additional, very slow metros that restarted > problematic ones every few seconds, and it worked nice(since they > newer died at the same time). > > best, > nesa
    • Apr 16 2007 | 9:00 am
      I am having this problem as well with a currently running installation. It is a very big patch, but nothing to fancy, running on a dual-G5. Same symptoms on another dualG5 and my ibook. Basically I have a qmetro driving quite a few things, frame rate is always above 24 on the installation machine, but sometimes the metro just quits, but with mine all metros and qmetros quit. each and everyone of them (3) has to be restarted. One of the metros was only put in there with the hopes of restarting the main qmetro when it failed, so it is only banging every 2000ms.
      Also, when this happens the lcd audio meters freeze, but those do not restart without deleting them and recreating them. This is a terrible problem.
      OS is current, max 4.6.2 jitter 1.6.3b2
      Sometimes it happens after 20 minutes, sometimes it takes a few hours. I thought it might be happening while a new movie was being read, but I disabled all movie players and it still happens.
      Can anyone help?
      Christopher
    • Jun 02 2007 | 1:27 pm
      hello, i only found complaining mail on this issue so far in the list- archives . obviously it only happens on "some" machines respectively configs or...???
      is there anything that could be done to track this down? any system config that might be guilty?
      needless (?) to say that this is a realy bad and annoiing thing, in fact it makes max totally unreliable etc.
      my system: macbook, osx 10.4.8 maxmsp 4.6.3
      the issue is not there on several other machines i tested...
      best klaus
      ps, here is a patch that illustrates the issue:
      On Apr 16, 2007, at 11:00 AM, Christopher Overstreet wrote:
      > > I am having this problem as well with a currently running > installation. It is a very big patch, but nothing to fancy, > running on a dual-G5. Same symptoms on another dualG5 and my > ibook. Basically I have a qmetro driving quite a few things, frame > rate is always above 24 on the installation machine, but sometimes > the metro just quits, but with mine all metros and qmetros quit. > each and everyone of them (3) has to be restarted. One of the > metros was only put in there with the hopes of restarting the main > qmetro when it failed, so it is only banging every 2000ms. > > Also, when this happens the lcd audio meters freeze, but those do > not restart without deleting them and recreating them. This is a > terrible problem. > > OS is current, max 4.6.2 jitter 1.6.3b2 > > Sometimes it happens after 20 minutes, sometimes it takes a few > hours. I thought it might be happening while a new movie was being > read, but I disabled all movie players and it still happens. > > Can anyone help? > > Christopher
    • Jun 04 2007 | 7:01 pm
      Quote: nesa wrote on Sat, 05 August 2006 11:01 ---------------------------------------------------- > None of the patches had anything special, only non-standard > external was bark~(which likes to hang max if you close the patch while > audio is on, at least on my pc).
      ----------------------------------------------------
      That is almost certainly due to bark~ not calling freeobject() properly.
      DDZ has documented correct deallocation of MSP objects (which must be done in a particular order, otherwise *boom* guaranteed). There are numerous threads in the archive covering the correct procedure. You should point out the problem to bark~'s developer.
      -- P.
    • Jun 06 2007 | 9:14 am
      >>obviously it only happens on "some" machines respectively configs >>or...???
      I've tried running your patch on my Windows laptop, 1.7GHz, with the built-in "audiointerface ;-)" at 98 - 100% CPU, and it is running for mor than 1 hour now without problems...
      So it seem's to happen only on some macines or configs...
      Gerald
    • Feb 16 2009 | 5:43 am
      I am having this exact same problem right now. Sometimes one, sometimes all, of my metros will just stop banging. They will not get toggled, they will just stop, period. I am running a patch that takes about 2% of my CPU's power. One can imagine just how frustrating this is. I am not using any externals in my patch, so i couldn't see it being a result of improper memory deallocation.
    • Feb 16 2009 | 7:38 am
      I identified what I believe to be the same problem back in October 2008. Look at the bottom of this thread for an example. Joshua knows about this, and I hope it is fixed in the next incremental.
      best, Zachary
    • Feb 16 2009 | 12:22 pm
      { "boxes" : [ { "box" : { "maxclass" : "ezdac~", "patching_rect" : [ 217.0, 403.0, 45.0, 45.0 ], "id" : "obj-7", "numinlets" : 2, "numoutlets" : 0 }
      } , { "box" : { "maxclass" : "inlet", "outlettype" : [ "int" ], "patching_rect" : [ 445.0, 169.0, 25.0, 25.0 ], "id" : "obj-3", "numinlets" : 0, "numoutlets" : 1, "comment" : "" }
      } , { "box" : { "maxclass" : "inlet", "outlettype" : [ "int" ], "patching_rect" : [ 333.0, 160.0, 25.0, 25.0 ], "id" : "obj-2", "numinlets" : 0, "numoutlets" : 1, "comment" : "" }
      } , { "box" : { "maxclass" : "button", "outlettype" : [ "bang" ], "patching_rect" : [ 345.0, 469.0, 15.0, 15.0 ], "id" : "obj-1", "numinlets" : 1, "numoutlets" : 1 }
      } , { "box" : { "maxclass" : "message", "text" : "120", "outlettype" : [ "" ], "fontsize" : 9.0, "patching_rect" : [ 372.0, 186.0, 32.5, 15.0 ], "id" : "obj-10", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "flonum", "outlettype" : [ "float", "bang" ], "bgcolor" : [ 0.866667, 0.866667, 0.866667, 1.0 ], "htextcolor" : [ 0.870588, 0.870588, 0.870588, 1.0 ], "fontsize" : 9.0, "patching_rect" : [ 397.0, 204.0, 35.0, 17.0 ], "id" : "obj-284", "triscale" : 0.9, "numinlets" : 1, "numoutlets" : 2, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "/ 240.", "outlettype" : [ "float" ], "fontsize" : 9.0, "patching_rect" : [ 397.0, 227.0, 40.0, 17.0 ], "id" : "obj-285", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "comment", "text" : "BPM", "fontsize" : 9.0, "patching_rect" : [ 442.0, 211.0, 30.0, 17.0 ], "id" : "obj-286", "numinlets" : 1, "numoutlets" : 0, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "loadbang", "outlettype" : [ "bang" ], "fontsize" : 9.0, "patching_rect" : [ 267.0, 190.0, 48.0, 17.0 ], "id" : "obj-270", "numinlets" : 1, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "toggle", "outlettype" : [ "int" ], "patching_rect" : [ 338.0, 222.0, 15.0, 15.0 ], "id" : "obj-271", "numinlets" : 1, "numoutlets" : 1 }
      } , { "box" : { "maxclass" : "newobj", "text" : "phasor~ 0.5", "outlettype" : [ "signal" ], "fontsize" : 9.0, "patching_rect" : [ 339.0, 320.0, 64.0, 17.0 ], "id" : "obj-272", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "t 0.", "outlettype" : [ "float" ], "fontsize" : 9.0, "patching_rect" : [ 377.0, 293.0, 24.0, 17.0 ], "id" : "obj-273", "numinlets" : 1, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "sel 1", "outlettype" : [ "bang", "" ], "fontsize" : 9.0, "patching_rect" : [ 377.0, 267.0, 32.0, 17.0 ], "id" : "obj-274", "numinlets" : 2, "numoutlets" : 2, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "t b i i", "outlettype" : [ "bang", "int", "int" ], "fontsize" : 9.0, "patching_rect" : [ 339.0, 242.0, 49.0, 17.0 ], "id" : "obj-275", "numinlets" : 1, "numoutlets" : 3, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "* 0.", "outlettype" : [ "float" ], "fontsize" : 9.0, "patching_rect" : [ 339.0, 294.0, 29.0, 17.0 ], "id" : "obj-276", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "abs~", "outlettype" : [ "signal" ], "fontsize" : 9.0, "patching_rect" : [ 342.0, 395.0, 31.0, 17.0 ], "id" : "obj-277", "numinlets" : 1, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "delta~", "outlettype" : [ "signal" ], "fontsize" : 9.0, "patching_rect" : [ 341.0, 374.0, 38.0, 17.0 ], "id" : "obj-278", "numinlets" : 1, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : ">=~ 0.001", "outlettype" : [ "signal" ], "fontsize" : 9.0, "patching_rect" : [ 342.0, 414.0, 57.0, 17.0 ], "id" : "obj-279", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "edge~", "outlettype" : [ "bang", "bang" ], "fontsize" : 9.0, "patching_rect" : [ 342.0, 434.0, 36.0, 17.0 ], "id" : "obj-280", "numinlets" : 1, "numoutlets" : 2, "fontname" : "Arial" }
      } , { "box" : { "maxclass" : "newobj", "text" : "rate~ 0.0625", "outlettype" : [ "signal" ], "fontsize" : 9.0, "patching_rect" : [ 341.0, 354.0, 71.0, 17.0 ], "id" : "obj-281", "numinlets" : 2, "numoutlets" : 1, "fontname" : "Arial" }
      } ], "lines" : [ { "patchline" : { "source" : [ "obj-280", 0 ], "destination" : [ "obj-1", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-271", 0 ], "destination" : [ "obj-275", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-275", 0 ], "destination" : [ "obj-276", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-276", 0 ], "destination" : [ "obj-272", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-272", 0 ], "destination" : [ "obj-281", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-281", 0 ], "destination" : [ "obj-278", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-278", 0 ], "destination" : [ "obj-277", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-277", 0 ], "destination" : [ "obj-279", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-279", 0 ], "destination" : [ "obj-280", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-275", 1 ], "destination" : [ "obj-276", 1 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-275", 2 ], "destination" : [ "obj-274", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-274", 0 ], "destination" : [ "obj-273", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-273", 0 ], "destination" : [ "obj-272", 1 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-284", 0 ], "destination" : [ "obj-285", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-285", 0 ], "destination" : [ "obj-276", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-10", 0 ], "destination" : [ "obj-284", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-270", 0 ], "destination" : [ "obj-10", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-2", 0 ], "destination" : [ "obj-271", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } , { "patchline" : { "source" : [ "obj-3", 0 ], "destination" : [ "obj-284", 0 ], "hidden" : 0, "midpoints" : [ ] }
      } ] }
      this seems to be a good way of keeping time. when i was using metro for a drum machine it would always fail keeping time but dont have any issues using this method. hope that of some use