Re: MIDI parser source (bytestream->MIDI messages)

Matthijs Hollemans wrote:
> Your code looks fine, except for the { braces, which I always put on th=
e=20
> next line.=20

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=20
> declared all local variables "static," since that doesn't seem to be=20
> 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=
=20
> do what your MidiIn::PushInput does, but with a configurable data sourc=
e.=20
> So the user of this class would have to provide a GetNextByte() method=20
> that returns the next byte of input. If would return a special code to=20
> signify the end of the data stream. Then the midi_server and your own=20
> code could simply use the same class, preventing code duplication.

Yep, this would be nice. Don't know what the best way for interfacing thi=
s=20
would be. You could offer a BMidiLocalProducer subclass with my method;=20
just push bytes in, and have the complete messages Spray()ed automaticall=
y.=20
Offering access via GetNextByte would work too, but I'm not sure its most=
=20
efficient - if data comes in in chunks of several bytes each, you add a=20
function call each time you want to fetch one byte; input in chunks of=20
several bytes would be more efficient.

Eh, but let's talk API another day, I'm too engaged in coding. ;)
=20
> Unfortunately, we aren't really supposed to extend the public API. Now,=
=20
> we could add BMidiParser to the BPrivate namespace, but then your app=20
> 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 Mi=
di=20
> Kit, but I guess these will simply have to wait until OpenBeOS R2.

Maybe we could create a libmiditoolkit, which contains enhanced functions=
.=20
This could be migrated into libmidi2.so in OBOS R2, requiring only an=20
exchange of headers and a recompile.

> Cool. Remember, though, that MidiPortProducer not only needs to parse t=
he=20
> byte stream, it also needs to talk to the drivers through the proper=20
> protocol. Right now it simply uses a blocking read() call to get the=20
> bytes -- which seems to work -- but there are also a number of ioctl()=20
> calls to worry about. Unfortunately, I have no idea how these are=20
> supposed to work. This doesn't change anything with respect to your=20
> changes, but it is something to keep in mind :-)

Okay, stored in mind. ;) I don't have experience with low-level I/O yet,=20
but as I want to learn about that, I'll revisit the MidiPortProducer code=
=20
when I can judge what it is doing wrong.

Bye,
Chris