Xref: utzoo comp.sys.mac.hypercard:3099 comp.sys.mac.programmer:12125
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.hypercard,comp.sys.mac.programmer
Subject: Re: play/beep problems
Message-ID: <10033@hoptoad.uucp>
Date: 3 Feb 90 23:09:15 GMT
References: <9895@hoptoad.uucp> <1935@cbnewsk.ATT.COM> <16286@boulder.Colorado.EDU> <9916@hoptoad.uucp> <16372@boulder.Colorado.EDU> <9960@hoptoad.uucp>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 55

OK, so I got a copy of HyperCard 1.2.2 because everyone told me the
problem is fixed there.  Well, it's fixed in its worst manifestation,
but it's not fixed well or fixed completely.

Thanks to the poster who traced his own HyperCard 1.2.2 and reported
the following (which I've confirmed).  The "solution" is that the
SysBeep trap is tail patched.  The patch gives an immediate command
with value 102 and zero arguments, then a normal command 3 (quiet),
then a normal command 101, then calls the old SysBeep, then gives a
normal command 100.  All three commands 100, 101, and 102 are
undocumented; all are given with param1 and param2 as zero.  Somehow,
they seem to reset the channel state.  Anyone knowing exactly what
they do, please let us all in on the secret.

So, the sequence of events I gave originally will not plug the channel
on a Mac Plus or Mac SE running HyperCard 1.2.2 and System 6.0.2 or
up.  That's nice.

However, this "solution" still leaves a single sound channel open all
the time, and similar bad things can happen.  For instance, if
SuperClock chimes the hour, or some other INIT plays a sound, then the
HyperCard sound channel still gets clogged and won't play until you
either make HyperCard beep (which reinitializes the channel) or switch
to another application and back in MultiFinder (which gives the same
undocumented commands to reset the channel).  This is not good; it's
perfectly legitimate for an INIT to play a sound in response to some
event.

The other problem is that you still can't write an XCMD that plays a
sound by calling the Sound Manager, which obviously is something an
XCMD should be able to do.  Such an XCMD will step on the HyperCard
sound channel and give the usual results -- sounds will not play until
you make HyperCard beep or you switch application layers under
MultiFinder.  An XCMD can always send a "play" message, but this does
not necessarily run fast enough or give enough reporting information to
provide precise control of sound during rapid animation (a capability I
need for a current project), or give the desired functionality of the
XCMD, which might be a sophisticated synthesizer.  The XCMD can't give
the undocumented commands itself because it has no way of getting at
Hypercard's sound channel.  And yes, I have verified that such an XCMD
will clog the channel; neither of these problems are speculative.

Why, oh why, oh why oh, couldn't they have just followed the rules?  I
don't see how it could be such a wide-ranging code change just to
switch from single-channel-always-open to one-channel-per-sound.
Though I haven't seen the source code, this seems like one of those
two-hour changes.  Instead they chose to continue to break the rules of
the Sound Manager, with predictable consequences, and to add to that a
breaking of Apple's compatibility guidelines by including a tail
patch.  Heavy sigh.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Every institution I've ever been associated with has tried to screw me."
	-- Stephen Wolfram