Yes, you would simply read the complete event, from the timing data thru the status byte to any carried data, and just ignore the whole thing, and move on to process the next event.. I would say that Running Status does need to be taken account of regardless, because if the midi event being disregarded should change RS then the following event would have a problem.

Geoff

You are correct that in the MIDI file format, it is important to be able to keep track of how many bytes each message takes.

Be aware that the allowed "status bytes" in a MIDI file are a little different than the status bytes allowed on a MIDI cable. Also, some of the "status bytes" in a MIDI file have different meanings or formats than the status bytes on a MIDI cable that have the same value.

The "status bytes" allowed in a MIDI file are:
* any MIDI channel message (hex 80 to EF)
* a System Exclusive message (hex F0)
* a "verbatim" message (hex F7)
* a Meta event (hex FF)

In a MIDI file, the MIDI channel messages have the same meaning as they do on a MIDI cable, and they all have a known length. These are the only messages in a MIDI file that can use running status.

The other kinds of messages in a MIDI file all contain a "variable length quantity" that indicates how many data bytes are contained in the message. Also these message types cancel any running status in effect and can't use running status themselves.

As you probably know, on a MIDI cable, the status byte of hex F4 is currently undefined and reserved. If you happened to come across this status byte on a MIDI cable, you would have to ignore it and wait for the next status byte.

But in a MIDI file, you have to know how many bytes each message takes. When you are expecting a "status byte" in a MIDI file, hex F4 is not allowed. If you really did encounter a "status byte" of hex F4 in a MIDI file, the only thing you could do is display an error message, you would not be able to continue reading the MIDI file past that point.

(If the MMA ever defines a purpose for the MIDI cable status byte of hex F4, and if it is useful to put inside of a MIDI file, I think it would have to be stored in a "verbatim" message -- a MIDI file "status byte" of hex F7. This kind of MIDI file message has a "variable length quantity" that indicates how many bytes it takes. The data bytes of this kind of message are supposed to be sent to the MIDI cable verbatim, so in theory, it can contain anything you want to transmit on a MIDI cable, including things that aren't otherwise allowed in a MIDI file or things that aren't currently defined. However, in practice, be aware that it's such an esoteric message, you probably can't rely on MIDI players to support it very well.)

References:

This table of MIDI cable status bytes shows hex F4 is undefined and reserved.

The Standard MIDI file specification (first PDF link on the page, login required to download), describes the allowed events in a MIDI file. See PDF pages 8 and 9 (printed page numbers 6 and 7).

Also, this exact same post was posted by Jan Kučera on January 31, 2016: Ignoring MIDI events int SMF

The answer given by Clemens Ladisch to that post agrees with what I said above:

[...]parsing [MIDI files] requires knowing the length of messages.

F4 is invalid, and must not appear as an event in SMF files. (In theory, to send an F4 byte out of the MIDI port, an SMF file would have to use an escaped event (F7).)

When you encounter an invalid event, such as F4, the best you can do is to abort parsing and return an error.