[openbeos-midi] Re: Greetings!
- From: Owen Smith <ods94538@xxxxxxxxx>
- To: openbeos-midi@xxxxxxxxxxxxx
- Date: Thu, 17 Oct 2002 18:27:57 -0700 (PDT)
Hi Philippe,
> Hey, nice to see you around!
> How it's going since Be epoch end for you?
Much quieter, thanks. :-) I'm in school at the moment,
finishing up a bachelor's degree in Music.
> Well, all hints about good and bad design ideas
> about the midi_server <-> libmidi2 will help us
> reimplement it. For example, do the midi event(s)
> are spray to every BMidiConsumer simply by
> write_port() the event data to all consumer ports,
> or do shared memory should be used to keep latency
> low?
I don't think you'll find that shared memory is
necessary when dealing with MIDI data. Keep in mind
that MIDI events are usually only a few bytes in
length, and copying a few bytes in and out of a port
hardly incurs any overhead at all. (A possible
exception is sys-ex dumps, but here latency is less of
an issue than, say, control events--also keep in mind
that the MIDI serial rate is pretty slow!) Shared
memory, on the other hand, generally costs space and
can be tricky to manage correctly (see the Media Kit).
If you look in the Media Kit, you'll see that there is
a little-known class that implements a "short" buffer.
The idea was that, for cases where buffers need to be
sent quickly and the data was small enough, you could
simply copy the data into the buffer's header and send
the header by itself. IIRC, this was how we planned to
implement MIDI support in the Media Kit: by bypassing
the shared memory (i.e. buffer) system altogether.
Food for thought, perhaps?
Also note that you don't need a port for each
BMidiConsumer, and that in some cases you can forego
IPC altogether! See my reply to Jerome for details.
-- O
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
Other related posts:
