I finally got around to looking at this issue (thought I'd take a break from arguing about licensing and actually contribute!)
It turns out this issue is really easy to "fix", but much harder to *really* fix. To elaborate: 1. To "fix" the issue, all I had to do was change fluid_midi so it doesn't ignore the End-of-track event. In my patch, it puts the EOT event on the event queue, which forces the player to wait until it hits the EOT event before it considers a track to be finished. I've opened a ticket on this issue with an attached patch: https://sourceforge.net/apps/trac/fluidsynth/ticket/101. You can follow the development of this patch on Launchpad: https://code.launchpad.net/~mgiuca/fluidsynth/eot-event 2. To *really* fix the issue, it turns out, it is a bit more complex, depending on your MIDI file. If your MIDI file's EOT event is precisely at the same time as the final note, then this won't help in the slightest. I write my music using Rosegarden (http://www.rosegardenmusic.com/), and no matter how long you drag out the track object, when you export to MIDI, it sets the EOT event to the same time as the last note-off event. So this patch doesn't actually help me at all. As I said on the tracker, if we want to fix this, we'll have to dive deeper into the code and wait until all the notes have actually finished playing before we stop the song. Basically, #1 is a bug in FluidSynth (it *should* observe the EOT event and not cut off early). #2 could possibly be considered a bug in the MIDI file / Rosegarden, but it might be nice to address it anyway. I think the ticket I just opened (#101) should just be for fixing the #1, and if people are keen to address #2 we can open a new ticket. Matt _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
