midifile considers realtime message, which are not part of midi files

[porres]

data that [midirealtimein] reports shouldn't be part of midi files...

[umlaeute]

why not?

• https://www.midi.org/forum/3769-midi-real-time-message#reply-3770
• https://www.cs.cmu.edu/~music/cmsip/readings/Standard-MIDI-file-format-updated.pdf §2.3 p.5f

[porres]

both links say that they can be part of a Sysex message, but this doesn't mean they are legal on their own. In fact, anything goes within a Sesex message and midifile already takes care of sysex

[umlaeute]

so do you have an example file that has the illegal data stored, or some example patch to record the illegal data?

[porres]

I don't have examples, I guess one can use midifile to record realtime messages easily. But hey, check here on page 6 of the Standard:

Another form of sysex event is provided which does not imply that an F0 should be transmitted. This may be used as an "escape" to provide for the transmission of things which would not otherwise be legal, including system realtime messages, song pointer or select, MIDI Time Code, etc. This uses the F7 code: F7 \<length> \<all bytes to be transmitted>

[umlaeute]

well, i think this is the text i was referring to, with my two links, no?

EDIT: i think you were actually quoting my 2nd link. but anyhow: yes, this is what i was thinking about (i can't remember why i put page "5f" rather than just "6", ...)

[porres]

yes, this is from the pdf.

not sure if midifile takes care of this form of sysex event btw

[umlaeute]

well, with the midi-clock.mid file (somewhere buried in the first link, probably on a secondary page) it just outputs the the raw bytes (e.g. 240 248 , aka 0xF0 0xF8).

I don't have examples

since you opened this ticket: what is the actual problem that you have discovered and want to solve?

[umlaeute]

sidenote:

https://github.com/pd-externals/mrpeach/blob/0a3afee8f5610c4ad55a58fc0142196393b4a393/midifile/README.md?plain=1#L1-L3

[danomatika]

Wouldn't you want to be able to record incoming running status to a MIDI file? If the MIDI file spec doesn't allow for running status, then the problem is more that midifile supports this when it should really add the status byte implicitly.

UPDTE: Sorry, I confused "realtime" with "running status" for some reason.

[umlaeute]

I think, I would want to be able to record whatever comes over the MIDI-wire (and which is legal in a MIDI-file).

So far, I only see that @porres wants to remove some functionality (which seems to be the opposite).

That's why I'm asking whether there are specific examples of broken behaviour.

[porres]

it just outputs the the raw bytes (e.g. 240 248)

so that's a sysex message, not a midi clock realtime message, which would be just '248'.

what is the actual problem that you have discovered and want to solve?

I think, I would want to be able to record whatever comes over the MIDI-wire (and which is legal in a MIDI-file).

The code to either play or write midi realtime message is useless. There are no midi files with them, so it will never play that. If the player finds them, it should be considered a bug in the midi file and ignored, or maybe print a warning.

Equally, there's no point in writing realtime messages into a midi file, because it is illegal and against the specification of a MIDI-file.

I don't see this as a feature, but a bug, I guess Martin just wasn't aware midi realtime messages are supposed to be sent in "realtime" and not in MIDI files.

[danomatika]

If realtime messages are not allowed in the MIDI file spec, then they shouldn't be supported by the object. In fact, the 255 / FF MIDI system reset status byte value is used by the MIDI file spec to denote it's own meta events, so it would be important to make sure not to write the value arbitrarily.

[porres]

midifile handles 0xFF correctly as a meta event, but yeah, that's another point/reason that midi real time messages are not allowed, anything from 248 to 255... unless you use the sysex "hack" for some reason