#3 File writing/reading major problems

open
nobody
None
5
2011-01-19
2011-01-19
No

There seems to be a significant problem with midi file writing.
Read in a midi file, write it out again, then try playing the result. Each time I've tried doing this (playing the file using Timidity++), the result has been that each track gets played one after another.

I've spent a day trying to debug this and can't work out what the problem is. The event tick times that get read in seem reasonable, so I assume the problem is with the output, but I can't see what it is.

Furthermore, as you might expect from the above, if you then try reading in the file that you previously wrote, the timings exhibit some strange differences to the timings that were originally read in.

Note:
Before it was possible to run these tests at all, I had to fix a couple of bugs. Firstly the typo "contorl" -> "control" in midi.py. Secondly, the slightly bigger problem that the tracks all get duplicated as you write them out.

All in all, this seems to be the basis for a really good Python midi-handling package, but until these major problems are overcome it's unusable. I may return to trying to fix them myself, but for now I'm going to try investigating other packages available.

Discussion

  • Mark Granroth-Wilding

    I've found the bug.
    EventStream needs to set self.endoftrack=None in add_track(), so that a new EndOfTrackEvent gets used for the next track.

    I'm working on a version of midi.py with this bug and the others mentioned above fixed. I'll post it here once I've cleaned it up.

     
  • Mark Granroth-Wilding

    New version of midi.py with bugfixes and additions

     
  • Mark Granroth-Wilding

    Attached: new version of midi.py.

    I've fixed the bugs that I mentioned. Reading and writing of midi files seems to be working fine for me now.

    I've also added some stuff to do with running status. System common and system exclusive messages (as far as I can work out) should not use running status and should reset the current running status, so I've implemented that.

    Finally, I've also added some extra code for one particular type of sysex message - single note tuning events. This may seem rather arbitrary, but I'm using them myself, so thought it best to put the code in the library so that others can easily create these.

    Hope this all looks good. The library's working well for me. I hope this can be of use to others.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks