Xref: utzoo comp.sys.atari.st:36279 comp.music:2778 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!speedy.cs.pitt.edu!bogdan From: bogdan@speedy.cs.pitt.edu (Bodgan Kosanovic) Newsgroups: comp.sys.atari.st,comp.music Subject: Re: Midi file format (Used by several midi programs). Summary: Computer Music Standardization Problems Keywords: MIDI, MIDI file format, atari, samplers, sound processing Message-ID: <10189@pitt.UUCP> Date: 19 Mar 91 02:35:43 GMT References: <1482@ahds.UUCP> Sender: news@pitt.UUCP Reply-To: bogdan@neuronet.pitt.edu (Bogdan Kosanovic) Organization: University of Pittsburgh Lines: 138 In article <1482@ahds.UUCP> geert@ahds.UUCP (Geert W.T. Jonkheer CCS/TS) writes: >... >I am writing a midi program for the atari ST. As many other programs, >I would like to use the standard Midi file format to store >midi data on disk. However, I don't know what the terms on this >format are. Where can I find information about the midi file format? >... etc. Thank you on asking that question. I have started a year ago interesting project (see below), not supported from any institution (as in majority of computer music projects), which led me to the similar questions. Problem of STANDARDS in Computer Music. MIDI standard is not enough. Every day we can see hundreds of new "Music" products whose only purpose is to take your money out of your pocket. Manufacturers are not thinking of standards, they need FAST production and large profit. I don't think that there exists a Standard MIDI File Format. It is also important to define what kinds of information you would like to see in such file (multitrack recording of MIDI events, MIDI dump of patch parameters, music scores of composition, live performance protocol file, etc., etc.) As far as I know MIDI Sample Dump Standard is THE only standard which can be related to 'files' (although it doesn't imply usage of files). It is more like MIDI Sample Dump Packet Protocol Description. If you thought of MIDI events recording, and file containing such informations, I'm afraid that widely accpeted standard DOES NOT exist. >The information i would like to get is: > >1) Are the parameters in the standard midi file machine independant. > Can all parameters be used on every midi instrument? > They should be ! Particular music device drivers should hide all characteristics of particular instrument. (Layered approach). Some MIDI instruments, however, are less powerful, so one cannot expect of all instruments to respond to all possible events. (Such events should be skipped or mapped into others when possible). >2) How are the parameters orded in the midi file. > Again, I am not sure what 'parameters' are you talking about ? If you think of MIDI composer/recorder, some hierarchy in file definition should be higly welcomed, as well as modularity, in order to minimize duplicate information (repetition of events or bars or groups of bars). If you think of patch dump files. Ordering doesn't matter. >3) Can machine dependant data (for example midi exclusive data) also be > stored in the midi file, or must i use my own format to store these > data. > This was a project I've mentioned above. I've started writing a tool which could provide MIDI programmers with a possibility of producing MIDI applications capable of controlling ANY type of MIDI device by using Object Oriented definition of Exclusive Data. To simplify, my Universal Device Driver Code Generator should produce driver code in plain C language if given simple ASCII file containing definition of any MIDI instrument. Once you have your application working with one relatively complex instrument you can be positive that it should work WITHOUT change with ANY other instrument. The only thing you should do after purchasing NEW instrument would be to enter your favorite editor and type in the definition of your NEW instrument's system exclusives using META language designed for such operations. Actual application would use STANDARD library calls like in GKS, GEM or similar graphic standard libraries (open_virtual_workstation, send (handle, data), receive(handle, data), ... where handle is music device ID opened at the beginning of application (or later)). The answer on your question is YES, but again I am not sure that there exists a standard (world wide). Unfortunately, I didn't complete my project, because nobody wanted to pay me, and on the other side people who are paying me expect from me to do other things. (I completed parser for META language, and started code generation, I also defined "standard" formats, all known exclusive messages should fit in, and I also started to think of mechanism which could provide you to include in definition file even new system exclusive message formats which are likely to appear in the future). I would like one day to see this or similar system working and to see happy faces of all music people after purchasing new instrument and configuring it after just a couple of minutes. Why should we purchase new device drivers from the manufacturers when we could define new one in 10 minutes !!! >4) Many midi music programs are using the standard control commands > for manipulating the music (such as bender, hold etc.) > I have not seen a program use control commands that are > particularly for a midi instrument (such as sound effectors which > are not descriped in the midi standard). > Programs must use the standard control commands and the > 'user defined' control commands for manipulating music > (i think) to get the most flexibility. > Is there a program on the market that uses this concept? > I hope one day we shall be able to purchase Real-Time Music Workstation capable of Music/Sound/Image processing. I hope it will cost less than 2000$ US dollars and will fit size of my desk. Some simple sound processing control can be implemented and IS implemented on some Digital Sound Processors. It is often just simple preset/effect change which is useless in 99% percent of real life situations. What I would like to see (as well as you) is real time change in reverberation or delay characteristics possibly controlled from the external source (joystick or similar controller). In a year or two Digital Signal Processing technology will be capable (I hope) of doing such things in real time and for less than 2000$ dollars. The problem is when the manufacturers are going to lower their extremely high prices. (Why some manufacturers of sampling keyboards are selling hard disk drives (40MB, extremely slow) for 900$ (!!!) when such drive can be purchased for as low as 200-300$ ?) I would also like to easily control tempo changes, dynamics, timbral characteristics (all in real-time and possibly from the external sources). AND I WOULD LIKE TO SEE A SOFTWARE PRODUCT WITH ALL THESE CAPABILITIES WHICH I CAN UNDERSTAND IN ONE DAY, WITHOUT PAIN of READING 100s of MANUAL PAGES WRITTEN WITH THE ONLY PURPOSE OF justifying WRONG DECISSIONS THEY MADE DURING DESIGN & IMPLEMENTA- TION. That would be all for know. Please forgive me on length of a text. Bogdan R. Kosanovic 4705 Fifth Ave, Apt 1-L Pittsburgh, PA 15213 U.S.A. (412)-681-2019 E-Mail: bogdan@neuronet.pitt.edu (please use this address)