Re: A big advantage to lilypond

[Simon Albrecht]

Hi Daniel,

On 22.03.2016 01:46, Redwood (Daniel) wrote:
> But I wonder: why aren’t more lilypond authors posting more of their sources to 
> IMSLP?

personally, I’m often reluctant to do so, because I might want to 
distribute my typesets commercially. In my opinion, _good_ music 
typography is an art and science and worth paying for; also I create an 
own visual style with my typesets that I don’t want others to easily 
discard. It’s a generous thing to typeset music and publish the source, 
but it’s perfectly valid to not do so and keep it private.
There’s also a technical side to it: (nearly) all of the scores I 
typeset rely on my personal stylesheets library, which I also feel 
somewhat protective about, and it’s impractical to include all of it in 
such an upload, or make a specific version containing only that which is 
really needed…

>   And is there some way to find the lilypond source files — the pieces that 
> have lilypond sources. I found some through their postings on a French site 
> (can’t think of the name now), but it’s on about a dozen pieces, none of which 
> interest me.

There are a few sources beside IMSLP that may be considered:
Mutopia has already been mentioned.
Nicolas Sceaux’s ‘Nenuvar’ editions <https://github.com/nsceaux/nenuvar> 
– that’s likely the one you were referring to.
Nancho Álvarez’ ‘Victoria’ site <http://www.uma.es/victoria/index.html>
Also, sometimes you find .ly sources on CPDL as well.

> Music I’m going to perform, I usually typeset anyway, partly as a way to learn 
> the music. But much of what I play is for my enjoyment, and I don’t rescore it. 
> Also, much music like Beethoven sonatas are a great deal of trouble to 
> score/typeset.

Another point to consider: why would you want to do new typesets? E.g. I 
have no (or very little) understanding for anybody to retypeset works by 
Brahms, since there’s the superb 1927 complete edition, which is not 
only typeset to the highest possible standard, beautiful and legible, 
but also to my knowledge doesn’t have any problems regarding musical 
text. Admittedly often the problem is that you have to choose between 
/either/ good typography in older editions /or/ reliable musical text in 
newer editions, with old editions being error-prone or convoluted with 
additions, and new editions being a typographical nightmare, which I 
find hard to stand as well.
But of course you will know yourself what you want to retypeset, and why.

And lastly: even if I can obtain a ly source file from somewhere on the 
web, I sometimes have to rework the entire code, before making any use 
of it (and then I wonder if I’d been better off to just input it 
myself). Sometimes the coding is objectively sloppy, convoluted, or 
difficult to read; sometimes it’s just because of different coding 
styles, or approaches to representing the music[1], which can pose 
extremely annoying obstacles in sharing code. And the python-ly 
(Frescobaldi) formatting tools only get you so far (great though for 
doubling durations, or absolute->relative, or the like).
Which is why I very much think we need higher standards in that area…

Yours,
Simon

[1] E.g. in ancient (mensural) music: One finds scores with one bar per 
line, and with the splitting of ‘cross-bar’ notes hardcoded into the 
LilyPond source. However, that badly reflects the intent of the original 
notation, and prevents making editions without complete bar lines and 
without splitting notes from the same source. It’s such a fortune that 
we have the Completion_heads_engraver to do exactly that which 
contemporally would have been the way to go from parts (without 
barlines) to scores (with barlines and split durations). And so I have 
been changing thousands of lines of code to use this facility. The ‘one 
bar per line’ approach is sensible for some kinds of music, but it’s 
definitely not sensible for mensural music with such a different notion 
of timing concepts.
Also, it’s often unclear whether to code different sections of a work as 
separate scores or not, with both having different implications for 
titling, instrument names, file structure…