Hi Fabien,
Thanks for the prompt, and I'm sorry I didn't answer your email
sooner (it was still in my queue):
There is a problem with
your idea which is that the state (sysex, non-sysex, empty) has to be
updated asynchronously by the system thread and at least one client
thread. There may be a lock-free way to do this, but it's not obvious.
FWIW, you can do the flag update at the same time you update the fifo,
so that you take advantage of a this already-thread-safe moment,
note that it should not take long to update.
There is no "already-thread-safe" moment since PortMidi does not lock
the fifo. Adding locks is bad because of the potential for priority
inversion, given that the locks would likely be used by threads with
different priorities.
The second problem is that you can read both sysex and non-sysex data in
a single PortMidi message: real-time messages (one byte) are allowed by
the MIDI spec and by PortMidi to be embedded within sysex messages.
True, but this is why it is interesting to consider to put that in the portmidi
code,
because it is not trivial to do.
There's some old discussion archived somewhere, and maybe some comments
in the PortMidi code: a problem is that PortMidi would need to buffer an
unbounded number of real-time messages if they are not delivered
embedded in sysex data, and the real-time messages could be received
late if you have to wait for the sysex message to end. Alternatively,
you could buffer the sysex message until it is completely received and
let the real-time messages pass through as they are received (a better
idea), but this would require unbounded buffers for the sysex data. You
could potentially malloc storage as needed, but malloc also has priority
inversion issues, and I think it's a good idea to avoid calling malloc
from a real-time program if possible.
That said, It isn't very hard to do the way I suggest IMHO,
at least in the normal mode, but when it comes to recover a correct state after ,
for example , a sysxex failure with unterminated messages,
then it becomes interesting to handle that ...
I could volunteer to make this quite interesting addon if you find this
valuable.
I'm still not convinced this is a workable idea. I've certainly thought
about variations, and some other systems handle sysex differently, e.g.
writing messages off to separate buffers provided by the application,
but I don't see a strong argument to change the PortMidi API except
perhaps to add new optional functionality for applications that are
willing to accept some compromises in return.
BTW, I've doxygenized the documentation in portmidi,
it is done with minimum modification to portmidi.h
and recent doxygen tools can generate nice pdf and xcode3 documentation.
Would it be of your interest to get the doxygen makefile and the diff of
portmidi.h ?
Fabien
That sounds like a good thing, and long overdue. Can you send the changes?
-Roger
_______________________________________________
media_api mailing list
media_api@create.ucsb.edu
http://lists.create.ucsb.edu/mailman/listinfo/media_api
