Axiom-Crux

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?

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?

metrotempo-random-stopping-problem

Strange problem, could be something to doing with a scheduler error. Could try the external qmetro (available at 

 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.

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


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 

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 

I would be extremely grateful for any clues.

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 

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.

>
> 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  *~


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 

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).

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).

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 

> 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 

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'...

> 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

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.

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.

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.

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.

i only found complaining mail on this issue so far in the list- 

obviously it only happens on "some" machines respectively configs 

is there anything that could be done to track this down? any system 

needless (?) to say that this is a realy bad and annoiing thing, in 

fact it makes max totally unreliable etc.

the issue is not there on several other machines i tested...

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 

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

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

ps, here is a patch that illustrates the issue:


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


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 

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.

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).

>>obviously it only happens on "some" machines respectively configs

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

>>obviously it only happens on "some" machines respectively configs
>>or...???

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.

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.

https://cycling74.com/forums/index.php?t=msg&goto=158848&rid=0&S=6b165dde472bb5d07865f0623b39b244#msg_158848

            "box" :             {

                "maxclass" : "ezdac~",

                "patching_rect" : [ 217.0, 403.0, 45.0, 45.0 ],

                "id" : "obj-7",

                "numinlets" : 2,

                "numoutlets" : 0

                "maxclass" : "inlet",

                "outlettype" : [ "int" ],

                "patching_rect" : [ 445.0, 169.0, 25.0, 25.0 ],

                "id" : "obj-3",

                "numinlets" : 0,

                "numoutlets" : 1,

                "comment" : ""

                "patching_rect" : [ 333.0, 160.0, 25.0, 25.0 ],

                "id" : "obj-2",

                "maxclass" : "button",

                "outlettype" : [ "bang" ],

                "patching_rect" : [ 345.0, 469.0, 15.0, 15.0 ],

                "id" : "obj-1",

                "numinlets" : 1,

                "numoutlets" : 1

                "maxclass" : "message",

                "text" : "120",

                "outlettype" : [ "" ],

                "fontsize" : 9.0,

                "patching_rect" : [ 372.0, 186.0, 32.5, 15.0 ],

                "id" : "obj-10",

                "fontname" : "Arial"

                "maxclass" : "flonum",

                "outlettype" : [ "float", "bang" ],

                "bgcolor" : [ 0.866667, 0.866667, 0.866667, 1.0 ],

                "htextcolor" : [ 0.870588, 0.870588, 0.870588, 1.0 ],

                "patching_rect" : [ 397.0, 204.0, 35.0, 17.0 ],

                "id" : "obj-284",

                "triscale" : 0.9,

                "numoutlets" : 2,

                "maxclass" : "newobj",

                "text" : "/ 240.",

                "outlettype" : [ "float" ],

                "patching_rect" : [ 397.0, 227.0, 40.0, 17.0 ],

                "id" : "obj-285",

                "maxclass" : "comment",

                "text" : "BPM",

                "patching_rect" : [ 442.0, 211.0, 30.0, 17.0 ],

                "id" : "obj-286",

                "numoutlets" : 0,

                "text" : "loadbang",

                "patching_rect" : [ 267.0, 190.0, 48.0, 17.0 ],

                "id" : "obj-270",

                "maxclass" : "toggle",

                "patching_rect" : [ 338.0, 222.0, 15.0, 15.0 ],

                "id" : "obj-271",

                "text" : "phasor~ 0.5",

                "outlettype" : [ "signal" ],

                "patching_rect" : [ 339.0, 320.0, 64.0, 17.0 ],

                "id" : "obj-272",

                "text" : "t 0.",

                "patching_rect" : [ 377.0, 293.0, 24.0, 17.0 ],

                "id" : "obj-273",

                "text" : "sel 1",

                "outlettype" : [ "bang", "" ],

                "patching_rect" : [ 377.0, 267.0, 32.0, 17.0 ],

                "id" : "obj-274",

                "text" : "t b i i",

                "outlettype" : [ "bang", "int", "int" ],

                "patching_rect" : [ 339.0, 242.0, 49.0, 17.0 ],

                "id" : "obj-275",

                "numoutlets" : 3,

                "text" : "* 0.",

                "patching_rect" : [ 339.0, 294.0, 29.0, 17.0 ],

                "id" : "obj-276",

                "text" : "abs~",

                "patching_rect" : [ 342.0, 395.0, 31.0, 17.0 ],

                "id" : "obj-277",

                "text" : "delta~",

                "patching_rect" : [ 341.0, 374.0, 38.0, 17.0 ],

                "id" : "obj-278",

                "text" : ">=~ 0.001",

                "patching_rect" : [ 342.0, 414.0, 57.0, 17.0 ],

                "id" : "obj-279",

                "text" : "edge~",

                "outlettype" : [ "bang", "bang" ],

                "patching_rect" : [ 342.0, 434.0, 36.0, 17.0 ],

                "id" : "obj-280",

                "text" : "rate~ 0.0625",

                "patching_rect" : [ 341.0, 354.0, 71.0, 17.0 ],

                "id" : "obj-281",

            "patchline" :             {

                "source" : [ "obj-280", 0 ],

                "destination" : [ "obj-1", 0 ],

                "hidden" : 0,

                "midpoints" : [ ]

                "source" : [ "obj-271", 0 ],

                "destination" : [ "obj-275", 0 ],

                "source" : [ "obj-275", 0 ],

                "destination" : [ "obj-276", 0 ],

                "source" : [ "obj-276", 0 ],

                "destination" : [ "obj-272", 0 ],

                "source" : [ "obj-272", 0 ],

Metro/Tempo random stopping problem