Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!stanford.edu!neon.Stanford.EDU!flamingo.Stanford.EDU!espie
From: espie@flamingo.Stanford.EDU (Marc Espie)
Newsgroups: comp.sys.amiga.audio
Subject: Re: To all mod player programmers, my personal wishlist
Keywords: Intuition, modules players, Amiga, Programmers, Powerpacker
Message-ID: <1991Apr25.193358.14944@neon.Stanford.EDU>
Date: 25 Apr 91 19:33:58 GMT
References: <1991Apr24.110733.22225@cs.ruu.nl> <1991Apr25.145445.6722@ccs.carleton.ca>
Sender: news@neon.Stanford.EDU (USENET News System)
Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France)
Lines: 82

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).