Thanks robtillart for taking the time to look and comment.
starnges that an destructor calls initialize
Initially I had some memory allocation going on and I had to free memory (that was being done in close()), so the destructor needed to call close(). I have renamed initialise() to resetTrack() which may give us all less of an uncomfortable feeling.
saw you have a dump mode (but it is a cooked dump not a raw dump)
There is a sketch that does a raw dump of the data in the chunks after the header, without using the library. I also use a utility called "MIDI File Analyzer" (picked up somewhere off a Google link) that basically agrees with my own dump(s) of the files, so I am have a high confidence the dumps are correct.
not handling all values between 0xf1 ... 0xff:
Yes, correct. These values are real time valuies that appear in a MIDI live stream as control messages but are not valid in a file - 0xf1 is undefined, 0xf2 is Start a sequence, 0xf3 is Continue sequence. 0xf4 is Stop sequence, 0xf5 is undefined, 0xf6 is Active Sense (like a watchdog timer), 0xff is Reset System. All others in this range should be processed.
x not used
A leftover from when I had an intermediate result being calculated.
syntactically wrong as you should use the boolean && not the bitwise &
and it can be faster
Agree. Suggested version also saves 1 byte of stack space :-)
many loops use int i; you could check if uint8_t is enough ?
Good point, will check.
So many #if 's makes me wonder if you could not better
Great point here. I have done what you suggested before and I don't know why I didn't do it here as well. This will also make the code more maintanable, as an alternative output stream is easier to implement if needed.
I'll post an updated version of the library once implemented and tested.