Haha indeed that is the time delta.
Well, if you load a MIDI file that works via JUCE code, save it right away, it will create a bogus MIDI file. Unless I’m missing something completely, it’s reading the same event at the end of writeTrack([…]).
My thoughts are that, perhaps in this case, filtering this event series in readNextTrack([…]) and writeTrack ([…]) and adding it at the end may be a safer and robust solution for a JUCE user/programmer. This may seem like overkill, may slow down the process a little bit, but who knows what a user might do in between loading tracks, and later saving tracks.
A separate method that completely cleans out a track’s End of Track event series, and adds it at the end, could be called after reading a track, and before writing it to a file, probably eliminating the need for this code in writeTrack([…]):
const MidiMessage m (MidiMessage::endOfTrack());
out.write (m.getRawData(), m.getRawDataSize());
void MidiFile::fixEndOfTrackEvent (MidiMessageSequence& out)
//Don't bother with a blank sequence
if(out.getNumEvents() <= 0) return;
double lastTime = 0.0;
for(int i = 0; i < out.getNumEvents(); ++i)
if(out.getEventPointer(i)->message.isEndOfTrackMetaEvent() == false)
lastTime = out.getEventPointer(i)->message.getTimeStamp();
out = seq;