Re: Idle handling, just not grokking it.
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!