Currently for MusicXML import, we are able to go from MusicXML to Alda []ScoreUpdate. The following 3 PRs combined will introduce an Alda code generator to complete the import process:
The generation is mostly straightforward, with a few points to note:
As commented, AldaSourceContext is ignored in generation. I think this is a very fine choice.
Processing parts and voices is a little non-trivial. I tried to do it in the cleanest way, but essentially the generator must "reconstruct" an ASTNode because ASTNode.Updates "flattens" this information in ScoreUpdates.
PartUpdate to LispListNode
We only handle conversion for PartUpdate's that are introduced by the MusicXML importer.
We also add KeySignature.String() so that we can generate the correct literal for the corresponding LispStringNode of a KeySignatureSet.
test_helper.go
I've slightly refactored/generalized parser's tests in parseTestCase in test_helper.go:
Now providing actual ASTNode or []ScoreUpdate is optional. These are tested if provided. Otherwise, we just test that everything works and that the generated ASTNode is equal the parsed ASTNode.
We now always test applying ScoreUpdates to a Score (with an opt out). I also changed a couple test cases so that they could be applied to a score. Let me know if we want it changed.
examples_test.go which tests the example files now uses parseTestCase.
e2e
We've talked about a complete refactor of testing to spin-off an e2e testing module downstream of both parser and model. I think the changes we have now are "good enough" that this change is not quite worth it for now, given my timeline. I've left it as a TODO.
Background
Currently for MusicXML import, we are able to go from MusicXML to Alda
[]ScoreUpdate. The following 3 PRs combined will introduce an Alda code generator to complete the import process:This PR is the first step of the process, introducing
[]ScoreUpdate->ASTNodeconversion via the following function inparser/gen.go:Notes
gen.goThe generation is mostly straightforward, with a few points to note:
AldaSourceContextis ignored in generation. I think this is a very fine choice.ASTNodebecauseASTNode.Updates"flattens" this information inScoreUpdates.PartUpdatetoLispListNodeWe only handle conversion for
PartUpdate's that are introduced by the MusicXML importer. We also addKeySignature.String()so that we can generate the correct literal for the correspondingLispStringNodeof aKeySignatureSet.test_helper.goI've slightly refactored/generalized
parser's tests inparseTestCaseintest_helper.go:ASTNodeor[]ScoreUpdateis optional. These are tested if provided. Otherwise, we just test that everything works and that the generatedASTNodeis equal the parsedASTNode.ScoreUpdates to aScore(with an opt out). I also changed a couple test cases so that they could be applied to a score. Let me know if we want it changed.examples_test.gowhich tests the example files now usesparseTestCase.e2eWe've talked about a complete refactor of testing to spin-off an
e2etesting module downstream of bothparserandmodel. I think the changes we have now are "good enough" that this change is not quite worth it for now, given my timeline. I've left it as a TODO.