metro stops
Hi
Has anybody already had metro objects suddenly stopping when it seems there is no reason (cpu not that high, even on activity monitor)?
It happens to me since I changed my powerbook G4 to a MacBookPro.
It will also happen on a Mac mini. Maybe an Intel processor issue ?
It seems to me that the hotter the processor is, the faster it happens.
I must precise that this problem only rises when both overdrive and scheduler options are on, which is required by most of my patches, and that the metro objects are running at high rates (33 ms maximum).
Thanks,
Joseph
I know this is a bit of a huge thread resurrection, but something similar has been happening to me lately. Some of my shorter metro objects would randomly stop, no rhyme or reason. I stopgapped a solution by having a longer (1000) metro re-starting the shorter ones, but that's really not ideal at all.
In addition, I have some Spectroscope~ and Meter~ objects that also seem to like to halt. I can get them going again by opening their help files (which is extra strange), but they usually stop again shortly after.
I'm not certain if it has anything to do with being in overdrive mode, either - I've seen it happen both ways.
OK, looking more through the archives, it seems this problem has existed for something like 8 YEARS. And nobody's discovered the issue? It's still happening in Max5, which is a little surprising, honestly.
Can we perhaps each list what we DO know might be causing the problem, all in one place?
What I know: It doesn't seem to be affected by overdrive/audio interrupt settings.
Changing the I/O Vector settings around can help, but it's never something simple like 'Make the settings larger.' It usually seems to be something like 'Make it smaller, then return it to the normal value.' I left my patch running overnight and it still cropped up when I checked it in the morning, though.
Could it have something to do with merely overloading the scheduler? I'm sure I have tons of metro and 'constant-output' Max objects, perhaps it has to do with too many of them piling up into the same scheduler vector?
Platform? Max version? OS version? Max settings?
Sequence to reproduce, perhaps?
Customer support people hate playing 20 questions.
If one cannot generalize then providing specifics
for *your* situation is the way to go.
Yeah, I know that it's annoying when there's no specifics, trust me. but it seems that the problem is cropping up on any range of systems (mostly macs?) with varying amounts of complexity in the patches. Anyway, here's my system stuff:
Platform: Intel Mac
System: 8 Core 3Ghz Mac Pro
Max Version 5.0.3 (I haven't upgraded yet, I'm trying to avoid it until I'm done with this patch. i'd rather not have NEW problems cropping up!)
Max Settings don't seem to affect it much at all, i've toyed with everything, scheduler settings, DSP stuff, it always comes back up - though it takes longer to happen with:
Smaller sample rate in the DSP settings
Larger IO Vector Size/ Sample Vector Size
Higher Queue and Poll throttle settings
No idea how one would reproduce it, it just started happening recently. My patch is hideously complex, though (At it's core it's Noboyasu Sakodna's Granular2.5 on 60 different kinds of steroids)
The max patcher itself is about 2.8 megs, multiple subpatchers (with subpatchers themselves), sends/receives going numerous direction and multiple sublevels into subpatchers, etc. With a compressed copy sent into textedit, it is 174 8.5x11 pages long.
My current solution for MOST of the problems (Metros seem to work now, any MSP object that has to poll a signal to output a Max signal still screw up) is to have a metro driving a metro driving a metro. This seems... counterintuitive (a 30 second metro driving a 1 second metro driving a 5ms metro, all just to make sure the 5ms one doesn't die).
Something else useful, here's a list of all the externals used in the patch:
Fredrik Olofsson's f0.smooth, f0.auto_scale, f0.distance
Joshua Kit Clayton's hr.wave, hr.plus, hr.times, hr.phasor, hr.play
Stefan Tiedje's St.lice
If you can get your patch to the point where it is self contained, in other words, contains all the externs and abstractions needed to run it, we'll try and reproduce.Please include CLEAR instructions on how you are getting to the problem, then send it in to support.
Bonus points are awarded for us not having to add anything to the Max search path, or click things in more than one window, unless of course these moves are part of the actual problem.
:)
-A
OK, now it's gotten extra-strange. In my built application (it's been running for about ten minutes, now), the Meters and metros haven't died yet.
I opened the patch up in Max5, with the application version runninng as well, and the editable patch has had the meters freeze almost instantly.
Which means... this MAY be a non-issue. If everything runs fine standalone, I'm not too worried about having to reset thing a lot on my own when building - it becomes merely an annoyance, instead of a real problem.
Still, I wonder why the standalone version doesn't have this glitch? What's different between the Max5 Runtime and Max5?
mushoo schrieb:
> I opened the patch up in Max5, with the application version runninng
> as well, and the editable patch has had the meters freeze almost
> instantly.
Is the indication freezing meters~? I have non reproducible, but purely
cosmetic, freezing meters and I believe also scope~s. They stop moving,
but all audio is running normal. Audio on/off resets them.
I have no way to determine how this is triggered, thus no bug report yet.
I Do never had a metro problem though, but maybe because I would avoid a
5 ms metro under any circumstance... (If it needs to be that exact, I'd
do all in the audio domain.)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
The main indication is the freezing meters/spectroscopes, yes. However, I have a (now 5ms) metro driving a series of random number generators, for a pitch-random-per-grain function, and after a while it's possible to hear that the randomization has stopped, and each grain is locked to whatever pitch it was at when the metro froze.
The metros driving metros workaround I'm using seems to at the least stave off the problem for a couple hours or so, which is better than every couple minutes. I've given the latest version to my tester, as a built application (which seems to NOT suffer from the freezeups) so I guess I'll wait and see if he notices anything.
Quote: MuShoo wrote on Mon, 11 August 2008 20:26
----------------------------------------------------
> The main indication is the freezing meters/spectroscopes, yes. However, I have a (now 5ms) metro driving a series of random number generators, for a pitch-random-per-grain function, and after a while it's possible to hear that the randomization has stopped, and each grain is locked to whatever pitch it was at when the metro froze.
----------------------------------------------------
5ms metros are, IME, dicey.
I would an MSP object, for instance an [lp.frrr~ 200]. If you insist on stock objects, you can probably cobble something with noise~ and sah~.
Lp.frrr~ is part of the Litter Pro Bundle. More information at the URI below.
Hope this helps,
Peter
Hi,
I believe this whole problem is from scheduler overload. I have had it on many occassions once a patch becomes complex. It occurs when there is a lot of control information being passed around (changing parameters with a metro every 10 ms. for example), more or less regardless of cpu load from DSP, I think.
1. meter~s stop (scope~s too, I think).
2. timed scheduler events stop: metro, qmetro, delay, also peakamp~.
I have reported these problems to Cycling74 but had little response.
The really frustrating thing is that there's no way of debugging, since there is no indication in Max of scheduler load and no way of knowing which objects are contributing to it.
The only solution I have found is to drastically simplify the patch. For my latest piece, I set aside about 80% of what I had developed and everything worked perfectly...
Good luck,
Ben
One of the things I've been doing to assuage the problem is to only have a small number of metros. Say I've got 8 drunk objects, instead of each having it's own metro, they all share the same one - if I need to toggle one of them off, it gets a gate betweeen itself and the metro send.
It does seem to be some sort of scheduler overload that max doesn't recover gracefully from.
Hi MuShoo,
Sure, yes, cut down on the complexity, cut down on the control information, cut down on the graphic displays, etc. But how do you know what and how much to cut down? Pure guesswork...
BTW, I forgot to mention another symptom of this general problem: sometimes messages will disappear. I had this occur regularly in a patch a couple of years ago. I could confirm that messages were being generated but that they did not arrive at their destinations. In at least one case, a message generated by some kind of a machine (patch) would not arrive at its destination, while the same message produced by a mouse click would. This of course not consistantly, but regularly, depending on how much other stuff was going on at the same time.
When sheduler load is high, other objects that produce control information (bang) from signals (like peakamp~, which I mentioned) will also stop.
The conclusion - and this comes from years of using and teaching Max/MSP in a wide variety of situations - is that beyond a certain level of complexity, Max (not MSP) becomes unpredictable and unstable. Hence unreliable. Hence unusable in a concert situation.
The problem is that there is no way of knowing where that "threshold of complexity" lies, what it consists of even, how close you may be to it in any given patching situation, or what to do when you find that you have gone beyond it.
Otherwise, Max is beautiful...
Ben
I can second the 'mesesages dropping' symptom, too - I was working on a message-heavy MIDI controller patch recently, and whenever scheduler load got too high (IE putting a metro at 1), all midi messages would just stop being sent. It was bad enough that the only fix was to close and reopen the patch.
If you have a clearly commented, self contained patch which demonstrates this dropping of messages we would certainly like to see it.
-A
Quote: thigpen@u.washington.edu wrote on Sun, 24 August 2008 22:29
> The conclusion - and this comes from years of using and teaching Max/MSP in a wide variety of situations - is that beyond a certain level of complexity, Max (not MSP) becomes unpredictable and unstable.
yes, I feel the same way.
>Hence unreliable. Hence unusable in a concert situation.
hmm hmm, been there.. (of course I should just learn to code better, or that's what they say - but wasn't max supposedly perfect for people that don't like becoming code monkeys?)
> The problem is that there is no way of knowing where that "threshold of complexity" lies, what it consists of even, how close you may be to it in any given patching situation, or what to do when you find that you have gone beyond it.
true
> Otherwise, Max is beautiful...
Yes! And since 5 it has gotten even better (haven't upgraded yet though - no rush - but I will eventually.)
I find myself thinking of max more and more as a platform for quickly doing a) simple things, and b) protoyping. It is also great of course for teaching things like sound synthesis.
So I like to make small, relatively simple patches for performances with (technically) relatively simple electronics, and to use it as a sort of sketch book. Quickly cobbling together ideas, for testing and experimenting further.
One monster all-I-could-ever-want-for-any-electronic-music-context-performance-patch is just lunacy, if you ask me.
When things get too complex things might not work, might not be efficient enough, or might get generally unmanageable. Of course, sometimes(!), things just sound better in other apps.
Anything seriously granular just *screams* supercollider, if you ask me. You could even control it from max over osc.
And I agree with Stefan that a 5 ms metro is not a very viable option in any(!) case. Can't you do something with edge? Hook it up to the amp envelope? As soon as the grain envelop is not equal to zero anymore you get a bang to generate new parameters for the next grain, or something along those lines?
I repeat (in case of any religious fanatics reading this) Max is great and nice. But it has it's limitations, and therefore its uses. Like other programs have too.
I wouldn't use C++ and Xcode to teach sound synthesis. But I wouldn't build a commercial synth using max/pluggo either. Things like that, ya know..
regards,
kjg
While we're waiting for something sufficiently clear
that Andrew and his pals can reproduce and come up with
solutions....
Some persons have found the following four questions
to be worthy as sources of contemplation.
I'm sure that many of the posters here would never
fall for such simple snares, of course. This is for
everyone else. You would be amazed at the number of
"serious" Max programmers who don't really ask themselves
questions 2 and 3 with any regularity.
Why do you need multiple metronomes?
Why aren't you using change objects to reduce bottlenecks?
Why do you think the metronome needs to be running at that speed?
Are you allergic to data thinning?
Why wouldn't you do this at audio rate?
A consequence of the ease with which one can prototype
using Max is that lots of people never get beyond "good enough"
when it comes to thinking about solutions that work with their
specific ideas/applications. While I strenuously avoid teaching
beginners that there is only one way to do things, there is a
sense in which some solutions *are* better than others in
some circumstances.
Much of the time, the answers to 'Do you need the metro running at that speed' and 'Why aren't you doing this at audio rate' are the same: You don't. Much of the time metro's work fine anywhere above 50ms, and it's unnoticeable.
Sometimes though, there's gotta be a reason for a quick metro that's not audio rate. Other wise, why have metros capable of going down to 1ms? Or snapshot objects?
One of the things I'd been using a quick metro for (and discovered I didn't really need it to be overly quick) was to generate random values for a frequency of a Phasor. These would be sampled and held for whenever a playback loop was finished - but, the playback loop has a minimum width of 5 ms. Using a metro slower than that results in a pitch that doesn't shift consistently, often taking two loops or even more before a new frequency is generated.
I'll admit, I had other more important concerns with the patch gnawing at me, and didn't really try to figure out a way to do it all in the audio realm. However, I don't believe there's an 'expr' object in MSP, which would also lead to a much more convoluted patch design.
I'm not trying to be defensive or anything, just give my reasoning for using a quick metro.
I have taken to the idea of using one metro for anything that needs a metro. Usually I'll split it into a couple metro speeds, having one at 1000, one at 200, and one at about 50-55.
The other issue is that trying to come up with something clear and precise for Cycling support is that the problem only seems to arise in extremely complicated patches with lots and lots of stuff going on.
The current version of my patcher that has metro problems is about 7 megs, just as a .maxpat.
Again, strangely enough I experience none of the metro problems in a built application running with it's own copy of the Max Runtime. It just makes building and prototyping a bit more frustrating.
Quote: MuShoo wrote on Mon, 25 August 2008 03:52
----------------------------------------------------
> One of the things I'd been using a quick metro for (and discovered I didn't really need it to be overly quick) was to generate random values for a frequency of a Phasor. These would be sampled and held for whenever a playback loop was finished - but, the playback loop has a minimum width of 5 ms. Using a metro slower than that results in a pitch that doesn't shift consistently, often taking two loops or even more before a new frequency is generated.
I'd rather do this than using a 5ms metro.
Offset and scale to taste, of course.
Quote: MuShoo wrote on Mon, 25 August 2008 03:52
----------------------------------------------------
> I have taken to the idea of using one metro for anything that needs a metro. Usually I'll split it into a couple metro speeds, having one at 1000, one at 200, and one at about 50-55.
Well, you don't really need multiple metro objects. Or any, for that matter. Try running things from one phasor and a bunch of rate~ objects. It might just solve your problem.
> The other issue is that trying to come up with something clear and precise for Cycling support is that the problem only seems to arise in extremely complicated patches with lots and lots of stuff going on.
Yes, but if you find yourself wanting to run patches this big and/or complicated, doesn't it make sense to try to run them as solidly and tightly programmed as possible? Of course you can take a metro down to 5 ms every now and then when experimenting. But doesn't it make sense to replace it with a more accurate and stable solution to generating numbers when you decide to use it in a performance patch *at this speed*?
And of course, while you are at it you might as well add a change object here an there, take out any redundant number boxes and UI elements etc.
The prototype/sketch moment is gone. Now your algorithm needs to be solidly implemented.
> The current version of my patcher that has metro problems is about 7 megs, just as a .maxpat.
With a patch this big I wouldn't rely on any scheduler based timing anyway, especially not when I'm having issues that seem to come from overloading the scheduler queue.
Seriously, you either simplify the patch radically, or you go signal rate for those fast pulses.
And you generally streamline things, thin out data flow, use trigger objects to assure order of execution etc. You can't expect anything big to run properly without these basic safety measures and optimizations.
You will probably not manage to reproduce this in a patch with 10 objects or less. Which means those metros run fine when used sensibly.
What are you trying to do anyway, land your macbook on mars? :)
"What are you trying to do anyway, land your macbook on mars? :)"
Crap, someone figured it out!
I've actually only recently gotten the thing 'feature complete' which means I'm beginning to go back and clean up and streamline everything - I definitely like that phasor~/rate~ idea and will have to experiment a bit.
First thing I"m doing is making all the grains based in a single poly~ object with multiple instantiations, instead of 8 discrete grains - it's slooooooooooooow.
All I really have to add to this right now is that I have had this
issue at times too. I have a specific patch right now that it happens
to occasionally, and if I get time soon I will attempt to simplify it
and send it over to the appropriate parties.
On Apr 15, 2008, at 5:18 AM, joseph wrote:
> Has anybody already had metro objects suddenly stopping when it
> seems there is no reason
barry threw
Media Art and Technology
San Francisco, CA
Work: 857-544-3967
Email: bthrew (at) gmail (dot) com
Web: www.barrythrew.com
Hi,
Andrew, thank you for asking for example patches. Unfortunately(?), I have nothing misbehaving at the moment...
Barry, I hope you have the time to do this. The difficult thing, as MuShoo mentioned, and as I have found repeatedly, is that when you try to isolate the problem it tends to go away.
Simply deleting some of the rest of the patch, things that work fine and have no communication with the malfunctioning part, can cause the malfunctioning part to work exactly as it should. This is why I believe the problem is linked to overall scheduler overload rather than to any specific objects or patching techniques.
Of course the suggestions by Gregory and others are important for reducing unnecessary complexity. However some of a patch's complexity is directly related to the sound result and to the clarity of the user interface. And until you reach the deadly "threshold of complexity," there is no reason to reduce the quality of the interface or the sound.
The problem is to know what this threshold is and why. For the DSP aspect of a patch, for instance, this is easy: you simply look at CPU use and cut back your patch accordingly. Without this kind of feedback for scheduler load (or whatever is at the root of these various bizarre behaviors), you can only resort guesswork...
Ben
barry threw schrieb:
> All I really have to add to this right now is that I have had this issue
> at times too. I have a specific patch right now that it happens to
> occasionally, and if I get time soon I will attempt to simplify it and
> send it over to the appropriate parties.
Its probably better to complicate it more to have the effect pop up. I
had no metro problems, but meter~s stop moving, though audio was fine.
It wasn't related to the complexity of the patch, but it seemed it was
related to what the computer was running elsewise. Maybe its possible to
reproduce this better with heavy load through other processes...
This patch though seems to be fine, if messages would miss, the coll
would contain some data, and certainly with for example 500
voices/metros the scheduler load is heavy:
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Hi Stefan,
This patch works fine for me. With 500 voices, I only have a bit of sluggishness when I turn the metros on and off (meter~ and toggle displays pause momentarily). Maybe symptoms will show up if I let it run continuously for a while.
Ben