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