home *** CD-ROM | disk | FTP | other *** search
- About the midi.datatype future:
-
- Preface:
- I am having not much time to spend for programming and I have some
- other projects, too, so, if you are a programmer, I need your help.
- And I do not know all about midi, so I need some help to do the
- final design. If you even want to take over the whole project,
- please contact me.
-
-
- What is to do:
- Well, there are still some small improvements to be done like:
- * Send reset before starting playing
- * Make use of some special features of datatypes.library V45
- * Create a prettier control panel
- * etc.
- but I think that the BIG thing should be done first:
-
- To make loading/saving useable and allow the use of subdatatypes,
- there is a need to specify a nice memory representation of midi
- music files.
-
- Having this it will require to write code to load and save midi files
- and the midi player needs to be fully rewritten.
-
-
- Memory representation of midi music:
- The most common midi file format "Standard Midi File" (SMF) consists
- of byte streams divided into tracks by something that looks similar
- to an IFF format. These midi streams are good for sequential (serial)
- access and do need very little memory, but they fail miserably when
- trying to be accessed randomly. Random access however is required by
- editors and by players that can skip to a specifyed song location.
- So it should be considered to transform this midi byte stream into
- a tree of structures and arrays to allow easy editing and random
- accessing of it.
-
-
- What programs can make use of this memory representation ?
- * Midi editors for loading/saving midi files. It is important that the
- memory representation allows easy editing of the midi stream.
- * Midi file ananlyzers for loading midi files.
- * Midi music generators (for example a drummachine or algorythmic tunes)
- for playing and saving midi files.
- * Programs that print midi melodies on paper for loading.
- * midi.datatype subclasses for loading/saving non-SMF files. Special
- care must be taken to ensure, that all important midi file formats
- (and even those that appear in future) can be converted into this
- memory representation.
- * The internal player of midi.datatype, but external players do not
- need it, since they can make use of the internal player even if they
- have their own GUI.
-
-
- What about music modules ?
- One difference between midi music and Protracker like music modules is
- that midi uses synthetic sounds as instruments and modules use sampled
- sounds as instruments being part of the module. If this would be the
- only difference, everything would be fine and converting between them
- would only be a matter of selecting the right instruments.
-
- The instruments of modules are another problem, since many samples that
- are used cannot be found on a midi synthesizer. A further big difference
- is the effect section, which is very different (even between different
- module formats).
-
- And last but not least the way data is stored is totally different. Midi
- uses byte streams with explicit timing information whereas modules use
- a data array, called pattern, with implicit timing information. Explicit
- timing information allows more precise timing and can save memory.
-
-
- So can there be a music.datatype combining midi and modules ?
- If somebody has enough time to design and program this, I think yes.
- As an alternative a separate module.datatype could be designed with
- the same interface for playing.
-