I have made a change in the 2.1 branch for my own use, but have a few questions:
1) Would it (described below) be of use (should I figure out how to make it optional and submit a PR)? 2) I may have run across a memory leak and would appreciate a pointer if not so I understand (and can submit an issue if it is a leak)? 3) Was there an easier approach to accomplish this? Here's the scenario: I have a midi player I wrote for a player piano, and also a music display on which I show scores either imaged, or in some cases PDF's from Musescore. For the latter, which can have measure numbers shown, it is helpful for the midi play to show the measure being played, and allow restart at a given measure (for a student learning, wanting to hear a passage played slowly to get the timing, etc.). Musescore is not used as a player as this runs on a wimpy Raspberry Pi and can't keep up with faster pieces (I've tried, even on a Pi 3B). The measure numbers shown on the score do not allow for repeats. Rather than trying to change that, I decided to try to include the measure numbers in the midi output itself. I chose a Meta type Marker, since it will be ignored generally by midi players, and I can include a textual indicator of the current printed measure (and in repeats it will show the same measure number again of course). This seems most in keeping with "normal" measure number practice, rather than changing them to be unrolled. I also did not want to unroll the score for similar reasons - to have the score be more traditional for a student (or me for that matter). Anyway... So far all this seems to work. What I did was change exportmidi.cpp to add an event with any note-on in the measure, once for each measure in each track. To get the measure number I moved upstream to rendermidi.cpp and in the various collect sections passed the measure number into the routine, and stashed it in the NPlayEvent map to be visible later in exportmidi.cpp. I do wonder if there was a better way (and perhaps more importantly if this approach is going to fail for some specific types of scores I had not anticipated)? I am attaching a file if anyone cares to look. While looking at this, I did run across something I do not understand. My C++ skills are old and rusty, so maybe this is obvious but... using this type of Meta event means using the setEData function, which sets a pointer _edata to an arbitrary character string created on the heap (at least that's how other existing code does it, so I followed suit). I see no where this is freed; there's no destructor for MidiEvent, nor does the destructor for the track these are loaded into do anything. Is this a memory leak, albeit a relatively small one? Is that why the code at the top of exportmidi.cpp, to include title, copyright, etc. was never finished? (It's disabled with an if #0 even though it looks simple and almost complete). Or if it is freed in some way, take pity on someone trying to learn C++ again and can you show me where? Anyway... I'm good where I am, the code works, I can include it in future releases, not asking someone to create a new feature for me. My main question is whether there might be any interest in it, and if so I'll try to figure out how to add it as an option (maybe on the measure number section of general) and do a PR for the master branch? Linwood diff.txt <http://dev-list.musescore.org/file/n7580206/diff.txt> -- View this message in context: http://dev-list.musescore.org/Possible-new-feature-memory-leak-in-midi-output-question-tp7580206.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
