[...] > 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. The MIDI Kit is easy to use, but not very flexible. It does not allow for IPC. It also get unnecesarilly difficult to use when needing to output to more than one port. > 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. Correct. > 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. Well, I did not mean to say that every programmer has to parse the standard MIDI files himself, just that we should focus on getting the MIDI kit core functionality, i.e. input/output of MIDI to interfaces/applications, working. I guess adding MIDI file parsing/playback wouldn't be that difficult and would indeed make life easier for game developers. > >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? Simple input and output to either hardware MIDI interfaces or other applications. > 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? The original MIDI Kit does not support IPC MIDI input/output. With more complex applications I don't like having to use a BMidiPort with a seperate thread for every output. The MIDI 2 Kit has its problems too, though. If compatibility with BeOS is to be preserved we'll have to implement the MIDI 2 Kit. It's easy I think to build an old MIDI Kit compatible layer on top of that. What could prove difficult is to have a MIDI 2 Kit compatible API that doesn't suffer all the problems the Be's MIDI 2 Kit does. What would be good now I think is for the members of the MIDI Kit team to suggest ideas of how to implement the Kit. I have suggestions also, but I don't want to influence you already. It would be a good thing IMHO to see if we can come up with an elegant solution. And we'll need drivers, (without a standard ioctl set, just a device dependant way to communicate with it) so that can be started on. Especially MPU401 UART support is important since so many soundcards have these. I have been working this weekend on a plugin interface that implements a standard interface for communicating with the low level MIDI driver: midi application -> midi kit -> device plugin -> device driver. the plugin is a set of "C" functions and a C++ class. I have not yet finished it and I'm doing this for POSIX, but the plugin interface is cross platform (the implementation itself is not, it needs threads and timers, but it is also device dependant, so that is not a problem.). I think it would be best to start programming from the bottom up, i.e. starting with the drivers, plugin.... --martijn