• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Idle handling, just not grokking it.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idle handling, just not grokking it.


  • Subject: Re: Idle handling, just not grokking it.
  • From: Christopher Nebel <email@hidden>
  • Date: Thu, 15 Nov 2001 11:01:33 -0800

On Thursday, November 15, 2001, at 09:53 AM, Bill Briggs wrote:

I think you're talking about Chris Nebel's post (see below). In the post he indicated that even a single beep wouldn't be heard unless a delay was introduced, yet we get single beeps. Multiples are the ones that go missing.

You won't hear a beep if you try to beep just before exiting the program, but that's a different problem. This one is something else -- beep n appears to only beep once. I did a quick experiment, and it looks like the problem is that Mac OS X is too bloody fast.

"beep" calls the system routine SysBeep, which has played the sound asynchronously ever since -- um, at least System 7, I think. (They realized that otherwise, the beep prevented you from doing anything else while it was playing -- a major liability if your beep is more than a few tenths of a second long.) That means that SysBeep returns immediately, and "beep" goes and calls it again for the second beep, etc. On Mac OS 9 with a sufficiently fast machine (or a sufficiently long beep sound) you can hear the beeps overlaying each other a bit. Now enter Mac OS X: SysBeep returns so fast that all the beeps play almost exactly over each other, so it sounds like there's only one. If you throw enough in, you will hear them spread out -- try "beep 2000".

What you need to do is add some time between the beeps. "Delay" only takes an integral number of seconds (gotta fix that), and one second is too long, so you have to add a short do-nothing loop. On my machine (a 500MHz PowerBook G3), this works pretty well:

repeat 5 times
beep
repeat 50000 times
2 + 2
end repeat
end repeat

I'd be tempted to call this correct behavior, but it's too perverse, so I'll write a bug on it.


---------- reprint of earlier post ----------

There's an architectural design point that makes it difficult to write a script that beeps as its final action. The difficulty is that sound output is owned by the process itself, so if it plays an asynchronous sound (which "beep" always does) and immediately terminates, the process, and therefore any sound output it called for, is destroyed before you ever hear anything. You can see the same thing with osascript:

osascript -e "beep" # the sound of silence...
osascript -e "beep" -e "delay 1" # now it beeps!


  • Follow-Ups:
    • Re: Idle handling, just not grokking it.
      • From: Bill Cheeseman <email@hidden>
    • Re: Idle handling, just not grokking it.
      • From: Christopher Nebel <email@hidden>
References: 
 >Re: Idle handling, just not grokking it. (From: Bill Briggs <email@hidden>)

  • Prev by Date: Re: Script Menu and "front" property
  • Next by Date: Activating an Acrobat Plug In
  • Previous by thread: Re: Idle handling, just not grokking it.
  • Next by thread: Re: Idle handling, just not grokking it.
  • Index(es):
    • Date
    • Thread