>> 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). > >Again I am talking about standard MIDI file parsing, not MIDI stream >parsing, just >to be sure you understand me correctly. >All but the most simple applications would never use a BMidiStore class for >MIDI >recording/playback. The midi2 kit doesn't have a BMidiStore equivalent. >Parsing a standard MIDI file is not that hard and if an application wants to >control >how the MIDI events are represented in memory it had best do this all >itself. >For the simple applications (like games) that just playback MIDI, ok for >those >something like BMidiStore can be usefull. But I don't consider it top >priority and >think such a class would be better placed in a seperate utility library. I appreciate your patience with me in this. I am *NOT* a musician and I know little to nothing of music, other than a CD Player. :-) My understanding of this topic comes from reading the MIDI file spec (well, skimming it) and looking at the MIDI (1) kit. The API looked very sensible and easy to use. I don't understand why you (and others) don't like it. Again, though, I have no real knowledge of MIDI, though, to make a judgement. What you seem to be saying, though, makes me wonder what the point of Midi2 is. It seems like it is just a message passer and replicator (sprayer). IOW, if I want to write an app that, say, plays MIDI songs, I have to parse the midi file myself, create a BMidiProducer, and feed it events. That seems unnecessarily hard to get started with, if the main focus of the app isn't music. As you said, a game or something. I am not sure what the "right" thing to do is, here. On one hand, it seems that you, as an experienced MIDI person have good ideas. But I just can't quite consign every programmer out there who wants to play music to having to parse files. >> 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 think this would prove very hard to get even remotely usefull :) Oh, no question. That would definately be a > R1 thing. >Because I think this is a higher level and does not belong in the low level >input/output API, just >to keep things simple and seperate. >If we have a working IO API then implementing a BMidiStore like class is >just a couple of >hours coding, I am just afraid that starting with implementing these extras >might distract from >the more important issues. And this is what I don't quite get. I looked at the MIDI spec. I couldn't read it in a couple of hours, much less understand and code it. When you say a "working IO API", are you talking about the Storage Kit? Can you talk a little bit about 2 things - why Midi (1) is not good enough for professionals and what Midi 2 does that is good?