[openbeos-midi] Re: activity/status?
- From: "Martijn Sipkema" <msipkema@xxxxxxxxxxxxxxxxxxx>
- To: <openbeos-midi@xxxxxxxxxxxxx>
- Date: Thu, 4 Apr 2002 11:29:22 +0100
> >> I would rather look at it as an example of the not really as free as
they
> >would have you believe GPL biting us. :-)
> >
> >Well, the GPL is about freedom for the user also. And many library
> >developers
> >choose to use LGPL.
>
> 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.
Writing a MPU401 driver from scratch shouldn't prove too difficult, but has
someone been able to find documentation on it?
> >[...]
> >> Where to begin? I would look at the BeBook. That and the MIDI spec.
> >> I would start by ignoring serial ports/USB all together and writing a
MIDI
> >parser
> >> for files. A second development track could use the existing (Be's)
parser
> >and load and
> >> play instrument files.
> >
> >Parsing a MIDI file is simple and better left to the application. The
midi2
>
> This is one of the places where it looks like Be and I had a difference of
opinion.
> I honestly didn't believe that Midi2 didn't have format parsing, but you
are correct.
> That *sucks*. I think that parsing the data stream (which, AFAIK is the
same from serial, USB or file)
> is a *critical* piece. That and synthesis.
>
> 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 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 betime
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
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.
> >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).
--martijn
Other related posts:
