The point to mentioning vblank was not register access, but the fact that you're likely not going to be sending MIDI messages during this time, which is relevant if you're needing to stream each individual message in a time critical manner. HDMA isn't going to help as it has no logic. You're only going to be able to send 4 bytes max (one per port). You're not just going to blindly send every X scanlines or frames are you? There are a number of big problems with that. ToP is not constantly trying to stream individual midi messages as you prescribed. It's chunking samples out periodically in a controlled fashion.
The DSP registers implement a lot of MIDI's functionality (such as key-on/key-off) out of the box to begin with.
Not really. Key-off on the SNES is not the transition to decay as you expect to get out of a key-off midi event... That's just it, you will see there is actually a great deal of processing to be done to translate each event, and properly manage your voices, channels, polyphony, and features.
the SPC doesn't need to block. it can run in a timer driven loop which at some point scans the port registers for a new event and buffers it when one is present (a suitably-sized ring buffer ought to work here) otherwise it cycles the loop and continues other processing (ie: processing of already buffered events, echo, reverb, pitch or amplitude modulation, etc.).
Good luck with that. I think you will have difficulty expecting the SPC timer and fetch code to correlate precisely enough with any fixed HDMA transfers. There could be many MIDI events that happen simultaneously such as simply two chords at once. And you're going to need to stream each one individually close enough together not to sound funny, and get it all processed before the tick time of the next event. Based on my experiences, I certainly wouldn't do it as such if you want it to be of any use beyond just a standalone MIDI player.
Regardless, I'm sure everyone would be interested in how things go for you during your development.