Documentation - JOSS Paper

[TGabor]

Here are some small comments regarding the JOSS paper submission:

• l.25-l.27: please clarify or add an example where the lossy conversion through musicXML poses a problem in the proposed workflow. In the paper, it is not clear why this could not be solved with MusicXML. I would guess that especially when you need to edit the MuseScore file in ms3, an intermediate step through MusicXML would make certain operations impossible or destroy some parts of the score layout.

  • l.29-30: DataFrames are not necessarily feature matrices. The feature matrices extracted by ms3 are represented as DataFrames.

  • l.31: "... to enable version control" sounds a bit like TSV is required for version control. It definitely simplifies it and it is also much easier to see differences between the annotations across different commits. Could you make this point a bit clearer?

  • l. 35 "write back" -> "save"

  • L.35: To me the term "data translocation" is not clear. Do you mean conversion?

[johentsch]

addressed via 4fea2211..626c772f

I decided to leave your first remark unaddressed because, in the context of research data, "lossy conversion" suffices as an exclusion criterion.

[TGabor]

@johentsch I disagree that “lossy conversion” suffices as an exclusion criterion for research data. For example, if you’re only interested to derive some musical features independent of the layout, then it should be sufficient to rely on a lossy conversion that only affects the layout. I see that it will be especially important to have a lossless conversion once you want to write modified annotations back to the original MuseScore file. But this is not clear in the motivation in l.25

[johentsch]

The raison d'être for a MuseScore parser is that no other software parses MuseScore format. The musicXML discussion is misguided.

[faroit]

@johentsch hooking into this discussion here:

in the paper you state:

For example, the Free and Open Source Software MuseScore provides a full-featured yet intuitive interface for engraving music, but its native XML format does not explicitly encode the temporal positions of events such as notes and rests. Hence the need for a parser that extracts the implicit information and stores it in an interoperable format.

Despite being one of the most wide-spread score encoding formats, current score parsers [e.g., @Cancino-Chacon2022_PartituraPythonPackage; @Cuthbert2010_Music21ToolkitComputerAided; @Pugin2014_VerovioLibraryEngraving], do not handle it without first performing a lossy conversion to the musicXML format. The Python library ms3 fills this gap.

I agree that having only lossy conversion parsers, is indeed sufficient as a motivation to write a new one. However, for readers out-of-domain (like myself), I am with @TGabor, that a short, easy to understand, example where that loss would matter and what ms3 enables specifically that wasn't possible with existing parsers, would be helpful.

[faroit]

@TGabor are the changes in e8c11a8 sufficient for you?

[TGabor]

@johentsch Thanks for the updates! I think this is clearer now. 👍

@faroit yes, lets go ahead!

[johentsch]

Thanks for your feedback, @TGabor and @faroit. I hadn't pinged you after my changes because I took #66 as an occasion to reorganize the tests. It's done locally and they'll come out with v1.3.0. Today or tomorrow. Could we wait until then, @faroit?