spinning-ball hang

    Jun 01 2006 | 7:12 am
    I don't know if this is even a sensible question, but is there anything special about a spinning-ball hang vs. Max quitting? I'm just wondering whether it might be possible to narrow down my bug search by understanding a little better what's special about a hang. As I understand it, the spinning-ball is just OS X giving an app time to complete a task. But what is an actual hang? Is there any all-purpose answer? Are there any types of routines I should look at if the app is hanging?
    Thanks in advance for any thoughts.

    • Jun 01 2006 | 10:08 am
      okay, I think I've tracked it down... I assumed it must have been some of my nasty java, but it looks like it's actually sflist~ gagging on too many preloads.
      So, given that there's no way for one to know when sflist~ has succesfully preloaded a sample, and the samples are all over my audio HD, how can I know exactly when it's safe to attempt another preload? (hint, hint... How a bang from sflist~ when a sample is preloaded; kind of like buffer~??? mmmm... nice!)
    • Jun 01 2006 | 11:22 am
      If you're on tiger, check the developer tools on the apple website, look for "spin control" (I think it's in the CHUD package) It does exactly what you're looking for.
      For your preload problem, maybe something like this can help
      MaxSystem.deferlow(new Executable() { public void execute() { // one preload } }
    • Jun 01 2006 | 6:15 pm
      Already there. That's what the outlet does.
    • Jun 02 2006 | 7:31 am
      hmmm... that would be good to include in the Docs. Maybe my pdf is old(??). I'll check. Didn't/don't see anything in the help file either.
      I did see the comment about "cue reporting" on the outlet, but I think I imagined it was reporting the currently playing cue.