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

Reply via email to