Oron,
Here are better answers to your 3 or 4 questions/comments:
Yes, there is a call to exit() in *source code* portmidi.c, but this is
only compiled if PM_CHECK_ERRORS is defined. This is the default in the
makefiles because it's probably the right setting for development work.
It's convenient because it catches and reports errors even if you don't
explicitly check return values in your application. "Serious"
applications and non-console Win32 apps should compile without
PM_CHECK_ERRORS, check return values explicitly, and handle them.
portmidi28aug06 is not the latest version. I can't check the website at
the moment, but I think it's portmidi23oct06, and I restored some code
that was somehow dropped from the portmidi17nov04 version. If there's
still stuff missing, please let me know.
The "huge buffer of 1024" should not really be a problem -- the buffers
are passed around by reference (although perhaps there's a copy when you
cross the kernel boundary?). I think it would be more of a problem to
use small buffers in the case of large sysex messages. Allocating the
right size for each message would incur heap allocation and free
overhead, and could cause some serious real-time problems acquiring
locks to a shared heap (as in the default thread-safe malloc()). I think
there is far more overhead handling byte-by-byte delivery of even short
sysex messages in the device driver than possibly copying up to 1024
bytes for nothing, but I'm open to exploring any apparent performance
problems.
Finally, you said sometimes sysex messages are not delivered to the MIDI
device. I've experienced synthesizers dropping sysex messages when they
are sent at the full MIDI data rate, and portmidi does not try to
throttle MIDI data rates. Another possible problem is internal buffer
overflow: you should make sure the portmidi output buffer size passed to
pm_OpenOutput() is large enough for the largest sysex message and you
should check all return values for errors. If that doesn't help, let me
know how to get portmidi to drop messages and I'll track down the
problem. A good way to start is to use two machines -- one to send, and
one to receive and check. The pm_test/sysex.exe program uses a similar
idea, but sends to itself, and seems to work reliably.
Thanks,
Roger
_______________________________________________
media_api mailing list
[email protected]
http://www.create.ucsb.edu/mailman/listinfo/media_api