Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!neon.Stanford.EDU!ibis.Stanford.EDU!espie
From: espie@ibis.Stanford.EDU (Marc Espie)
Newsgroups: comp.sys.amiga.audio
Subject: Re: Experiment IV
Message-ID: <1991May24.190414.1080@neon.Stanford.EDU>
Date: 24 May 91 19:04:14 GMT
References: <6547@vela.acs.oakland.edu> <1991May23.180254.24419@neon.Stanford.EDU> <6562@vela.acs.oakland.edu>
Sender: news@neon.Stanford.EDU (USENET News System)
Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France)
Lines: 43

In article <6562@vela.acs.oakland.edu> lmbailey@vela.acs.oakland.edu (Laurana Bailey) writes:
>
>
>MOD would be a great new IFF music standard if we could get Commodore
>to sit down and standardize it. It shouldn't be too difficult and it
>shouldn't take much modification to the current music programs already
>out (SoundTracker, Star Tracker, Noise Tracker, and more recently
>Power Tracker) to at least get them to agree to the IFF standard. 
>
>Any new features for a MOD creator program could be submitted to CATS
>for approvial into the IFF standard. 
>
>Perhaps this is more work than it sounds like, but it's better than
>the crummy .SMUS IIF standard currently out on the Amiga. The Amiga is
>noted for it's sound abilities and I have yet to see any music
>program short of some MIDI stuff that really makes the Amiga shine
>like the MOD writers do. 
>
>Perhaps someone at Commodore can speak up on the subject and perhaps
>offer a way to submit it to the powers that be for consideration?
>
Having played with the soundtracker format for a while, I would definitely
NOT consider it for an IFF format. It is a very simple binary dump,
highly amiga-dependent, very unflexible, and full of stupid quirks.
It is completely contrary to the IFF zen.
Now, designing a real music format with the same capabilities is very
feasible. SMUS is not so crummy, it has some capabilities for extension
(which soundtracker-like stuff sorely lacks). 

BTW, the player I've put into experiment iv is a very simple one. I left
it that way so that it could be used as a simple basis for people who
need to understand soundtracker format.
The next generation of player will most definitely compile the soundtracker
binary dump to its own internal format.

Update: right now, I've had some reports of problems with Experiment IV.
There seems to be a problem with the say command. Strangely enough, it
appears that it is the say command which hangs. Experiment IV does release
the audio device and exits as expected. Is there a known bug in the
narrator.device ? I'm not quite sure the audio.device lock capability is so
bug-free as I expected... more about that later.
----
	Marc Espie (espie@flamingo.stanford.edu)