Matthijs Hollemans wrote: > Your code looks fine, except for the { braces, which I always put on the > next line. Okay, then I'll make an exception to my brace rules in this case. :-) >I haven't many complains otherwise. Although I wonder why you > declared all local variables "static," since that doesn't seem to be > necessary, judging from your code. Martijn already pointed out the problems associated with that. > It would be nice to add a BMidiParser class to libmidi2.so, which would > do what your MidiIn::PushInput does, but with a configurable data source. > So the user of this class would have to provide a GetNextByte() method > that returns the next byte of input. If would return a special code to > signify the end of the data stream. Then the midi_server and your own > code could simply use the same class, preventing code duplication. Yep, this would be nice. Don't know what the best way for interfacing this would be. You could offer a BMidiLocalProducer subclass with my method; just push bytes in, and have the complete messages Spray()ed automatically. Offering access via GetNextByte would work too, but I'm not sure its most efficient - if data comes in in chunks of several bytes each, you add a function call each time you want to fetch one byte; input in chunks of several bytes would be more efficient. Eh, but let's talk API another day, I'm too engaged in coding. ;) > Unfortunately, we aren't really supposed to extend the public API. Now, > we could add BMidiParser to the BPrivate namespace, but then your app > would be using a private API which is also frowned upon. Oh well. > > There are other additions like this that I would like to make to the Midi > Kit, but I guess these will simply have to wait until OpenBeOS R2. Maybe we could create a libmiditoolkit, which contains enhanced functions. This could be migrated into libmidi2.so in OBOS R2, requiring only an exchange of headers and a recompile. > Cool. Remember, though, that MidiPortProducer not only needs to parse the > byte stream, it also needs to talk to the drivers through the proper > protocol. Right now it simply uses a blocking read() call to get the > bytes -- which seems to work -- but there are also a number of ioctl() > calls to worry about. Unfortunately, I have no idea how these are > supposed to work. This doesn't change anything with respect to your > changes, but it is something to keep in mind :-) Okay, stored in mind. ;) I don't have experience with low-level I/O yet, but as I want to learn about that, I'll revisit the MidiPortProducer code when I can judge what it is doing wrong. Bye, Chris