Hello.
On Wed, 22 Apr 2015 21:19:12 +0200, N. Andrew Walsh wrote:
I started using Lily for serious maybe a month ago, so I'm what you'd
call
new. I find the guide far more useful than the manual (the former
seems
more structured around how to do specific things, while the latter
seems
much more a general conceptual introduction).
However (and this is something I mentioned on a couple recent message
exchanges), I feel that neither one of them gets me very far past
making a
single monolithic file using defaults. There's been a lot of mention
(I
imagine rightfully) about how Lily is capable, above all, of making
beautifully engraved scores, and her suitability to managing a
text-based,
distributed, and version/change-tracked workflow. All of that sounds
awesome, but I don't see anywhere where that's comprehensively
documented.
Let's take my case: I'm transcribing masses from some obscure
composer from
the 18th century. There are no extant scores, only the parts (which
ironically works better for Lily's structure). I want these scores to
look
their absolute best, and the underlying files to follow the best
practices
for structure and organization. I want to put the score and parts
alongside
the work of a commercial (read: Sibelius-using) house and have it be
unambiguously a better-looking and standards-conforming result, and
be able
to show the incredible flexibility and rigorous flow-control that
using the
underlying system can offer.
I don't see anywhere in the reference or the manual where that sort
of
comprehensive style guide is presented. I'm thinking something like
the
doorstops O'Reilly's uses for documenting, say, HTML. I hate to use
the
term (it's already been ruined by bureaucrats), but what I'm really
looking
for is a comprehensive "best practices" style guide for how to
organize
larger scores.
Best practices, yes; for any score (not just large ones).[1]
A flexible structure that would be "compelling" and foster the creation
of
"compliant" tools.
Is it GridLY? [Cf. other post.]
Regards,
Gilles
Urs, I think this would probably dovetail nicely with your efforts to
build
a pool of competent engravers, as we would then all be working from
the
same style guidelines.
But that's just my use-case. Maybe there are others?
Cheers,
A
On Wed, Apr 22, 2015 at 9:03 PM, Urs Liska <u...@openlilylib.org>
wrote:
Am 22.04.2015 um 20:48 schrieb Federico Bruni:
Hi Abraham
I've been using LilyPond since 6 years.
I think that LilyPond documentation is great. Learning Manual is a
gentle introduction (basically 3 chapters only) for new users and
Notation
Reference is a complete reference, well indexed and easy to search
through.
I never found anything better (which is as complex as LilyPond).
I am quite in line with that impression. I don't think the
*documentation*
can be *much* better in general. However, there are a few things
that would
help new users (I think it would be very good if some of these could
also
comment on this thread).
It would be helpful if there were more learning material that has a
slower
pace and into more depth at explaining things than the notation
reference.
The Learning Manual is very good, but when that's finished people
are not
ready to walk alone.
That's what I intend with the tutorials section on the blog, but of
course
these posts are only drops in the ocean. But better than nothing.
I could also see something like a community book emerging from these
tutorials, but I'm not sure how well this would work out.
Urs
2015-04-22 17:09 GMT+02:00 Abraham Lee <tisimst.lilyp...@gmail.com>:
All,
I've been thinking about this a lot lately, even going so far as
to
create my own "Quick Start" tutorials for new users, but I can only
go so
far in my own head. I really have two questions that I keep
wondering about:
1. What is the thing you (especially new users) like the least
about
LilyPond's documentation structure?
2. If you could have the same documentation structure as found
in
another notation program, which program is it? Or put another
way: Is there
a notation program out there that has a documentation structure
you like?
1. The missing connection between input and output, in other words
something similar to the experience of point-and-click in an editor.
Yes,
this is not about structure. I think that structure of NR is Ok.
Also, syntax highlighting would help readability:
https://code.google.com/p/lilypond/issues/detail?id=2578
https://code.google.com/p/lilypond/issues/detail?id=1005
2. no idea
1.
I'm asking this because I'm trying to determine how we in the
'Pond can
make it easier for new users to jump in with both feet instead of
dipping a
toe and getting scared of the deep.
I may be over-thinking this, but I keep getting the feeling that
people
are scared of using LilyPond partially because the documentation,
though
deep and detailed, is a little too deep and technical for new users
who are
familiar with a GUI program and less familiar with programming.
I think that the best way for that kind of users is starting from
screencasts:
http://benlemon.me/blog/music/lilypond/operation-lilypond
What I would find useful is an interactive guide to lilypond
syntax:
https://code.google.com/p/lilypond/issues/detail?id=4200
_______________________________________________
lilypond-user mailing
listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
