Re: (hypothetical) Availability of LilyPond engravers

[Urs Liska]

Am 17.04.2015 um 16:10 schrieb Kieren MacMillan:
> Hi Urs (et al.),
>
> > In any projects not all contributors have to be proficient with all aspects, 
> > particularly not with beautifying the final output.
>
> Agreed.

Yes, and that is an important point when you are promoting the feature 
of "clustering" manpower. People were quite impressed when I told them 
that we happily and mostly without hassles integrate contributions by 
people of extremely different background and level of progress.

> > Nevertheless people should be able to provide their input without requiring too 
> > much hand-holding and without producing an inappropriate amount of errors.
>
> That, but also more. They should at least have:
>
> a good understanding of best (or at least better) practices in terms of 
> structuring the Lilypond code
> (unless that was done for them beforehand, and they’re just “filling
in the blanks”);

Good point.
In "Das trunkne Lied" we're doing the latter as we have generated our 
(67 x 90) input files programmatically, with a script that was fed by 
one hand-written "structure voice" and produced the individual file 
through applying that structure to templates.
This works well when large amounts of music and want to break it down to 
very small, digestible units. I think I'd do it always like this with 
larger orchestral scores, after having our code more generalized. But in 
general it is of course preferable when people can do their work 
self-organized.

> a good sense of when a manual process might be replaced efficiently and 
> effectively with an automated one
> (e.g., a new function or engraver), even if they can’t create that 
solution themselves; etc.

+1
Or at least the sense of when to ask.

> Unless I had seen several examples of the Lilypond code (not just output!) that 
> someone had generated recently,
> I wouldn’t even consider sending them a hand-written manuscript to engrave from 
> scratch.

This is a quite valid concern, I think.

In our crowd project we prescribed a certain coding standard, but 
without enforcing it. I have to say that it didn't match my own so-far 
practice, but it became absolutely apparent that it is so helpful if 
others' code (usually) just looks like your own (well, that's something 
any software project would take for granted).

I would even be more strict in future project and define things like the 
order of attachment of object types (e.g 
note->articulation->dynamic->slur->beam->tie or whatever).

OTOH it would be cool to have a "linter" script for LilyPond code. But I 
think we'll have that (nearly) for free once python-ly is reliably able 
to _write_ LilyPond code.

Urs

> Cheers,
> Kieren.
>
> _______________________
>
> Kieren MacMillan, composer
> www:  <http://www.kierenmacmillan.info>
> email:  address@hidden


--
Urs Liska
www.openlilylib.org