>> >Writing a MPU401 driver from scratch shouldn't prove too difficult, but >has >> >someone been able to find documentation on it? >> >> I don't know if anyone is looking... > >Well, start looking :) :-) Wish I could. Actually, I am just stirring up trouble here. :-) I don't have proper time to lead this group - I am just getting and keeping things going until we have a team lead. >Hmmmm indeed! Also the SGI MIDI API also does not handle sysex merging as >can be read on their website. So it is not a easy to solve problem. The best >solution >IMHO is to have the 'spray' function return an error saying that a sysex >transfer is >in progress. This is not that easy to implement however. That sounds sensible. I am not 100% sure why it isn't easy to implement. But, again, I know next to nothing about midi. >> >I disagree. The way MIDI parsing is done in the old MIDI kit is only for >the >> >most simple applications and will not scale to more complex ones. I don't >think parsing >> >standard MIDI files is an essential part of the MIDI kit. There are >libraries that >> >available that do MIDI parsing and I don't even think they are GPL'ed :). >I even wrote one myself >> >once and would be willing to opensource it (LGPL). >> >> I am not sure that I understand why you feel this way. > >What exactly do you not understand? I understand that you don't think that parsing of the file is a good idea in the API. I don't understand *WHY* you think that each developer should have to know that '4F' means turn on note 15 (or whatever). Actually, what I was thinking of the other day, as a neat idea, would be to incorporate MOD (through Translation Kit). Basically make MIDI the "BBitmap" of Translation kit. Then all of the music creation languages (mod, midi, etc) could be created and played transparently through MIDI kit. >I'm saying that I think reading/writing standard MIDI files shouldn't be in >the MIDI IO API. Right. But not why. You seem to know a lot more about MIDI than the rest of us. Please explain.