Re: A must-see for anybody on this list

[Urs Liska]

Am 14.02.2013 17:21, schrieb Joseph Rushton Wakeling:
> On 02/14/2013 04:44 PM, Urs Liska wrote:
> > While it may not seem to be intuitive you can actually write 
> > extremely robust
> > "house style" sheets (or rather libraries which I find much more 
> > reliable than
> > any preset templates or whatever you could use with WYSIWYG software.
> > With the additional advantage that you can (quite) easily apply 
> > changes to that
> > style sheet to existing scores.
>
> I'm sure that's true.  There's a difference between 
> robustness/reliability and "easy", though ;-)
Sure. But in the context of a professional publishing house, "easy" 
isn't the crucial point.
Besides being robust and fully documented, I'd say "maintainability" is 
an important issue. And I know that my views on that topic are quite 
biased (pro LilyPond) ...
> > One thing that could be stressed as a "selling point" towards 
> > publishers is the
> > "diffability" of Lilypond sources. I find it extremely interesting to 
> > have the
> > possibility of git-driven editing/publishing work-flows. Last year I had
> > communication with a Henle official who told me that they have a very 
> > fixed
> > work-flow which consists of a) the editor preparing his edition (in 
> > whatever
> > form), b) Henle preparing the engraving according to their standards, 
> > and c) no
> > less than six proof-reading cycles.
> > I think such a work-flow could profit extremely by a scenario where 
> > all involved
> > people work on the same codebase - the editor preparing the score 
> > with LilyPond,
> > the engraver beautifying directly in this codebase, and all 
> > proof-readers having
> > access to that too.
> >
> > I will soon pick up on that communication, and then I'll surely raise 
> > the
> > engraving issue, showing them some of my 'raw' scores, Janek's 
> > beautiful final
> > versions and maybe some exemplary git commits.
> > I don't expect this to have immediate impact, but who knows ...
> >
> > I will also prepare a presentation on 'plain text based work-flows 
> > for writing
> > (about) music' that I will do at my university, and I intend to also 
> > present
> > this personally to a few people occupied in scholarly editions. Such
> > collaborative approaches are perfectly suited for git-based work.
> > It would be good to get the attention of such institutions, as they 
> > might have
> > some influence on publishers' decisions (although I know that this 
> > influence is
> > actually quite small ...).
>
> Funnily enough I had very similar thoughts about this (I had a 
> discussion with Valentin along these lines some years ago as well as 
> some people in the scholarly music community).  My focus was very much 
> on things like Urtext editions, and it was part of a broader set of 
> thoughts about scholarly communication.
>
> Do let me have a copy of your presentation -- I'd like to cite it in 
> some work that I'm preparing on these kinds of issues.
Maybe I'll get in touch with you before. I already intended to present 
the outline of the presentation here and ask for feedback - I think it's 
an issue that concerns many of us ...
(The presentation is due at the end of April, so it will be some time 
still).
> > In the meantime I repeat that it would be a very valuable thing to be 
> > able to
> > export the (raw) music of a LilyPond score to MusicXML.
> > Maybe I wouldn't have decided so easily to switch to LaTeX if I 
> > hadn't known
> > about the possibility to export my documents to word processor formats.
> > For example I think it would be easier to convince academics that it 
> > is a good
> > idea to prepare an edition (collaboratively) using LilyPond and git 
> > if they know
> > that they can still export the result to a publisher who insists on
> > Finale/Sibelius.
>
> I'm not familiar enough with MusicXML to understand: how much 
> potential is there for lossy changes in the conversion process?
>
> I ask because my honest feeling is that unless the conversion is 
> guaranteed to be rock-solid, you're probably better off using Lilypond 
> to prepare a "manuscript" master copy which is then re-set by the 
> publisher's engraving staff using whatever methods they like.  The 
> unfortunate side of that is that it loses the possibility for 
> diff-based corrections and updates to the edition.
From the discussion on this list I assume that there are two very 
different 'stages' to this. One is the raw musical content, which seems 
to be quite easily converted (I think something like an XSLT-like 
transformation of LilyPond's music stream).
If one wants to also export LilyPond's layout qualities it would be much 
more intricate because at the time LilyPond makes its layout decisions 
that music stream isn't available anymore.

But I think the first option would be perfectly usable (at least in the 
context of our discussion) to be able to prepare the score with LilyPond 
and give the publisher a working file that he can apply his house style 
templates to and finish with his own man-power and knowledge.
Preparing a "manuscript" with LilyPond isn't the way to go because 
nowadays many (most) publishers won't pay engraving staff when they also 
can get editors doing that work for free. (This actually is the reason I 
didn't get a contract for editing a few works for UE).

Best
Urs
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user