Room for good space savings with MusicXML

[different55]

Tied notes end up as multiple separate notes (which actually ends up sounding different), rests aren't combined into one (just a waste of space), trailing rests aren't removed (same). Leading rests can also often be trimmed, but not always. Lots of room for easy condensing it down, which is extra important since we only got 1024 bytes to work with.

I tried hand-condensing my own collection of jingles. If you're hard pressed for space it's enough space to squeeze another jingle in. Savings are pretty decent. Over 12 songs I saved 120 bytes if I did my math right. Down to 972 from 1092, enough to get the existing songs under 1024 and enough to even add another on top of that.

Gonna try poking around with this over the next few days but I've never messed with C++ specifically so we'll see how far I get with that.

[greggersaurus]

Thanks for making this issue. These sound like some good improvements. If you have any issues when poking around please report them here I'll do my best to assist.

Regarding the ties notes issue. I think there is an additional MusicXML entry/node type that I am currently not parsing that distinguishes tied notes versus repeated notes, where the latter should sound like separate notes.

[different55]

Man I underestimated C++. Thought it'd be just like every other C-like language but there's like 5 flavors of syntax I've never seen before.

Anyway, I've got it functional, but it's very messy at the moment. The optimization all happens in download(), which means that getNumNotes() and getMemUsage() have no idea about it. Not sure if it'd be better to like build it in at the tail end of parsing? Maybe a little optimized note cache that would need to be updated on voice changes and stuff?