FreeLists / openbeos-midi / [openbeos-midi] Re: activity/status?

["Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>]

>> Oh no! Not license wars! ;-)
>> Just to save us all, I will say "No comment".
>
>It was not my intention to start a licanese war. You chose a license for
>OBOS,
>and that means that we can not use GPL'ed drivers, but LGPL'ed drivers could
>be used since they don't require the kernel to be GPL'ed. That's all I meant
>to say.

Understood. 

>Writing a MPU401 driver from scratch shouldn't prove too difficult, but has
>someone been able to find documentation on it?

I don't know if anyone is looking...

>> I would welcome comments from everyone on this, but I think that what we
>really want (and maybe
>> what Be had in mind) is a combination of the two. Classes like BMidi,
>BMidiPort, BMidiStore would be producers and/or consumers (from Midi2), and
>would parse/encode  data from ports/files.
>
>I was actually talking about standard MIDI file parsing and I still think
>that is best left to the application. As for parsing of the stream I am not 

I think that we may have a difference in terms, here. When I was talking about
parsing, I was talking about breaking down a stream (be it from a file, serial 
port, or 
USB) into events (OnNote, OffNote, etc). These events are "sprayed" to anyone
who has "connected" to that midi source. Basically, I am talking about the 
encoding 
and decoding of the data format into/out of events. Something that will turn 
0x4f into
"Off Note 15" (or whatever).

>sure how the old MIDI kit does this, but the midi2 kit doesn't parse. In a 
>consumer, the NoteOff()... etc functions will only be called when a producer 
>sent its data using either the generic data sending function with 'atomic == 
>true'
>or with the function for sending a noteoff. Also timestamps are not
>guaranteed to be time ordered, otherwise the Data() hook will only be called 
>(it is called for atomic commands also). Of course this isn't documented at 
>all. 
>This design works well for simple applications, but it is not the best 
>solution for 
>more complex ones IMHO. I think parsing of the MIDI stream should indeed be in 
>the kit as should time ordered receiving. This also makes the

I 100% agree.

>MIDI stream merging nontrivial. The current midi2 kit allows interleaving
>long system exclusive commands with other (than the allowed system realtime) 
>commands, even another sysex, which would mess things up, since there is no 
>way that I know of to identify the sender of a command.


Hmmmm

>> >kit does not
>> >provide any MIDI file parsing. A seperate MIDI file parsing library could
>> >always
>> >be added later.
>>
>> Sure. As could MIDI support in general. But I think that adding a lot of
>this upfront saves developers time, which is really the whole point.
>
>I disagree. The way MIDI parsing is done in the old MIDI kit is only for the
>most simple applications and will not scale to more complex ones. I don't 
>think parsing
>standard MIDI files is an essential part of the MIDI kit. There are libraries 
>that
>available that do MIDI parsing and I don't even think they are GPL'ed :). I 
>even wrote one myself
>once and would be willing to opensource it (LGPL).


I am not sure that I understand why you feel this way.



>
>--martijn
>
>
>
>