Discussion of Python midi library

[gbreed at cix.compulink.co.uk]

Mike Brenner wrote:

> Here is a suggestion as to what to encapsulate (each one is harder than 
> the next.
> 
> 1. Midi Instruments (preferably the hundred general midi instruments 
> from grand-piano up through gunshot and the hundreds of xg midi 
> instruments available on the more advanced synthesizers and 
> sequencers). The attributes of the instruments would include:

There are 128 General MIDI instruments.  This suggestion sounds like 
overkill, but as you're being ambitious it might be a good idea.  Make 
sure you have the basic library in place first.

> 2. Midi Selection Sequences. Each midi hardware will have certain 
> selection sequences, bank selection commands, patch selection commands, 
> controllers, etc. There must be a way of doing the machine independent 
> stuff in a machine independent manner and yet there must be a way to 
> insert the device-specific stuff. The currently selected hardware must 
> be part of the model. There must be ways to insert, delete, modify, 
> move, and copy notes and other commands into channels, including 
> setting their velocity (loudness), frequency (pitch), duration, etc. A 
> single command will enter a chord, a triple, a comment such as key, a 
> meta event, etc.

This all sounds like it makes sense.  Treating chords and triples might 
run into problems as the aren't treated as such by MIDI.  If we're doing 
hardware abstraction, I suggest going beyond some of the MIDI limitations 
like with channels and number of notes.

> 3. Image. A string image function must represent every object, possibly 
> in a standard format like xml, musicml, etc.)

This goes beyond what I'd expect from a MIDI library.

> 4. Time. There must be a consistent time model used throughout, which 
> easily represents notes, rests, start, finish, etc.

Certainly!  This is the main encapsulation you need over a verbatim 
translation of the MIDI.

> 5. Graphical representations in staff format, say, in jpeg or png 
> format.
> 
> 6. Reading in a bit-mapped graphical representation (say a jpeg or png 
> file) of a staff into midi format.

More stuff that goes beyond what a MIDI library should concern itself 
with.  Adding hooks for a score editing program makes sense, but staff 
notation shouldn't be special-cased in this way.  It differs from MIDI in 
some fundamental ways, particularly timing, and the two should be clearly 
distinguished.

> 7. Pattern recognition of a wav file into a midi format, choosing the 
> right notes, durations, and instruments.

And this is an extremely ambitious project in itself.


                    Graham