Prep mozart kv488 #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: Generated with `cp -r contrib/templates/ensemble/ ftp/MozartWA/KV488`. A subsequent commit will make appropriate modifications for this opus. Test Plan: From `ftp/MozartWA/KV488`, running `lilypond composer-opus-conductor.ly` generates readable output.
Summary: This commit adds files for each movement and instrument, so it should be the case that all that’s left to do is to fill in the notes! Test Plan: Check that compilation is successful: ``` $ cd ftp/MozartWA/KV488/ $ ! lilypond MozartWA-KV488-*.ly 2>&1 | grep -e warn -e err $ ls -1 MozartWA-KV488-*.pdf | wc -l 10 $ ls -1 *.midi | wc -l 3 ``` Verify in the conductor score that all parts are present, and verify that the clarinet and horn parts are transposed to A in both the individual part scores and the main score.
Summary: This commit adds a script `create_makefile.sh`, whose output is a Makefile whose dependency graph represents the LilyPond project structure. This exposes convenient commands like `make` and `make parts` and `make midi`, ideally with minimal spurious computation. In the current project structure as inherited from the ensemble template, the three `music.ily` files form hourglass dependencies: for instance, the violin part depends on `01_allegro/music.ily`, which depends on `01_allegro/piano.ily`. Even though changes to the latter will have no effect on the actual violin part output, the dependency structure hides this fact, so recomputing `make parts` will do lots of unnecessary work. In a subsequent commit, we will refactor the project structure to avoid this problem. Test Plan: Running `make test` passes. Adding `r4 |` to `01_allegro/piano.ily` causes `make test` to fail.
Summary: This commit restructures the `music.ily` files such that they only contain `\include` directives. This enables their dependents to instead depend on only a more precise subset of the `\include`d files, reducing the scope of the dependency. Test Plan: Running `make test` passes, and the output is unchanged.
Summary: This commit removes the references to the `music.ily` files, which served as hourglass dependencies and required unnecessary recomputation. Test Plan: Run `make parts`, then `touch 01_allegro/piano.ly`, and `make -n parts`. Note that before this commit, all parts would be re-typeset, but after this commit only the piano part will be.
Summary: Invoking LilyPond on all the entry points takes a while already, and is only going to keep taking longer. This commits separates the `test` target into `test` and `quicktest`, the latter of which will run much more quickly (at the expense, of course, of doing less testing).
Summary: My fingers are used to typing `make quickcheck`, so we might as well add this alternative.
Summary: This enables using library files like `articulate.ly` without adding dangling edges in the dependency graph. Test Plan: Run `./create_makefile.sh` and note that the `Makefile` is unchanged, because there are currently no library dependencies.
Summary: Because `layout-set-staff-size` does not adjust staff line spacing, the output looks quite bad when the two values differ. If the global staff size is set to be smaller than the layout staff size (as was the case prior to this commit), then notes on adjacent lines/spaces will overlap each other. This is particularly visible and ugly with whole note chords like `<c e g>1`. Quarter-note chords look bad, too. In this commit, we change the layout staff size from 17 to 14 to match the global staff size. Adjusting the global staff size would require recomputing the dimensions for the cover page and table of contents, so we opt for the path of least resistance for now.
Summary: Later notation caused the page to flow such that this created a “no viable initial configuration found; may not find good beam slope” warning. The produced beaming was okay, but this looks better (in my opinion), and also happens to better match the original score.
Summary: We can add this script only now, because the first movement has been completed. Similarly, we will only be able to add checking for each later movement once it has also been completed. Test Plan: Running `./assert_consistent_marks.sh` or `make quickcheck` passes as is, but if a `\barNumberCheck #1` is changed to `\barNumberCheck #2`, then these invocations fail with one “missing” message and one “superfluous” message, as desired.
Summary: In addition to this being an intrinsically useful piece of output, it also gives us some “finished products” in the time before the next two movements are finished. The only downside is that it roughly doubles the build time of `make all` and `make check`.
Summary: This way, changes to just one movement will not require rebuilding MIDI for all movements. This also simplifies the build logic; MIDI is no longer a special case (merely another case).
Summary: This change makes the code somewhat shorter and somewhat more readable: we now always reference files that exist on disk. The emitted Makefile is unchanged.
Summary: This reverts the commit that added short instrument names to all systems, serving its purpose in a different way: we now treat the woodwinds, the piano, and the strings as three atomic units whose staves must be hidden or shown collectively. The result is a cleaner score that is closer to the original layout. The code for `AtomicStaffGroup` is hacked together by observing `engraver-init.ly` in the LilyPond source tree, and the LilyPond documentation for defining new contexts.
Summary: This simply prevents `rm`-spam at the end of a Make invocation.
Summary: This commit was created by running ```shell sed -i -e '/articulate\.ly/n; s:\\include ":\\include "../:' parts/*.ly ``` after the obvious `mv`. The build script had to be updated considerably to deal with files whose outputs are not in the same directory as the input. (That is, if you run `lilypond a/b.ly`, then the output is in `b.pdf`, not `a/b.pdf`.)
Renamed primary conductor file (my bad!), adjusted makefile support Added preview image
|
I don't think this worked as I expected --- it is showing too many commits/changes. I think I need to redo this by making these changes on a branch in a separate clone, different from my base repo. |
|
Looking at this again, perhaps this is okay. GITHUB confuses me with statements like "glenl wants to merge 88 commits..." when, in fact, I only want to commit one small set of changes. Anyway, I'll re-open and let you review these. |
|
No longer needed, pull request is in-process at MutopiaProject. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I apologize for the additional rename of the conductor file -- my fault for the bad information. I've modified your makefile creation script and verified the build. Our build publishing build works as well.
I've submitted this as a pull-request to your branch so you can review and modify anything before actual publication. At this point it is ready and processing the pull to your branch will constitute a positive review.
Some notable changes:
One other small note: we typically assign the mutopia id on publication. You picked a valid ID and I just have to make sure it is processed in order to prevent duplicates. (Let's just say it is an international process...) Future new submissions can simply specify an ID of 0 and our process will assign an appropriate ID before publication. The
footer,copyright, andtaglinealways get updated and replaced on publication in case we change the copyright markup.