SMUSMIDI User Manual SMUSMIDI 1.0 SMUS to MIDI File Conversion Software by Thomas E. Janzen SMUSMIDI 1.0 software Copyright (c) 1991 Thomas E. Janzen All Rights Reserved Thomas E. Janzen makes no warranties, either expressed or implied, with respect to the software program recorded on the diskette or the instructions, their quality, performance, merchantability or fitness for any particular purpose. The program and instructions are distributed free "as is". The entire risk as to their quality and performance is with the user. In no event will Thomas E. Janzen be liable for direct, indirect, incidental or consequential damages resulting from any defect in the program or instructions, even if Thomas E. Janzen has been advised of the possibility of such damages. This software is intended for use within any and all applicable laws. Thomas E. Janzen is not responsible for the use of this software to convert music files claimed to be protected by copyright or other laws. This software may be redistributed only intact with no change and only at no charge. Your comments about SMUSMIDI are very welcome as soon as you have tried the program. Your comments and questions about SMUSMIDI may be directed to: Thomas E. Janzen 58A School Street Apt. 2-L Hudson, MA 01749-2518 1 (508) 562-1295 Commodore (TM), Amiga (TM), and AmigaDOS are trademarks of Commodore Business Machines, Inc. SAS/C is a trademark of SAS Institute, Inc. MIDI file format is specified by the International MIDI Association (IMA). No part of this software may be used in whole or in part in another public domain or commercial software. INTRODUCTION The standard MIDI file format, defined in "Standard MIDI Files 1.0" published by the International MIDI Association, is an international format for the exchange of MIDI event recordings, and may be so for many years to come. SMUS (Simple Music) format, defined by Electronic Arts and Commodore Business Machines, Inc., is still being used by multi-media programs; I can't estimate it's life. It is one of two file formats produced by DMCS from Electronic Arts (TM). The other is a proprietary IFF form with private chunks. The proprietary DMCS file holds more information than SMUS format, but it is not publicly defined. SMUS format is publicly defined, as is Standard MIDI File format. Although some multi-media programs for the Amiga use SMUS format, MIDI sequencing programs almost universally use Standard MIDI File format, in addition to private formats that hold more information, just as DMCS's proprietary format does. The current commercial SMUS-MIDI converter is available as an add-on to another program for a total of hundreds of dollars. Many people have written music in DMCS, only to later buy inexpensive modern MIDI sequencing software, and find that they cannot transfer the old files to the new program. This program, SMUSMIDI, makes it possible to transfer DMCS SMUS output files to a modern MIDI sequencing program by converting the DMCS SMUS file to Standard MIDI File format. SMUSMIDI does not: 1. Convert SMUS forms that are embedded in other IFF files. 2. Convert all SMUS files, for example, those output by software other than DMCS. 3. Support file icons 4. Require a MIDI hardware interface or use internal Amiga voices. SMUSMIDI was compiled with SAS/C 5.1a. HARDWARE REQUIREMENTS SMUSMIDI probably would run on an Amiga with 512K bytes of memory. To estimate the amount of memory needed for a conversion, multiply the length of the SMUS file in bytes times five. To find its length, use the AmigaDOS list command. RUNNING SMUSMIDI SMUSMIDI is run from a CLI (command line interface). Set a path (using the AmigaDOS path command) to the location of SMUSMIDI, or changed directory (with the AmigaDOS cd command) to the directory in which SMUSMIDI resides. The command format for SMUSMIDI is: SMUSMIDI inputfile.SMUS outputfile The input file should be an SMUS file output by Deluxe Music Construction Set. The output file may be any name; .MID will be appended to it. For example: 1>SMUSMIDI goldbergaria.SMUS goldbergaria FORM is: 1360 bytes. HEADER: Tempo: MM 63; 4 Tracks SCORE: goldbergaria.SMUS Instrument: First Voice Instrument: First Voice No more instruments. Length of track: 608 bytes This will read goldbergaria.SMUS, close it, convert it to Standard MIDI File format, and write it to goldbergaria.MID. The repeats marked by Bach are lost. To preserve the list of instruments in a note, use indirection: 1>SMUSMIDI >goldbergaria.notes goldbergaria.SMUS goldbergaria Limitations and known problems: DMCS SMUS files apparently lose some information (relative to the proprietary format) from the file, although I may be wrong about this. Some of the apparently lost information is: 1. Slurs (phrasing marks) 2. Playing styles (staccato, etc.) 3. MIDI channel assignments Therefore, the MIDI output file from SMUSMIDI cannot represent this information. In addition, SMUSMIDI does not preserve instruments. Repeat signs are lost. Crescendos are lost. I don't know if these items are in the SMUS file to start with, but they aren't documented in the standard. Preserved and copied into the MIDI file are: key signatures, time signatures, and control changes. SMUSMIDI inserts "NULL" text events in the MIDI file to separate two consecutive delays. I am too sick of working on the program to fix this. The music is converted quite well, so I don't care any more. A commercial sequencer I use strips out everything it doesn't want, so this is a non- problem anyway. SMUSMIDI CODE SMUSMIDI is the most complicated spaghetti code I have ever written. It is about 1231 lines. I didn't plan it that way, and that's why it happened. I could have spent more time designing; OK, SOME time designing. It probably took under 100 hours. The source files for SMUSMIDI are: SMUSMIDI.c IFF/smus.h IFF/iff.h IFF/compiler.h The IFF headers can't be included in the kit. They are printed in the ROM Kernel Reference Manual: Exec, and are available to developers. I got them from Freely Redistributable Software Library disk number 185. SMUSMIDI.c contains my code. SMUSMIDI begins by reading the command-line arguments. If anything goes wrong, it prints an error message, releases its memory, closes all files, and exits. The input file is opened and tested to see if it is an SMUS file. If not, SMUSMIDI exits. When it finds the SMUS form, it reads the entire form into a dynamically allocated section of memory (called SMUS_Score) and closes the input file. It then opens the output file; if this fails, it exits as before. Memory is allocated for the MIDI file ("MIDI_Score") that is four times larger than the SMUS file. The size of the MIDI files is typically 2.4 to 2.6 times the size of the SMUS file. The reason they are so big is that 240 clocks/quarter is used, and this produces larger delay values, which are a variable-length quantity in Standard MIDI File format. This value can be changed for recompilation, if you have a C compiler, at the top of the code in a macro called TICKS_PER_QUARTER. To continue, SMUSMIDI lists the score information, including any instruments. It does not use this information in the MIDI file. It then begins converting the tracks. The tempo track is made first, by reading only time-signatures and tempi (tempos) into the first track of the MIDI file buffer (MIDI_Score). When this is done, it returns to the beginning of the first SMUS track and starts converting musical events in SMUS_Score into MIDI events in MIDI_Score. It loops through a section of code that converts one track, until all tracks are converted. The loop is a nightmare. If I had done an intermediate conversion first, say into an array of structures that had the following representation for an event: 1. pitch 2. dynamic 3. true duration, including all ties 4. time to start from beginning of track, than it might be much easier to convert this to Standard MIDI File format. By doing a direct conversion, I made it necessary to track all kinds of annoying things, such as an array of old chord notes, because they have to be turned off together, and a separate array of old tied notes, for the same reason. Complex decisions are made in if-statements 5 or so deep on the basis of the following: Is the note tied? Is the note chorded? Is the note in an old chord? If so, is it tied backwards or forwards or both? Is the note tied backwards? Here's a chart I made late in the game: Tied Back NotTiedBck Tied Back Note Tied Back Tied Tied Not Tied Not Tied -------------------------------------------------------------- oldchrd Chord| dont' play play don't play play? | newchrd Chord| don't play play don't play play | add chrd ary add chrd ary add chrd ary add chrd ary | oldchrd No Chrd|don't play play don't play play | delay delay delay delay | turn off turn off turn off turn off | newchrd No Chrd|don't play play don't play play | delay delay delay delay | turn off ? ? ? This chart may be wrong is some details, but you can follow the code, if you dare. The reason that this is so difficult is that, aside from the assumption that I did it the wrong way, is that SMUS is a musical event protocol, and MIDI is an industrial event-based control protocol. MIDI doesn't know about dotted eighths, ties, or chords; it doesn't need to, but SMUS does. SMUS has flags for dotted notes (1.5 duration), triplets, quarters, eighths, etc., whether the note is chorded to the next note (implying simultaniety), and so on. SMUS is much more complex than MIDI. Tracking chorded/tied status was revealed as important when chords are tied together, but the chords have different notes. For example, if a chord, C - E - G is tied to a chord C - G, DMCS marks the E as tied even though there is no E for it to tie to. That's why I had to look ahead to see if there was a tie note. I have used complex combinations of chords and ties in DMCS to emulate piano pedaling, so I had to convert this kind of event and worse into MIDI format. The code includes many subroutines to support this nonsense, and you are welcome to read them. ROOM FOR IMPROVEMENT SMUSMIDI should be improved in the following ways: 1. The null text events separating delays should be eliminated and delays combined. 2. The repeat sign code should be reverse-engineered and repeats supported. 3. Ticks per quarter should be an optional command-line parameter. 4. The program should support general SMUS format so that outputs from programs other than DMCS can be converted. I won't do any of these changes because I have already successfully converted 130 of my own modern "classical" compositions and about 20 off the network, so I got what I wanted out of this exercise. BIBLIOGRAPHY MIDI Programmer's Handbook. Steve De Furia, Joe Scacciaferro. M&T Publishing, Inc. Redwood City. 1989. ROM Kernel Reference Manual: Exec; Carl Sassenrath, Rob Peck, Susan Deyl; Commodore Business Machines, Inc. Addision-Wesley Publishing Company, Inc., Reading. 1986. Deluxe Music Contruction Set Manual for your Amiga; Electronic Arts, San Mateo. 1986.