S36666WB%ETSUACAD.BITNET@ricevm1.rice.edu (Brian Wright) (11/01/90)
On 31 Oct 90 14:26:52 GMT you said: > > SO WHAT IS MY POINT? >I think that there should be a new standard for songs that resembles >the format that the SoundTracker modules are in. It will offer higher >quality music, allow more people to become musicians, and be easy to >play. The main point is that the quality of the music will be a lot >higher. Hear! Hear! Yes! Si! Oui! Da! I agree 100% The mod. files are becoming quite abundant compared to SMUS files. There has to be some kind of a synthesized type sound included in the file format so that, when available, we are not stuck with samples only. It might be wise to agree on a standard .mod and song file format because of the variations in each of the successive ST type programs. MED can either save .mod files or it's own version of a mod format. I think that there NEEDS to be a standard before we take the plunge. >dan. > >chopin!dan@uunet.uu.net --> please use. >st00482@auvm.bitnet --> yeeeech ------------------------------------------------------------------------ ======================================================================= ||NeXT- (nekst) N. The only PC to have sold less than 10,000 units and || || not be considered a flop. || ||------------------------------------------/ /------------------------|| ||---Brian Wright | / / || ||---s36666wb@etsuacad.etsu.edu | \ \/ / Only Amiga || ||---Commercial Artist and Amigaphile| \/\/ Makes It Possible!! || =======================================================================
peterk@cbmger.UUCP (Peter Kittel GERMANY) (11/01/90)
In article <35126@nigel.ee.udel.edu> S36666WB%ETSUACAD.BITNET@ricevm1.rice.edu (Brian Wright) writes: >On 31 Oct 90 14:26:52 GMT you said: >> >> SO WHAT IS MY POINT? >>I think that there should be a new standard for songs that resembles >>the format that the SoundTracker modules are in. It will offer higher >>quality music, allow more people to become musicians, and be easy to >>play. The main point is that the quality of the music will be a lot >>higher. > >Hear! Hear! Yes! Si! Oui! Da! I agree 100% The mod. files are becoming >quite abundant compared to SMUS files. There has to be some kind of a >synthesized type sound included in the file format so that, when available, >we are not stuck with samples only. It might be wise to agree on a standard >.mod and song file format because of the variations in each of the successive >ST type programs. Well, I don't know about the insides of the mod format. But I think it would be wise to keep the concept of IFF up. If you look into it, you realize that the 8SVX IFF already has many of the needed components for this type of data file. And for the real score you still can use SMUS. Perhaps this could be evolved a bit. 8SVX is until now more a single sample than a whole piece of music. So how about defining some new chunk types to expand the abilities of 8SVX? This could be discussed here in public, and when it is settled it should be presented to CATS (probably Carolyn Scheppner) as a proposal to include it into the official IFF standard. IFF has been such a tremendous benefit for the Amiga world that you should stick to it. So, what sort of chunks could be needed? Sorry, I don't know in which way ST/NT store their data, but one can guess: You need a SMUS like way to store the score with all its changings on the fly. Probably it would be advantegeous to compress informations in a way that you can easily build loops (also nested) and generally repetitions. Some more proposals? You see, in a way like this, the powerful IFF concept could be used to also meet the needs of newly evolved topics. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
joseph@valnet.UUCP (Joseph P. Hillenburg) (11/02/90)
How about since IFF uses chunks, we use a standard similar to MED, but follows the IFF pattern for chunks. Make the standard almost like MED, but have the chunks so that it's easier to manipulate. And make sure the MED guy, CBM, EA< and more know about the standard so that we make sure it spreads, and possibly a version of intuitracker that supports both MOD.* files and the new song files. -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
hill@evax.arl.utexas.edu (Adam Hill) (11/02/90)
In article <558@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: [ lots deleted ] >some new chunk types to expand the abilities of 8SVX? This could Dissidents Software was working on a SAMP IFF form. I have no idea if it is official.. I remember Leo S. had some things to say about it on BIX :-) >be discussed here in public, and when it is settled it should be >presented to CATS (probably Carolyn Scheppner) as a proposal to >include it into the official IFF standard. I guess it is time to break out the AutoDocs and become one with the IFF concept :-) >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... -- adam hill "I will tell you three things.." hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA! Amiga... Multimedia NOW!! 24 Bit Color(n.) Large waster of bandwidth. "Amiga walk with me ........"
stoller@cbmcel.UUCP (Martin S. Stoller) (11/02/90)
In article <558@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >Well, I don't know about the insides of the mod format. >But I think it would be wise to keep the concept of IFF up. >If you look into it, you realize that the 8SVX IFF already has >many of the needed components for this type of data file. >And for the real score you still can use SMUS. >Perhaps this could be evolved a bit. 8SVX is until now more a >single sample than a whole piece of music. So how about defining >some new chunk types to expand the abilities of 8SVX? This could >be discussed here in public, and when it is settled it should be >presented to CATS (probably Carolyn Scheppner) as a proposal to >include it into the official IFF standard. IFF has been such a >tremendous benefit for the Amiga world that you should stick to it. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk Unfortunatly, SMUS is WAY OUT OF DATE. ST/NT data files are NOT IFF, and never will be. What is really neaded is a new MUSIC FORM, which takes the good stuff of each idea. IFF is still the best thing. I can load a Pic from my AMI onto my PC, without bothersome conversions, for example. Also, all good Programs using GFX load and save IFF. Here a short declaration of JAZZ, a new IFF, which holds SAMPLES AND SCORE! =======WARNING; C BELOW!====== FORM HEADER --CHUNK OWNER {for info, such as AUTHOR, PROGRAMNAME, DATE ....} --CHUNK MAININFO {how many samples, length of song, time (3/4 etc), ...} ----CHUNK SAMPLE ----CHUNK SAMPLE . . ----CHUNK SAMPLE ------CHUNK SAMPLE INFO {length, time, maximum/minimum Octave, etc..} ------CHUNK BODY {crunched!} ----CHUNK SONG ------CHUNK SCORE INFO {length etc...} ------CHUNK BODY {crunched!} ================================ That means, a very simple IFF. I am not a musician, just a programmer. The above is free of any rights whatsoever... One can easily have several songs in one IFF, using CATS and such. (a song anim??? with diffrences calculated to save space... :-) my .02cents (CND) worth... -- Regards, UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller
martin@IRO.UMontreal.CA (Daniel Martin) (11/03/90)
In article <558@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >... >Well, I don't know about the insides of the mod format. >But I think it would be wise to keep the concept of IFF up. Yes. >... >So, what sort of chunks could be needed? Sorry, I don't know in >which way ST/NT store their data, but one can guess: No need to guess. By looking at a module you can easily discover the general file structure layout: (20 bytes) Name of song (30 bytes) Instrument Name 1 ... (30 bytes) Instrument Name 31 (2 bytes) Lenght of block list (Maximum 0x80 (128)) (2 bytes) Unknown (128 bytes) Block list (the music sequence of blocks) (4 bytes) normally 0x4D2E4B2E, unknown. (?? bytes) Block 1..n (notes for each channels (4), unknown) (Ins 1 lenght) Instrument 1 (binary dump) ... (Ins 31 lenght) Instrument 31 (binary dump) Instruments are just the body of an 8SVX file (binary dump). The instrument name field format is like: (22 bytes) Name of instrument (4 bytes) Lenght of sample (you must multiply by 2 this value) (5 bytes) Unknown (1 byte) either 0x01 or 0x00. Unknown. Bodies of instruments are place sequentially at the end of the files. Can some people add to the missing parts of this description?? IMHO, it would be relatively easy to IFF'size this format, using few new tags. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... -- // Daniel Martin Universite de Montreal \\ // MediaLab, ca vous regarde! C.P. 6128, Succursale A, \\ \\// Mail: martin@IRO.UMontreal.CA Montreal (Quebec), CANADA, \\// \/ Tel.: (514) 343-6111 poste 3494 H3C 3J7 \/
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (11/06/90)
In article <183@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes: >Unfortunatly, SMUS is WAY OUT OF DATE. ST/NT data files are NOT IFF, >and never will be. What is really neaded is a new MUSIC FORM, which >takes the good stuff of each idea. IFF is still the best thing. I can >load a Pic from my AMI onto my PC, without bothersome conversions, for example. >Also, all good Programs using GFX load and save IFF. Here a short >declaration of JAZZ, a new IFF, which holds SAMPLES AND SCORE! I don't think this is necessary. IFF isn't just a standard to store one single data item. The most simple way would be a CAT that stores a sequence of FORM 8SVX and FORM SMUS chunks. The SMUS player would have to use the preceeding samples before looking in its sound library. If all sounds used in the score are present in the CAT you have a single file that stores a complete piece of music. Maybe there are other limits within 8SVX or SMUS but that doesn't need a new music FORM but simple additional chunks to the existing formats. -- 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."
jnmoyne@lbl.gov (Jean-Noel MOYNE) (11/06/90)
I couldn't agree more on the need for a new IFF music file format. The
current SMUS format is a mistake. Let's face it, nearly nobody uses it. ST
has had such a succes because it came with the source code for the song
player, this song player was 2k long, very fast (in front of any SMUS
player), and very easy to use from a programmer's point of vue.
Programmers are not musicians usually, and they had the choice: either try
to write your own SMUS player (long process, it's gonna be long and
difficult to do, lots of bugs comming, hard to do in asm, will take a lot
of CPU time), or you use ST (nothing to write, you have an asm code
allready here, it's fast, etc ...).
So, since programmers needing a music for their programs are game and
demo programmers, and what they need is a fast song player, the fact that
you call the routine every VBL int is very cool too (since for all these
programs doing animations, everything is tied to the VBL int.).
So nobody never really used the SMUS, because it's too complicated,
programmers are lazy etc ... (whatever .. (-:). ST is really like an 8
bits program, but you can easilly put the different parts of it's file
format in an IFF form, IFF is really nice for the fact you can create all
the chunks you want. The instruments in the ST file format are merely a
dump of the waveform, with a name, a length, and a number. The body of the
songs is a suite of patterns, so you create a chunk pattern (the pattern
number, and the pattern itselfs) all the patterns have the same size, and
here you are. You may need a couple of other chunks, but the less the
better. Then you take your good old ST player, and just modify the loader.
By the way, it should be a great idea to use 8SVX to store the
waveforms instead of the dumm 'dump' used by ST (remember the problems
with the first versions of ST that couldn't load IFF samples).
At the same time, I think we need this RSMS IFF form (Real Simple
Music Score (-:), and a RESM IFF form (Really Evoluated Music Score).
Because ST doesn't use much of the sound possibilities of the Amiga. ST
uses only simple samples, the way it stores and allows you to enter the
score is kinda 'rude'. SONIX is giving a much better idea of what a music
program should be. Especially the instruments you can create yourself,
with an Enveloppe Generator (a real one), playing with filters, LFO's etc
... The Amiga synth is really a very poor synth for that (no enveloppe
generator (or follower), no funny things like ring modulation, LFO, etc
... it's 'do it yourself') it is a FM synth however ... but nobody was
ever able to produce an interesting sound using the FM in a program.
I don't know if it would be a wise idea to have 2 different IFF
formats. But we definitely need a Real Simple Music Score format. Then if
some program appears that uses really more of the internal musical
possibilities of the amiga (I don't belive too much in that however (-:),
this program should define an Evoluated format.
JNM
--
These are my own ideas (not LBL's)
" Just make it!", BO in 'BO knows Unix'p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (11/07/90)
In article <558@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >You need a SMUS like way to store the score with all its changings >on the fly. Not necessary. You can use CAT to glue SMUS and 8SVX together. 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."
stoller@cbmcel.UUCP (Martin S. Stoller) (11/07/90)
In article <1360@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <183@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes: >>Unfortunatly, SMUS is WAY OUT OF DATE. ST/NT data files are NOT IFF, Good Ideas Deleted... >Maybe there are other limits within 8SVX or SMUS but that doesn't >need a new music FORM but simple additional chunks to the existing >formats. >Michael van Elst > "A potential Snark may lurk in every tree." So you know your SF-Fantasy... ^^^^-> 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. (In the future: "MA, why is it taking so long to load the Molekule Structure of my Breakfast?" "Because you want Synthetik Corn Flakes with Asperatim. That is in an old Format, so it takes several milliseconds to decompress...") -- Regards, UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (11/13/90)
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."
bims@diku.dk (Asger H|gsted) (11/14/90)
S36666WB%ETSUACAD.BITNET@ricevm1.rice.edu (Brian Wright) writes: >On 31 Oct 90 14:26:52 GMT you said: >> >> SO WHAT IS MY POINT? >>I think that there should be a new standard for songs that resembles >>the format that the SoundTracker modules are in. It will offer higher >>quality music, allow more people to become musicians, and be easy to >>play. The main point is that the quality of the music will be a lot >>higher. >Hear! Hear! Yes! Si! Oui! Da! I agree 100% The mod. files are becoming >quite abundant compared to SMUS files. There has to be some kind of a >synthesized type sound included in the file format so that, when available, ^^^^^^^^^^^ The new startrekker V1.2 will be supporting synthesized sounds, so no need to worry! (Well, Exolon says this in the manual for the 1.1, so assuming he isn't lying, there will be no prob!) >we are not stuck with samples only. It might be wise to agree on a standard >.mod and song file format because of the variations in each of the successive >ST type programs. MED can either save .mod files or it's own version of a The new startrekker 1.1 supports also startrekker 1.0, Noisetracker 2.0 and previous versions of Noisetracker. >mod format. I think that there NEEDS to be a standard before we take the >plunge. Never wait with plunging tomorrow when you could do it today. >>dan. >> >>chopin!dan@uunet.uu.net --> please use. >>st00482@auvm.bitnet --> yeeeech So long, Xeno of Gnu design (bims@freja.diku.dk) >------------------------------------------------------------------------ > ======================================================================= >||NeXT- (nekst) N. The only PC to have sold less than 10,000 units and || >|| not be considered a flop. || >||------------------------------------------/ /------------------------|| >||---Brian Wright | / / || >||---s36666wb@etsuacad.etsu.edu | \ \/ / Only Amiga || >||---Commercial Artist and Amigaphile| \/\/ Makes It Possible!! || > ======================================================================= ^^^^^^^^^^^^^^^^^^^^^^^^ (he's right, you know!) -- ------------------------------------------------------------------------------ To be is to do. -- I. Kant To do is to be.
stoller@cbmcel.UUCP (Martin S. Stoller) (11/16/90)
In article <1373@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >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 ? And Mike Batt must have read Edgar Rice Burroghs :^) [stuff deleted] Read my Rablings elsewhere, if they still exist :^) >I don't think that a complicated IFF is much slower to load. Of course A complicated IFF plays H*LL with normal disks. As I wanted to say before, HARD DISKS are perfect for complicated IFF, but not Floppies... A simple IFF, with only one FORM, (planned proparly) will load faster than any CAT. >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 Copmression is also needed for simple IFF. Even decompressors written in C can be real fast on 68000/8Mhz! >from the overhead of IFF. >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. Quite simply 'cause the ANIM saves space on DISK and IN RAM! All my frames ( except the original) are diffs from the previous. I have Anims which are 40 frames long. How big ? Not much bigger than 2 ILBM's of the same resolution, noise and depth. >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. Ok, repair SMUS & 8SVX. You might end up with something usable :^) >Michael van Elst > "A potential Snark may lurk in every tree." You know what a SNARK is? No? Lucky you... -- Regards, UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (11/25/90)
In article <188@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes: >A complicated IFF plays H*LL with normal disks. As I wanted to say before, >HARD DISKS are perfect for complicated IFF, but not Floppies... A simple IFF, >with only one FORM, (planned proparly) will load faster than any CAT. Why ? Especially with floppies you won't see much differences between reading large chunks and smaller ones (ok, sth like 8 or 16 blocks). And then you can simply use buffered reads (or even double buffered). With harddisks that's a difference, the fantastic transfer rates most people mention (>300k/sec) can be reached only by reading contigous blocks in one single read operation, so you get slower when dealing with smaller buffers. >>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 >Copmression is also needed for simple IFF. Even decompressors written in C >can be real fast on 68000/8Mhz! Yes, that is but I don't see the point here. If you have to process the data at all (versus "loading a plain memory dump") you won't see any speed loss from parsing the IFF structure too. >>from the overhead of IFF. >>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. >Quite simply 'cause the ANIM saves space on DISK and IN RAM! All my frames ( >except the original) are diffs from the previous. I have Anims which are >40 frames long. How big ? Not much bigger than 2 ILBM's of the same resolution, > noise and depth. No, I didn't think of saving frames with full information, but I wouldn't invent a new FORM while say a LIST ILBM with maybe some new property chunks would have done the same. >>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. >Ok, repair SMUS & 8SVX. You might end up with something usable :^) What should I repair ? SMUS and 8SVX is quite usuable. >You know what a SNARK is? No? Lucky you... Well, it's handsome for striking a light. 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."