Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!ucsd!ucbvax!EE.ECN.PURDUE.EDU!bevis
From: bevis@EE.ECN.PURDUE.EDU (Jeff Bevis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ^G in WorkBench 1.4
Message-ID: <8911120043.AA25075@en.ecn.purdue.edu>
Date: 12 Nov 89 00:43:02 GMT
References: <3271@jhunix.HCF.JHU.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Purdue University Engineering Computer Network
Lines: 19

In article <3271@jhunix.HCF.JHU.EDU>, barrett@jhunix.UUCP (Dan Barrett) writes:
>>In article <3260@jhunix.HCF.JHU.EDU> barrett@jhunix.UUCP (Dan Barrett) writes:
>>> 	Perhaps S:BeepSound would be required to be a one-shot sample
>>> with duration less than 0.5 seconds, or something like that.
>
>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
>after the other, with the end of one sound going into the beginning of the
>next?

If I had anything to say about it, the successive ^G's would pre-empt the
currently playing 'beep' and restart it...  options (b) and (d) are certainly
unacceptable, and (c) is not really the best.

+--------------------------------+--------------------------------------------+
| Jeff Bevis 		         | "But I don't like spam!"		      |
| bevis@en.ecn.purdue.edu	 | 	     Give me Amiga or nothing at all. |
+--------------------------------+--------------------------------------------+