Seen with SDK 2.6.0 on Windows and Linux, Lua or C.
The documentation for playdate.sound.sequence:getLength() states that the function returns the step in the sequence where the last note ends (same as playdate.sound.track:getLength(), but for the longest track in the sequence). I take this as meaning the step where the last note stops playing, as that's what I would expect as "track length".
For this trivial test case:
at 60 BPM we have one note that plays for 4 seconds, or 1920 steps in the resulting MIDI file. I would expect the getLength() functions to return 1920 (or 1921) as the step at which the last note ends, instead they return 1, the step at which the last note starts.
Similarly, with one more note:
The functions instead return 1921, again the step where the last note starts playing.
With a note that lasts two bars, again the functions return 1.
Is this an actual bug or have I misunderstood the intent here?
That definitely sounds like a bug. If it's convenient, would you mind posting your .mid files showing this? I don't have anything (afaik) that creates mid files, and it'd save me from having to build one in a hex editor. Thanks!
Got it, sorry for the slow response! When it's reading the file it and it sees a MIDI note on event it creates a note event with length 1 in the sequence, and then when it sees MIDI note off if sets the length of the sequence event.. but it doesn't update the track length to match. I'm pushing a fix now. Huge thanks for your help here!