Allow overriding mac limit rate via -DLIMIT_RATE=0

[danomatika]

As discussed previously, Puredata includes Portmidi sources and we disable the mac rate limiting on build, currently via patching the existing LIMIT_RATE handling to allow overriding it via CFLAG -DLIMIT_RATE=0. This PR simply brings that patch upstream for consideration.

Another approach could be to keep the #ifdef checks but add another define to disable the first ala:

#ifndef NO_LIMIT_RATE
#define LIMIT_RATE
#endif

In that case, I'm not sure what fits the codebase best, maybe LIMIT_RATE_OFF ala VERBOSE_ON?

[rbdannenberg]

Have you tried the current version? It turns out that CoreMIDI will not drop data when you send to real devices. PortMIDI now detects when you are sending to a real device and does not limit the data rate. This has been tested using a microcontroller I built that implements loopback over USB. CoreMIDI limits bandwidth to virtual ports so that if there is a cycle in port connections, the infinite loop will not run forever in the kernel at high priority. But this can also drops data from normal programs. I do not know the internal algorithm for data rate estimation, and it's undocumented. I believe it does some kind of monitoring of buffers or does periodic measurements, and it must allow high-rate bursts to some extent. I would be open to a different rate control algorithm that reliably transmits MIDI, but I'm reluctant to put in an option to allow the software to misbehave. I'll think about it though.

Are there any cases where allowing programs to send unreliable data streams at more than 5KB per second over virtual ports is necessary? (A previous complaint was that rate limiting affected USB interfaces, but this is no longer true.) Do you have any other way to avoid losing data?