tim@hoptoad.uucp (Tim Maroney) (02/01/90)
In article <9916@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>So, if some skilled soul out there would check a more recent version of >>HyperCard than 1.2.1, trapping on the SndNewChannel call and seeing if >>it's called during the execution of a "play" command, we can find out >>if this bug has already been fixed, or if I should try to fix it >>myself. Actually, I've gotten an e-mail message from a kind soul who reported that SndNewChannel is still called only once in HyperCard 1.2.2, but the problem does not appear to still exist in that version. HyperCard does some cryptic munging of its channel in response to suspend and resume events in 1.2.1 that make it possible to restore the channel to full functioning by switching to another application and back in MultiFinder; presumably they put in the same reset code before beginning any "play" command in 1.2.2. I'll have to check it out. In article <16372@boulder.Colorado.EDU> rieman@boulder.Colorado.EDU (John Rieman) writes: >Why are you (of all people) still using 1.2.1 anyway? I don't go to computer stores very often; when I do, it's hard to get much attention, since I don't look like a businessman or a hippie.... >There are lots >of nifty new features in 1.2.2, some of which I couldn't do without. >For example: > lock/unlock screen [with visual effect ..., speed..., to image...] > select -- so you can select and move/delete an invisible object > show/hide picture > returnInField and enterInField system messages (to mark end of input) > foundChunk, foundField, and enhancements to the Find command > selectedChunk, Field, etc. > the option to use cursor keys when editing text in fields Actually, these are all in 1.2.1 as well, which is why I haven't really felt the loss before now. >and, as they say on TV, "minny, minny moore." Like the fix to this bug, apparently.... What other tidbits are in there? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"
tim@hoptoad.uucp (Tim Maroney) (02/04/90)
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
mjm@eleazar.dartmouth.edu (Michael McClennen) (02/05/90)
In article <10033@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > [ explanation of undocumented sound channel commands that hypercard issues ] >The XCMD can't give >the undocumented commands itself because it has no way of getting at >Hypercard's sound channel. Ah, but it can. The sound channels are organized as a linked list, with the most recently added first. The first field of a SndChannel record is a pointer to the next channel. If your XCMD allocates a channel, that field will contain a pointer to HyperCard's channel. You can then deallocate your channel, and use HyperCard's. Michael McClennen Dartmouth College Academic Computing
tim@hoptoad.uucp (Tim Maroney) (02/06/90)
In article <10033@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >> [ explanation of undocumented sound channel commands that hypercard issues ] > >>The XCMD can't give >>the undocumented commands itself because it has no way of getting at >>Hypercard's sound channel. In article <19138@dartvax.Dartmouth.EDU> mjm@eleazar.dartmouth.edu (Michael McClennen) writes: >Ah, but it can. The sound channels are organized as a linked list, with the >most recently added first. The first field of a SndChannel record is a pointer >to the next channel. If your XCMD allocates a channel, that field will contain >a pointer to HyperCard's channel. You can then deallocate your channel, and >use HyperCard's. Sure, if you don't mind depending on yet more undocumented behavior, and on certain assumptions (there is only one other channel, HyperCard's channel doesn't add any modifiers that make it unusable by you, etc.) which could easily cease to be true in the future. In short, this requires adding so much undocumented behavior that your own code is practically guaranteed to crash within a few years. Not that I don't appreciate the note -- it could be useful for some quick and dirty stuff. But the fact remains that HyperCard's sound channel behavior is a bug. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Gangsters would kidnap my math teacher, Miss Albertine, and I'd track them down and kill them one by one until she was free, and then she'd break off her engagement with my sarcastic English teacher, Mr. Richardson, because she'd fallen hopelessly in love with her grim-faced and silent fourteen-year-old savior." -- Nite Owl, in WATCHMEN by Alan Moore