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. 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
