CompuServe Messages

Chester: I have had the same problems. Apparently, at this time, the AmigaVision SMUS playing routines are not as robust or flexible as they might be. I suspect that this will be fixed rapidly, tho that is a guess, not based on anything more than common sense. The way I get around this (i.e. when I come accross a SMUS file that AmigaVision itself won't play correctly) is to use multitasking to have a separate player utility run the music in the background. I have used by DPLAY (a player designed to handle DMCS generated SMUS files with DMCS instruments) and PLAY (a player designed for Sonix SMUS and instrument files). They work just fine when launched from an EXECUTE icon as CLI commands. I normally use "runback" to do this. The only thing that is a bit kludgy is if you want to permit the user to turn them off. It can be done by issueing a BREAK cli command through another EXECUTE icon. However, you must know the number of the process which is running the DPLAY or PLAY code. The way you can find this out is to set up your AV script so that the music is running (make sure everything prior to that point is also going). Then go to a cli and type the STATUS command. In the application I do this in, the STATUS command will indicate that process 2 is being used. So, I have the "stop music" button issue a "BREAK 2 ALL" cli command, and the music will stop. Here's why it's a kludge — the only way that the same process number will be used by AV is if _everything_else_your_system_has_or_is_doing_is_exactly_the SAME at the time. So, NOTHING new or different can be up and running in the background, or the number of the process being used to run you player utility will probably be different. I hear that AmigaDOS 2.0 let's processes have names, or some other way let's you sort them out so this isn't a problem. The real fix, of course, is for AV to build a better SMUS player (which I'm sure they will). ?|^] Ray Lewis