Home Original page

Discussion of Python midi library

Max M maxm at mxm.dk
Tue Apr 9 07:06:12 EDT 2002 
gbreed at cix.compulink.co.uk wrote:

> Mike Brenner wrote:

>>Here is a suggestion as to what to encapsulate (each one is harder than 
>>the next.


Oh boy ... I guess that you will get to implement a few of those things 
yourself if you want to use them ;-)

With my knowledge of midi and music production I expect the project to 
consist of several layers in the end:

     1. PrimitiveMidi
     Reads in the file, converts from the binary format to some sensible 
Python objects like BigEndian, VarLength, Byte, Code. All in all just a 
list of objects. I want to keep it as simple and low level as possible. 
After a read there will be a single list of simple objects that mainly 
represents string and ints and can converto those to/from the fileformat.

     2. Midi
     The library that programmers actually want to use. It should 
encapsulate the primitive data or convert it to some more relevant and 
userfriendly objects. Like: midi_event, time_signature, tempo_event and 
so on. But pretty much I expect it to be an implementation of the midi spec.

     3. MidiPlayer
     Plays music in realtime through the midiport. Hereby also the 
soundcard.

     4. MidiSequencer
     This should be a library that is independant of the Midi library, 
but can work together with that and the MidiPlayer. Here objects for 
setting things like tempo, time signatures, musical events etc. should 
be. My ideal here is Cubase, but without any kind of graphics.

     5. AlgoComposer
     Well this is actually what I am trying to get at. The rest is just 
filling :-) It will be completely independant of the other libraries but 
will use them. I expect it to be general enough to also generate output 
to software composition systems like c-sound. Perhaps I will skip 3 and 
4 completely.

Of all this I have made a first version of "PrimitiveMidi". But it was a 
bad design so I am rewriting it now.

I have a very strong idea as to how I want the "Midi" layer to work.

I also have some prototypes of the "AlgoComposer", so I know where I 
want to end.

generally I want both ends to meet nicely. The least important part for 
me is probably the "MidiPlayer" as I can allways save my music as a midi 
file and then play that. Basically I am afraid that it will take to long 
to write, but I know that interactivity is great in making music so I 
also fin



>>1. Midi Instruments (preferably the hundred general midi instruments 


Belongs in "MidiSequencer"



>>2. Midi Selection Sequences. Each midi hardware will have certain 


Belongs in "MidiSequencer"



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


Belongs in none of my library modules. But feel free to write your own :-)

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


Belongs in "MidiSequencer"



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


Not in any of my modules.


>>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.


Yes and I won't do it in my lifetime  ;-)

regards Max M
More information about the Python-list mailing list