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: i...@kierenmacmillan.info
--
Urs Liska
www.openlilylib.org
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
