[openbeos-midi] Re: activity/status?

  • From: "Martijn Sipkema" <msipkema@xxxxxxxxxxxxxxxxxxx>
  • To: <openbeos-midi@xxxxxxxxxxxxx>
  • Date: Mon, 8 Apr 2002 11:24:19 +0100

[...]
> My understanding of this topic comes from reading the MIDI file spec
(well, skimming it)
> and looking at the MIDI (1) kit. The API looked very sensible and easy to
use.
> I don't understand why you (and others) don't like it. Again, though, I
have no real
> knowledge of MIDI, though, to make a judgement.

The MIDI Kit is easy to use, but not very flexible. It does not allow for
IPC. It also
get unnecesarilly difficult to use when needing to output to more than one
port.

> What you seem to be saying, though, makes me wonder what the point of
Midi2 is.
> It seems like it is just a message passer and replicator (sprayer).
> IOW, if I want to write an app that, say, plays MIDI songs, I have to
parse the midi file myself,
> create a BMidiProducer, and feed it events.
Correct.

> That seems unnecessarily hard to get started with,
> if the main focus of the app isn't music. As you said, a game or
something.
> I am not sure what the "right" thing to do is, here. On one hand, it seems
that you, as an experienced
> MIDI person have good ideas. But I just can't quite consign every
programmer out there who wants
> to play music to having to parse files.

Well, I did not mean to say that every programmer has to parse the standard
MIDI files
himself, just that we should focus on getting the MIDI kit core
functionality, i.e. input/output
of MIDI to interfaces/applications, working. I guess adding MIDI file
parsing/playback
wouldn't be that difficult and would indeed make life easier for game
developers.

> >Because I think this is a higher level and does not belong in the low
level
> >input/output API, just
> >to keep things simple and seperate.
> >If we have a working IO API then implementing a BMidiStore like class is
> >just a couple of
> >hours coding, I am just afraid that starting with implementing these
extras
> >might distract from
> >the more important issues.
>
> And this is what I don't quite get. I looked at the MIDI spec. I couldn't
read it in a couple of
> hours, much less understand and code it. When you say a "working IO API",
are you talking
> about the Storage Kit?

Simple input and output to either hardware MIDI interfaces or other
applications.

> Can you talk a little bit about 2 things - why Midi (1) is not good enough
for professionals and
> what Midi 2 does that is good?

The original MIDI Kit does not support IPC MIDI input/output.
With more complex applications I don't like having to use a BMidiPort with a
seperate thread
for every output. The MIDI 2 Kit has its problems too, though. If
compatibility with BeOS is
to be preserved we'll have to implement the MIDI 2 Kit. It's easy I think to
build an old MIDI
Kit compatible layer on top of that. What could prove difficult is to have a
MIDI 2 Kit
compatible API that doesn't suffer all the problems the Be's MIDI 2 Kit
does.

What would be good now I think is for the members of the MIDI Kit team to
suggest ideas
of how to implement the Kit. I have suggestions also, but I don't want to
influence you already.
It would be a good thing IMHO to see if we can come up with an elegant
solution.

And we'll need drivers, (without a standard ioctl set, just a device
dependant way to
communicate with it) so that can be started on. Especially MPU401 UART
support
is important since so many soundcards have these.

I have been working this weekend on a plugin interface that implements a
standard
interface for communicating with the low level MIDI driver:

midi application -> midi kit -> device plugin -> device driver.

the plugin is a set of "C" functions and a C++ class. I have not yet
finished it and I'm
doing this for POSIX, but the plugin interface is cross platform (the
implementation
itself is not, it needs threads and timers, but it is also device dependant,
so that is
not a problem.).

I think it would be best to start programming from the bottom up, i.e.
starting with
the drivers, plugin....

--martijn


Other related posts: