Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!jhunix!barrett
From: barrett@jhunix.HCF.JHU.EDU (Dan Barrett)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ^G in WorkBench 1.4
Message-ID: <3271@jhunix.HCF.JHU.EDU>
Date: 10 Nov 89 19:12:30 GMT
References: <3742@altos86.Altos.COM> <1159@maestro.htsa.aha.nl> <3260@jhunix.HCF.JHU.EDU> <4518@sugar.hackercorp.com>
Reply-To: barrett@jhunix.UUCP (Dan Barrett)
Organization: The Johns Hopkins University - HCF
Lines: 24

>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.

In article <4518@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>Why? A sample is a sample. If I want the beep to have Tweety-Bird saying "Paw
>Puddy-tat faw down" that's my business.

	Mainly to make the software a little idiot-proof.  I have seen
plenty of programs that allow multiple control-G's to get sent quickly.
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?

                                                        Dan

 //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett     -      Systems Administrator, Computer Science Department |
| The Johns Hopkins University, 34th and Charles Sts., Baltimore, MD  21218 |
| INTERNET:   barrett@cs.jhu.edu           | UUCP:   barrett@jhunix.UUCP    |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | BITNET: barrett@jhuvms.bitnet  |
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////