On Thu, Apr 23, 2015 at 01:55:57PM +0200, Gilles wrote:
[...]
> Of course, if you are used to it, nobody forces you to change. The
> suggestion was certainly that LilyPond should forbid all input other
> than the "standard" ("best practice") layout.
>
> [Yet I want to stress that what you seem to describe is exactly what a
> LilyPond GUI would do; I mean that the GUI designer has chosen a
> structure (like you did) so that the code knows where to fetch and to
> put things. You do it "manually".]
>
> Everything in one file is not a solution that can scale (e.g. for
> large, possibly distributed, encoding projects).
[...]
Yes, I'm aware that my approach probably works well because I'm the only
one working on the file at a time. :-) It's harder when multiple people
are involved. Though, even so, I suspect that with proper use of tools
like git that allow distributed 3-way merges, some of this difficulty
can be alleviated.
But clearly, for multi-person engraving projects it would make sense to
separate things out into multiple files, perhaps one file per instrument
per movement, or something along those lines.
My point, though, was that such a sophisticated layout is unnecessary
for simple projects, and may even be detrimental -- new users will be
overwhelmed by having all these files lying around when all they wanted
was to engrave a 1-page piece.
I think it's better to have a section in the manual describing best
practices for a variety of scenarios: 1 file for short piano solos, or
single-person small/medium-sized projects, multiple files for larger
projects, etc.. There's already some templates in the current docs, but
I find them far from complete -- for instance, the one example of an
orchestral score (for piano and orchestra) fails to address a lot of
issues that may come up, like how to use \partcombine effectively, how
to lay out instrument parts, what to do about cue notes, how to actually
generate instrument parts, etc.. We also need adequate examples of
piano scores that show how to deal with more complex issues like
cross-staff beaming/slurring, etc.. These issues *are* described in the
docs, but they are buried deep in obscure corners that aren't very
obvious is where one should look to find them.
T
--
I am not young enough to know everything. -- Oscar Wilde
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
