Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga
Subject: Re: a new music standard
Message-ID: <1373@mpirbn.mpifr-bonn.mpg.de>
Date: 13 Nov 90 15:36:43 GMT
References: <35126@nigel.ee.udel.edu> <558@cbmger.UUCP> <183@cbmcel.UUCP> <1360@mpirbn.mpifr-bonn.mpg.de> <185@cbmcel.UUCP>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 43

In article <185@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes:
>>                                "A potential Snark may lurk in every tree."
>So you know your SF-Fantasy...   ^^^^->
It's from the Mike Batt album "The hunting of the snark" based on Lewis Carrols
Epos. Would you call this SF ?

>A CAT is a good idea, but.  The more complicated an IFF gets, the longer
>it takes to load from FloppyDisk (Nota Bene: Fast HDs are FAST, so if your
>Programm is only to work on HDs, then there is no need to invent something new.
>But how many games are sold on Hard Disks???) and the faster said Floppy gets
>ready for an update! Also I am not (personnally) prepared to wait several
>minutes for the dang thing to load.  A new FORM is needed, and should include
>a new compression method for SAMPLES and SCORES.  Okay, so may last post
>was a bit simplistic, but that's how we want to keep it, right?  As I said,
>Michael's idea is good, but only if speed makes no difference.

I don't think that a complicated IFF is much slower to load. Of course
it needs a little more time than loading a plain memory dump but if you
introduce any coding schemes (like data compression), you won't see anything
from the overhead of IFF. If the machine is fast enough to do the
decompression on the fly you might even reduce loading time.

BTW, a new FORM would need nearly the same loader than reading a CAT or
LIST. And then, it is the strength of IFF to combine several data items
into one file in a structured manner. I've never seen a reason for ANIM
files not to include complete ILBMs but the stripped BODY. Maybe you'll
end with redundant information but it makes the format more orthogonal.

The only thing that I'm missing from SMUS scores is some internal
structure for repeated measures, patterns and the like. It isn't
necessary since you can express the structure within IFF but then
we had to create a standard interpretation of nested SMUS records.

Any volunteers to write (and publish) a SMUS/8SVX reader and player ?
I've seen a nice SMUS player but it comes binary only, so you can't
use it with your own programs.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."