🚀 go-pugleaf

In article <3271@jhunix.HCF.JHU.EDU> barrett@jhunix.UUCP (Dan Barrett) writes:
>If the "beep" sound is long, should it (a) restart as it receives each ^G,
>(b) overlap itself, using the other audio channels, (c) ignore ^G's that
>occur while a previous ^G is still playing, (d) play them one right afterf
>the other, with the end of one sound going into the beginning of the next?

One of my favorite terminals has a 4-bit counter.  When a Control-G arrives,
it increments the counter, maxing out at 15.  Whenever the counter is
nonzero, it triggers a bell circuit that outputs a "bong", then a short
period of silence, then decrements the counter.  The end result is that two
consecutive ^G's produce two distinct bongs, instead of one continuous
tone.  (I hate terminals that cut the first tone short when the second one
comes along.)  With this hardware "multitasking" the terminal can print
and beep at the same time.

On the Amiga, something like this would allow a program that has requested
two or more bells to exit (RemTask) before the tones were complete, and
do so without causing a guru.  I.e., ReplyMsg when the counter is incremented
instead of after the requested audio sample is done.  The BEEP task can take
its own sweet time in getting around to playing the sample and decrementing
the counter, without holding up the requesting task.

A BEEP task really needs only 3 functions: 1) increment the counter (which
triggers a beep (eventually)), 2) reset the counter and abort the current
audio sample (to stop the cacophony), and 3) commit suicide (after freeing up
all resources).
-- 
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com
McDonnell Douglas FSCO  | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21    | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"