The latest downloads on sourceforge include updates for the latest Xcode, some fixes for running on 64-bit architectures, and timestamping under OS X core midi that should prevent OS X from dropping bytes. It should be noted however, that accurate timestamping has been removed from the OS X implementation. Here's what happens now:
Whenever a timestamp is computed, before storing it in a packet for OS X, the timestamp is increased if necessary to limit the data rate to below 15KB/s, which is the point at which OS X will start dropping packets (it's an intentional design choice in CoreMIDI). That means if a 3-byte message is scheduled for time t, and you send another 3-byte message scheduled for time t, the second message will be sent with a timestamp of t + 3/15000, or t + 0.2ms. Note that "real" serial MIDI would delay the packet further to about t + 1ms, so the small delay of 0.2ms may not matter. It might be possible to do better. CoreMIDI uses some aggregate data rate measure, and short bursts, e.g. two simultaneous note-ons, are certainly not a problem, but modeling CoreMIDI's underlying rate control mechanism to avoid dropped packets is not simple. At least the current strategy is relatively simple to explain, offers near-maximum throughput, and seems to avoid all cases of dropped packets. _______________________________________________ media_api mailing list [email protected] http://lists.create.ucsb.edu/mailman/listinfo/media_api
