Need to be updated to the latest version.
See: https://github.com/madrisan/open-scores

Ok, found here.

Can you add a commit to this PR to add the latest changes you made?

Definitely yes, now that the MutopiaProject has been reborn :), I think I will invest some time in porting everything I have digitised over the past two years.
The only big problem I notice is the support for the 'Letter' format I see at www.mutopiaproject.org/.
I did not foresee anything other than a display on a tablet (my regular use).
I will try to look at how this is handled. Any hint?

Good to know you'll contribute again! I see that you work on CI/CD stuff... We definitely need a Github workflow setup for Mutopia to make PR reviews easier. I've started looking into mupub, but I'll need some help sooner or later.
I think I'll open a new issue to sketch a roadmap once I have a better idea of how the current infrastructure works.

Mutopia provides PDF files in A4 and US Letter formats so you should check that your scores look good in these two formats. The tablet is not considered as a target device so if yours scores contain hacks for the tablet display I think you'd better remove them when you submit your scores to Mutopia. Don't know if I answered your question...

There is no hack to enforce a 'tablet' format, but my scores are intended (optimised) for an A4 format.
For example, I try to match the end of musical phrases or blocks with the end of lines (or pages).
And page settings are often adjusted to optimise the number of pages and the visual output of the partition.
I will try to see how to do it without losing any functionality.

Regarding CI/CD, yes I can help I think even though I work in the GitLab environment at Qwant.
But I think it would be an interesting project for me. Please let me know.
You could perhaps enable the discussion tab in the project (hoping not to be invaded by spam.)

Should be good for a merge now.

@fedelibre I'm testing GitHub Worlflows as a usable CI for this project.

@fedelibre I'm testing GitHub Worlflows as a usable CI for this project.

Ok, interesting. But I think that eventually we should use the same build tool used for the Mutopia website, that is mupub. It's not been developed for a while, but we are discussing some needed updates.

Ok @fedelibre . My idea was to execute mupub by a GitHub workflows indeed.
The current build action, using the lilypond binary is just a simple test.

A CI with mupub is a headache :) so I am hanging this test for the moment.
The PR is finalized.

Thanks for your contribution.

I don't have any experience with reviewing new Mutopia contributions, so I'm adding @dominicus in case he finds some time to give some feedback.

These are my thoughts:

• Every lilypond file should have a \version statement at the beginning of the file. No matter how simple it may be, if there's a \version then it will be possible to update the file in the future. I see that mupub check returns a warning when the version is missing.
• I would reduce the number of .ly files if very small, such as covercolor.ly and global.ly. coverColor is used only once and can be moved to the main file. The override in global.ly might be turned into a function in the main file?
• I don't know if the Open Scores cover page is suitable for Mutopia. I have nothing against it and it looks nice. I just wonder if there's a common style that should be kept for Mutopia.

Hello, sorry for the delay. I was on holiday.

Every lilypond file should have a \version statement at the beginning of the file

Why would a duplication of code be a good idea? The risk is that the various versions will not be synchronised.
I noticed that mupub check returns a warning, but not lilypond, so I'd say it's a bug in mupub.

I would reduce the number of .ly files if very small

This modularization is convenient for me

• global.ly is loaded from each file in the parts folder, so merging it with another file means that I will no longer able to compile a single parts file, which is useful when digitising partitions or fixing issues.
• the covercolor.ly file is generated by the configure script in my source repository.

I just wonder if there's a common style that should be kept for Mutopia.

Two years ago I had taken a tour of the Mutopia partitions and found no common ground. I took my inspiration from what I found in some digitisations that I found better realised. For example the footer providing the licence.

I am not so motivated to change the seventy or so digitisations I have in my pipe to merge into Mutopia. ;)
Especially since the skeleton is now generated by a script I developed to make my life easier.

Every lilypond file should have a \version statement at the beginning of the file

Why would a duplication of code be a good idea? The risk is that the various versions will not be synchronised. I noticed that mupub check returns a warning, but not lilypond, so I'd say it's a bug in mupub.

It's just a simple single line, nothing complex. I would not call it a duplication. It's like a shebang in a bash or python file.
On the other hand it's considered an important best practice by LilyPond developers. In fact it's the first item in the general suggestions to write LilyPond code:

Always include a \version number in your input files no matter how small they are. This prevents having to remember which version of LilyPond the file was created with and is especially relevant when Updating files with convert-ly command (which requires the \version statement to be present);

I'm Ok with the rest of what you wrote.

@madrisan I see you added the \version statement in the parts/*.ly files, but you should add it to all the lilypond files in the parent folder. Thanks.

I don't have any experience with reviewing new Mutopia contributions, so I'm adding @dominicus in case he finds some time to give some feedback.

• I don't know if the Open Scores cover page is suitable for Mutopia. I have nothing against it and it looks nice. I just wonder if there's a common style that should be kept for Mutopia.

@fedelibre I think adding a cover page is OK on a multi-movement piece, but I'm recommending we find an agreeable way to skip the reference to Blue Lavender Open Scores in the Mutopia PDFs. Perhaps @madrisan can add commented-out spacing code Mutopia maintainers can uncomment as we process the PRs. I'm not sure if I'm explaining this correctly, but there's ways to delineate code blocks so one can quickly spot code sections where you want to toggle comments to show/hide on this cover page. This way the project branding can show in Blue Lavender PDF, and be empty space in Mutopia PDF. I've added #1128 to discuss this topic of cover pages, URLs and capture feedback others have.