>>perhaps the sound handles aren't locked, and they 'move' on you?<<

Oh, tsk-tsk, Bill, I did say I was locking them. (Interestingly, it didn't
become necessary to do so until code called for multiple sound handles--but
the effect of an unlocked sound handle is immediately & gratingly obvious, so
that was a _very_ early change!)

>>I suspect that somewhere in your sound-playing routine you're changing 

memory that shouldn't be changed <snip, snip> Regardless, I can pretty much
guarantee that your sound routine is branching off into "left field" and
overwriting memory <<

Or, for a nicer metaphor, flying right out of the ballpark and smashing the
window of a parked car, as happens at least once per season where I live. But
I hope you meant to say "sound-loading"--if things are going to go bad, they
will do so even if I remark out all references to actually _playing_ the in-
memory sound.

>>I use the sound _name_ rather than a resource id because I had trouble with
the SOUND command any way other than this<<

Oh, sure. The very first thing I tweaked when I started messing about with
Mel's SoundBuddy was changing over to named sounds--in my case just because
I've got so _many_ of the things, and they can't be numbered systematically
like PICTs. It goes:

CLEAR LOCAL
LOCAL FN loadNamedSound(soundname$)
  DIM err
  DIM tmphndl&
  CALL USERESFILE(soundResFile%)
'because the external resource files are so large (that's why they were 
'created in the first place) I route code to the specific file I need, and
then 
'point back at the main rsrc file (the compiled app) the rest of the time. 
'But the crashes also occur if I do a mockup of the program with sounds in 
'the compiled app, nothing external, or try it within FB which ignores
'external files.
  tmphndl& = FN GETNAMEDRESOURCE(_"snd ",soundname$)
'since I'm pointing at a specific rsrc file, I probably _could_ stay with
'GET1NAMEDRESOURCE, but didn't want to take any chances. Is there
'any way this choice might affect the handle? (doesn't _seem_ that way...)
  LONG IF tmphndl&
    err = FN HLOCK(tmphndl&)
'I once tried an expanded version of all my sound routines, asking it to 
'beep in the case of any error, but got no beeps
  END IF
  CALL USERESFILE(mainResFile%)
'reset to default file so app doesn't waste time searching Sound & Art files
'when it's looking for a string or anything else
END FN = tmphndl&
'sound handle is passed back to the FN that requested it, where it gets 
'plugged into the appropriate global. Since three of the handles are loaded 
'from within the same FN, but it's always just _one_ of the three that 
'acts up, we can pretty well rule out the question of something wrong 
'with any of the originating FNs.

One more thing occurred to me: would I get different results if I worked with
each  global handle _directly_ (backSound&(1) = FN GET... etc) instead of
working with a local & sending that back to the global? I don't mean, would I
get different empirical results if I tried it once, but would memory itself
behave differently?