Like most software, there is always something more that can be done. Below is such a list for lilydumper/lilyplayer.

In the part about how to find out where notes are, we saw that the event-listeners sets the grob id that will appear in the svg files to add the x-width and y-height to it, so it can later be retrieved from the svg file. This is actually unnecessary as these can simply be written to the notes file. And then using the point and click option, it is possible to retrieve where the note is in the svg by looking for a elemts with an xlink:href attribute (instead of looking for g element with an id attribute). This should be priority number one on the ameliorations to implement as it makes for simpler and more reliable code. In fact changing the id of the grob is either not possible anymore on newer versions of lilypond, or works differently, so that lilydumper is broken when using latest lilypond.

The svgs files generated by lilypond are quite big. An svg optimiser like svgo showed that svg files could sometimes be reduced in size by a factor of 4 without noticeable changes. This would make the file smaller and rendering the pages faster.

The svg files used in the lilydumper output are taken straight out from lilypond. If one day lilypond starts including markers in the output, or if the input file would do such a thing, this marker would then leak into the file. Therefore using a tool to only keep the relevant part of the svg that impacts the visible output would be of interest.

We saw that lilydumper had to run lilypond thrice:

• once to find out when to play each note
• once to find out where the notes were on the music sheet
• once to get the clean music sheet

Running lilypond takes time and it is possible to get clean music sheets out the ones used to extract the notes placements automatically. That would avoid the need of running lilypond the third time.

Right now, lilydumper ignore crescendo / decrescendo ... events. As a consequence, all notes are played with the same intensity. This could be nice to add.

Running lilypond takes time, as alaready said. And these runs are sequential. However with multicore processor, there can be some gain in running them in parallel.

When extracting data, for example notes from the music sheets, each page are processed sequentially. Since the data extraction from one page does not impact the other ones, they could be done in paralle. However this processing time is small in comparison of the time it takes to run lilypond, hence there might not be so much gain here.

It could be nice to have the source file automatically included in the generated file, so it becomes possible to "edit" the file.