jjverkui@cs.ruu.nl (Hans Verkuil) (04/24/91)
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
o Supports crunched (PowerPacked) modules
o Runs on a PAL and NSTC Amiga
o Handles modules written for PAL/NTSC on a NTSC/PAL Amiga correctly
o Has no trouble multitasking while playing
o For a fairly good user interface: take a look at IntuiTracker 1.2, your
module player should look like this (but at least it should also have a
button to select all modules in a directory at once).
o Should have non-stop music, i.e. loading the next module while the first is
still playing. Note: your player should be smart enough to wait with
loading if there is insufficient memory to handle both modules at once.
o When called from CLI it should detach itself, so that 'runback' doesn't
need to be used.
o It should have some way to give it a predefined module list it has to
play (for slides shows for example).
o It should be able to load modules from any device (harddisk, ramdisk,
floppydisk, etc.) and, if possible, you should support an environment
variable that gives several directories you should search for modules.
Like the Path command:
setenv MODS "dh0:music/modules!df0:modules!dh0:music/modules2"
o I would appreciate an equalizer like IntuiTracker has and a control panel
like IntuiTracker is a must!
o It should be able to handle more than X modules (where X is the munber
of lines that fit on your screen when using menus to access the modules).
Maybe you should use a requester instead of a menu.
o It should work properly with modems (I haven't one, but I heard that
often there were troubles when using a modem)
Why this wishlist? Well, I have tested several players, but all lack
features I consider important. Module Master won't run properly: apparently
it doesn't support PAL. It does support Powerpacker, but its interface is not
so good and MED is also not supported. IntuiTracker has the best user interface
of all players. However, IntuiTracker 1.1 is buggy and the equalizer and the
scrolling message when you select ABOUT of IntuiTracker 1.2 are very slow for
some strange reason (maybe PAL/NSTC problems?). The only player that plays
MED modules is MEDPlayer itself. Since this player has no user interface to
speak of, I don't need to explain why I want another player that supports
MED.
So, I hope someone out there is able to make a good player. If I knew how to
handle the modules and play them, I would try to make a good interface myself.
But I have no idea how to handle modules and I haven't the time to delve into
the subject. So, my question is: anyone out there who wants to program such a
player or who wants to change an existing player to support the above features?
If so, and if you have access to Internet, I'd be happy to beta test it for you,
or to receive a copy of your player.
Finally: I have assumed in the above wishlist that you would add at least all
the features of IntuiTracker. As I have said: this program has the best
interface of all players I've seen. Also, are there any useful features I've
missed?
Happy programming!
----------------------------------------------------------------------------
Hans Verkuil, Toendra 115, 2904 TK Capelle a/d IJssel, The Netherlands
Student Computer Science - Utrecht University - (jjverkui@praxis.cs.ruu.nl)
"...and the princesses were beautiful as the day is long and so noble they
could pee through a dozen mattresses --" (Terry Pratchett)
--
----------------------------------------------------------------------------
Hans Verkuil, Toendra 115, 2904 TK Capelle a/d IJssel, The Netherlands
Student Computer Science - Utrecht University - (jjverkui@praxis.cs.ruu.nl)ags@scs.carleton.ca (Alexander George Morison Smith) (04/25/91)
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
espie@flamingo.Stanford.EDU (Marc Espie) (04/26/91)
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 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... 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). 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).
drxmann@ccwf.cc.utexas.edu (Dustin Christmann) (04/27/91)
In article <1991Apr25.193358.14944@neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >now that there are amigas with 1Meg/2Meg of chip memory. Does any program >except MED support more than 512K chip mem. Module Master 1.7. It is probably the best overall player program right now al- though it does have a couple of problems. For example I'd like for it to sup- port MED modules and not fragment my RAM so badly. Also I have found a couple of modules that don't play right. But other than that, it's great. Any future module player should be able to use PowerPacked modules. It really saves a lot of space on disk. Just my $0.02 worth... -- Thanx, Internet: drxmann@ccwf.cc.utexas.edu Dustin R. Christmann Bitnet: DRXMANN@UTXVM "For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life." - John 3:16
burton@latcs2.lat.oz.au (Jamez de Coilier) (04/28/91)
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.