FreeLists / openbeos-midi / [openbeos-midi] Re: MIDI parser source (bytestream->MIDImessages)

[Christian Packmann <Christian.Packmann@xxxxxx>]

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