The MIDI renovations in the chap-midi branch now compile and work for me
on i386 with the MIDI devices I have on hand for testing, and it would
be great if they could also be tested on some other platforms and
equipment. They resolve PRs kern/32441 kern/32442 kern/32567 kern/32588
and kern/32694. The documentation in the midi.4 man page is more extensive,
and both audio/rosegarden (a very old version) and wip/rosegarden
(less old) can be used on NetBSD for MIDI work. (audio/rosegarden
needs to be patched as described in PR pkg/32735).

A minimal functional test would involve at least playing a reasonably
demanding MIDI file with midiplay(1) over an externally connected MIDI
synthesizer. Jeff Glatt has a sample of well-constructed MIDI files at
http://www.borg.com/~jglatt/files/midifile.htm; some, like his own "Joan
of Arc" (under Progressive Rock) are not bad at revealing data rate or
dropped data problems. The new Active Sensing support can be tested by
interrupting midiplay(1); when the playing stops, the external synth
should be silenced rather than sustaining the last sounded notes. (If
that doesn't happen, please make sure the connected equipment does
support active sense before suspecting a problem).

A simple test for input is 'cat /dev/music >foo' (then play something on
an externally attached keyboard) followed by 'cat foo >/dev/music'
(which should give a recognizable reproduction). The dropped-input
problem (kern/32441) could be quite noticeable and annoying if large
chords (many near-simultaneous notes) were played over a umidi
interface. Input should now be reliable; if you have a keyboard that
offers elaborate auto-accompaniments and echoes them to MIDI OUT while
playing (as many do), you can confirm that you are able to capture these
with 'cat /dev/music >foo' and reproduce them. The reproduction may
differ in some voice parameters like volume, timbre, etc. from the
instrument's built-in performance.

More focused (if less entertaining) tests can be found in the PRs
listed above.

kern/32651 may affect users of MIDI interface h/w that lacks a transmit
interrupt. Such interfaces are found on some inexpensive soundcards,
and also there are some soundcards that apparently do support tx
interrupts but whose MD NetBSD drivers do not use them (and should).

The new MI code takes a different approach to the problem, based on the
observation that MIDI traffic is sparse and bursty: short clumps of
messages meant to be near-simultaneous interleaved with no traffic for
macroscopic periods. So the code no longer artificially throttles the
transmission rate when there are messages to send; they are sent as
quickly as possible, and in the usual case of MIDI playback there should
be no practical effect on system responsiveness. There can be an effect,
though, with bulk transmissions such as voice patches. Interrupts are
not blocked and the writing process is forced to yield periodically, so
multiprogramming does continue, but the drag will be noticed. Of
course the moral is that anyone who would like good multiprogramming
responsiveness while transmitting bulk MIDI data should avoid using MIDI
interfaces that lack a transmit interrupt--and the handful of drivers
that do not use the tx interrupts their hardware actually supports
should be updated to do so (most easily by someone familiar with the
hardware involved).

-Chap