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