Comment 4 for bug 1527410

For the record the portmidi header does describe how a caller is supposed to recover from overflow. If we aren't detecting overflow that's a bug as well:

/* Pm_Read() retrieves midi data into a buffer, and returns the number
    of events read. Result is a non-negative number unless an error occurs,
    in which case a PmError value will be returned.

    Buffer Overflow

    The problem: if an input overflow occurs, data will be lost, ultimately
    because there is no flow control all the way back to the data source.
    When data is lost, the receiver should be notified and some sort of
    graceful recovery should take place, e.g. you shouldn't resume receiving
    in the middle of a long sysex message.

    With a lock-free fifo, which is pretty much what we're stuck with to
    enable portability to the Mac, it's tricky for the producer and consumer
    to synchronously reset the buffer and resume normal operation.

    Solution: the buffer managed by PortMidi will be flushed when an overflow
    occurs. The consumer (Pm_Read()) gets an error message (pmBufferOverflow)
    and ordinary processing resumes as soon as a new message arrives. The
    remainder of a partial sysex message is not considered to be a "new
    message" and will be flushed as well. */