Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!mel.dit.csiro.au!latcs1!burton From: burton@latcs2.lat.oz.au (Jamez de Coilier) Newsgroups: comp.sys.amiga.audio Subject: Re: To all mod player programmers, my personal wishlist Keywords: Intuition, modules players, Amiga, Programmers, Powerpacker Message-ID: <1991Apr28.055307.19311@latcs2.lat.oz.au> Date: 28 Apr 91 05:53:07 GMT References: <1991Apr24.110733.22225@cs.ruu.nl+ <1991Apr25.145445.6722@ccs.carleton.ca> <1991Apr25.193358.14944@neon.Stanford.EDU> Organization: GUI and HyperMedia Programming ,Latrobe Univ.,Melb,Australia Lines: 102 In <1991Apr25.193358.14944@neon.Stanford.EDU+, I could have sworn espie@flamingo.Stanford.EDU (Marc Espie) managed to say: +In article <1991Apr25.145445.6722@ccs.carleton.ca> ags@scs.carleton.ca (Alexander George Morison Smith) writes: +>In article <1991Apr24.110733.22225@cs.ruu.nl> jjverkui@cs.ruu.nl (Hans Verkuil) writes: +>>To all module player programmers in the Amiga world: +>>I want to have a module player that has the following features: +>> +>>o Supports (at least) Sound/NoiseTracker and MED (up to 3.0) modules +>>... +> +>One more minor one: +>o Tells the operating system that it is using the audio channels. +> +>Intuitracker 1.1 crashes when something else does audio, such as the +>speech device announcing the time. Other players have similar problems. +>IT 1.2 seems to fix this by allocating the audio channels to itself. +>Other module players should do the same to be truely multitasking +>friendly. If you want to get fancy, audio priority and channel stealing +>would be neat. +> +>o An ambitious player could use fast memory (or even hard drive space) +>for storing samples, only copying the needed parts to chip memory just +>before the sample is used. That would allow an explosion in sample +>size. After all, only four samples are ever active at once, why not +>keep the rest somewhere where there is lots of space?. +> +>- Alex +Ok, I'm currently programming a ``nice'' player, so I have my opinion +about that. + +- channel stealing is a MUST. It's much nicer to have a very well-behaved Agreed, plus you can vary your priority, i.e. so that IMPORTANT sounds in the music play at higher priority... +player. Also, it's easier to test it if you can run two versions at +once, or run it at the same time as another reasonably ``behaved'' program. +like Intuitracker12 (a good player too, if it didn't crash, played at the +right speed, and didn't try to hack the display of my 3000, and....). +(See the RKM's CMD_LOCK for the audio device) +Very, very nice. For those who don't know: for playing with the audio +hardware, most programs allocate all channels with maximum priority, so that +they effectively bar access to anybody. Another possibility is to ask the +audio.device to play watchdog for you. You allocate the channels with the +priority you need, and anybody who has a higher priority can steal them +from you (alarm clocks, beeps), but you get to know it. Your program +restores the audio.device to an acceptable state, frees the channels, +and usually goes to sleep, waiting for the channels to return. + +- the memory is something of a problem. Let's have a player that is, say, +30K long. Add all kinds of fancy possibilities, like swapping samples +from one place to another. You either slow it down/enlarge it enormously +(or both:-). If (like me), you have lots of memory, a fast hard-disk and +a fast processor, that's fine. What about an amiga 500 with 512K, or +an old 1000 with 256K ? What about the guy with 1Meg who wants to use his +amiga and have a player going ? I was such a guy not long ago... How about making it into a bunch of re-entrable libraries, each of about 10kbytes. Then when you can find the resources to use a 'fancy' function like double buffering from FAST ram, bring in the approriate library. Then the same executable will run on a 256kbyte A1000 and a 8Mbyte A3000. +What he needs is a forgettable player with a simple interface. +Forgettable, because it takes a minimum amount of memory, is easy to set +up, and doesn't ever crash... (also, only the samples have to be in chip mem, +not the whole module... which means some extra work for loading compressed +formats without using too much extra-memory). Again , if speed is a problem, the modules will have to be unpacked before it plays. This will run on a smaller m/c , just a hell of a lot slower. +The easy solution is to have a full-featured version and a trimmed down version. +The not easy part is to figure out what is a must-have for the trimmed down +version. Any ideas ? Why ? BTW, the sample-size problem is a real problem +now that there are amigas with 1Meg/2Meg of chip memory. Does any program +except MED support more than 512K chip mem. +With a little twicking, it's usually feasible to transfert the samples at +the right place without too much overhead. Another interesting possibility +is undersampling: compress the samples by a factor of two and play them at +twice the speed. + +Also I would need some more stuff to experiment. +Maybe other formats than noisetracker and MED are needed, but I need EXAMPLES... + +Right now, all my noisetracker modules use only command 0-4 10-15 (with +a slight haze about 14), the docs I have don't agree about the other +commands, and anyway I have no means to test them. +I have one future composer module, and that's it. Not a hint about differences +between noisetracker/startrekker/protracker (well... one hint: a doc file +for protracker and a replay-routine which won't work on a 68030 :-( ). + +I would appreciate sample modules/players/composers/doc files... pointers +to archives or specific demos on ab20 (I have the ``music'' stuff). +Answer by e-mail, of course. Thanks. + +Before I get flooded with questions, I don't know when I will release my +player. Hopefully, there will be a pre-release sometime very soon (less than +a week). Good luck with the work James Burton. La Trobe University Melbourne.