Re: Examples (for the web site and complete scores) status
Op donderdag 06-08-2009 om 00:08 uur [tijdzone -0700], schreef Graham Percival: IMO, there are two kinds of examples here. 1) advertizing examples: we can do tabs, complex rhythms, lots of accidentals, gregorian chant, etc etc. We expect people to glance at the image and then move on. 2) educational examples: part of the documentation. We expect people to read the source if they're interested. You missed 3) benchmarking/full feature examples/developer's/user's smoke tests input/mutopia/F.Schubert/morgenlied.ly input/mutopia/J.S.Bach/baerenreiter-sarabande.ly input/mutopia/typograhpy-demo.ly I'm a bit unhappy with the commit messages Remove mutopia Remove examples First, these commit messages tell me nothing more than the diff itself: stuff is being junked. It would be interesting to know why it is junked, why this does not remove any interesting information, or where copies can be found. We are junking things like - texidoc = The B\\\arenreiter edition of the Cello Suites is the -most beautifully typeset piece of music in our collection of music (we -both own one. It is also lovely on French Horn). This piece does not -include articulation, but it does follows the same beaming and -linebreaking as the printed edition. This is done in order to -benchmark the quality of the LilyPond output. - -As of lilypond 1.5.42, the spacing and beam quanting is almost -identical. - -There are two tweaks in this file: a line-break was forced before -measure 25, we get back the linebreaking of Baerenreiter. The stem -direction is forced in measure 24. The last beam of that measure is up -in Baerenreiter because of context. We don't detect that yet. - -Note that the Barenreiter edition contains a few engraving -mistakes. The second line begins with measure 6 (but prints 5). The |: -half way in measure 13 has been forgotten. - are you sure you want to just junk these things? I for one would consider it a very bad regression if this baerenreiter sarabande example would ever compile to something less beautiful than it does now. Of course, regression is the end of all tests. However, after a major hack, as a developer you would want to make sure that typography-demo produces something worth-wile again. Also, I think it always had the feature of using all stencil backend functions, so you'd know during a hack how far you are. The sarabande has been a good smoke test for me. If you meant to move some of these, it is /much/ nice to preserve history, rather than copy or later re-introduce [ie, revert these commits and do a move]. Also, I'm not sure why the totally obvious input/example-*.ly had to go. This seems to me as being such a nice-no-need-for- documentation-nobrain place to get going? After an install on a new/foreign machine, I would do lilypond /usr/share/doc/lilypond/input/example-1.ly [and/or some other files from input/]. Why does this have to change, and why did this happen without any mentioning of what the new mantra is like? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Examples (for the web site and complete scores) status
On Mon, Oct 12, 2009 at 12:43:12PM +0200, Jan Nieuwenhuizen wrote: Op donderdag 06-08-2009 om 00:08 uur [tijdzone -0700], schreef Graham Percival: IMO, there are two kinds of examples here. 3) benchmarking/full feature examples/developer's/user's smoke tests input/mutopia/F.Schubert/morgenlied.ly input/mutopia/J.S.Bach/baerenreiter-sarabande.ly input/mutopia/typograhpy-demo.ly Then these can go in input/regresssion/ ... as it happens, I already added typography-demo.ly because some files in regression/ relied on it. They're easily rescued from the 2.13.5 tag. Remove mutopia Remove examples First, these commit messages tell me nothing more than the diff itself: stuff is being junked. It would be interesting to know why it is junked, why this does not remove any interesting information, or where copies can be found. Good point; I should have added a link to the mailist discussion about such removals. We are junking things like - texidoc = The B\\\arenreiter edition of the Cello Suites is the -most beautifully typeset piece of music in our collection of music (we are you sure you want to just junk these things? I for one would consider it a very bad regression if this baerenreiter sarabande example would ever compile to something less beautiful than it does now. Then it surely belongs in the regtests. If you meant to move some of these, it is /much/ nice to preserve history, rather than copy or later re-introduce [ie, revert these commits and do a move]. Other than typography-demo.ly, I did not intend to move the files; I didn't realize that they were part of an unofficial set of regression tests. But I have no problem with un-deleting them, moving them to the regression/ dir. As a technical git question, would this require reverting the entire deleting... commit, doing a git mv, then another git rm for whatever's left? Also, I'm not sure why the totally obvious input/example-*.ly had to go. This seems to me as being such a nice-no-need-for- documentation-nobrain place to get going? It's not linked in the new website. We've had *months* to look comment on the new website, and in particular we've had virtually nothing happening for the past 5-6 weeks. If there's a particularly nice example, it either goes: - Documentation/general/examples/ (if it's an advertizing example) - Documentation/snippets/ (if it's a learning / documentation example) - input/regression/ (if it's for developers) [and/or some other files from input/]. Why does this have to change, and why did this happen without any mentioning of what the new mantra is like? I've mentioned cleaning up input/ a few times, and in particular I discussed the above separation of Documentation/ from input/. By this point, I thought that everybody who was interested in that discussion had already seen it 2 or 3 times. It might be useful to separate hey, what if we did XYZ -devel discussions from I have this plan, I will do XYZ, this is your last chance to complain -devel discussions. I know that the idea of a separate mailist wasn't well-received, so what about having a subject-line tag like [PROPOSAL] or [LAST CHANCE] ? We'd need to make sure that we don't overuse such things, but there have been a few times that a relatively major change caught people unaware. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Examples (for the web site and complete scores) status
On Wed, Aug 05, 2009 at 07:57:52PM +0200, John Mandereau wrote: The new directory Documentation/examples that was proposed to host examples for the web site plays a duplicate role of input/ and input/mutopia. What about cleaning up these two directories (that is, deleting unused input files and cleaning up makefiles) and use input/ instead of creating a new directory that would mostly have the same purpose? BTW what about keeping existing examples in input/mutopia in another page named e.g. More examples? OK, that's not very inspired; if there are good reasons for not keeping these input files, let's just junk them. IMO, there are two kinds of examples here. 1) advertizing examples: we can do tabs, complex rhythms, lots of accidentals, gregorian chant, etc etc. We expect people to glance at the image and then move on. 2) educational examples: part of the documentation. We expect people to read the source if they're interested. I do not think that we should mix #1 and #2. I want the web-Introduction page to simply be an introduction. Once somebody has decided to use lilypond, they should never look there again. Also, I want to keep those pages simple, and if possible, direct the reader through them. The Where next? sections are an explicit way of doing this. Now, I asked Jonathan to look through input/ and input/mutopia/ for anything worth keeping for the website. I assume that he's done so, so evidently nothing there fits into category #1. If you think he missed anything cool, then by all means we can add another item to the Examples page. If somebody thinks we should show longer example(s) to aid our advertizing efforts... I'm not *completely* opposed to splitting Introduction-Examples into Short examples and Long examples. I'm currently against such a move, since it would disrupt the current flow of the Introduction pages -- again, I believe that the best way to improve the readiblity of those pages is keeping them as simple and non-verbose as can be reasonably achieved with our human potential without an unduly strenuous amount of effort or overly long temporal span. (sorry, my meta-humor got away with me) That said, I'm willing to listen to counter-arguments about why we should add long examples to the advertizing pages. As for category #2, we already have a great location for pieces of input: the snippets. If there's anything of educational value in input/, let's put it into LSR. We don't currently have a complete pieces or long examples or whatever tag, but I'm sure Valentin would love to add one. I think it's important that, once users get expectations about the docs+website, we meet those expectations. One expectation is that examples of input notation are in the Snippets. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Examples (for the web site and complete scores) status
Le jeudi 06 août 2009 à 00:08 -0700, Graham Percival a écrit : IMO, there are two kinds of examples here. 1) advertizing examples: we can do tabs, complex rhythms, lots of accidentals, gregorian chant, etc etc. We expect people to glance at the image and then move on. 2) educational examples: part of the documentation. We expect people to read the source if they're interested. I do not think that we should mix #1 and #2. I surely agree about not mixing them in the output, but input files for #1 could be reused for #2. Now, I asked Jonathan to look through input/ and input/mutopia/ for anything worth keeping for the website. I assume that he's done so, so evidently nothing there fits into category #1. If you think he missed anything cool, then by all means we can add another item to the Examples page. I don't think so. The examples page looks great besides one little link in small font size to the sources (or to a dedicated Snippets page, see below). My concern is about what to do of files in input/. As for category #2, we already have a great location for pieces of input: the snippets. If there's anything of educational value in input/, let's put it into LSR. We don't currently have a complete pieces or long examples or whatever tag, but I'm sure Valentin would love to add one. I think it's important that, once users get expectations about the docs+website, we meet those expectations. One expectation is that examples of input notation are in the Snippets. Agreed, but we'll have to think about the way these larger examples (many of them are full pieces) should be compiled on LSR and in the docs. In particular for our docs, I'm not sure lilypond-book processing is desirable, I'm willing to keep them compiled directly by LilyPond, and we'd have a special page in Snippets documents, e.g. generated by an updated avatar of mutopia-index.py (the script that generate old Examples page). Thoughts? You already know I'm lazy about renaming directories (one reason is, it's so easy to forget someting, for instance did you rename pictures/ to logo/ in GUB? ;-), and the full pieces snippets should probably in a different directory if we don't compile them with lilypond-book. Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Examples (for the web site and complete scores) status
On Thu, Aug 06, 2009 at 06:46:35PM +0200, John Mandereau wrote: Le jeudi 06 août 2009 à 00:08 -0700, Graham Percival a écrit : As for category #2, we already have a great location for pieces of input: the snippets. If there's anything of educational value in input/, let's put it into LSR. We don't currently have a complete pieces or long examples or whatever tag, but I'm sure Valentin would love to add one. I think it's important that, once users get expectations about the docs+website, we meet those expectations. One expectation is that examples of input notation are in the Snippets. Agreed, but we'll have to think about the way these larger examples (many of them are full pieces) should be compiled on LSR and in the docs. In particular for our docs, I'm not sure lilypond-book processing is desirable, I'm willing to keep them compiled directly by LilyPond, and we'd have a special page in Snippets documents, e.g. generated by an updated avatar of mutopia-index.py (the script that generate old Examples page). Thoughts? I think there's two reasonable possibilities: 1) Include the images in whatever format the other snippets are. Maybe as an appendix rather than a main chapter in Snippets, but the essential point is that if somebody's looking at the short snippets in info, they would also look at the long examples in info. This my preference. My guess is that lilypond-book -- possibly a hacked lilypond-book with extra handling for long examples (I don't know what that might entail, since lilypond-book already works fine for long examples for me) -- would be the easiest way of doing this. But if you'd rather investigate custom texinfo macros and special processing with lilypond directly, I won't object. 2) Create pdfs of the long examples, then let each doc format simply link to those pdfs. I don't like the old Examples page. You already know I'm lazy about renaming directories (one reason is, it's so easy to forget someting, for instance did you rename pictures/ to logo/ in GUB? ;-), Yeah, that was me. and the full pieces snippets should probably in a different directory if we don't compile them with lilypond-book. As long as they exist under Documentation/snippets/ (since they'd be part of the Snippets manual), I don't have any opinion on whether they'd be a separate dir or the same dir as the other snippets. One question that AFAIK hasn't been resolved is whether it's actually worth including long examples. So far my vote is no, but I'm not vetoing it. I just don't see the educational value of them. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
