Hello everybody, I'm sure you all know about the LilyPond Snippet Repository, this wonderful place where anyone can share his ideas, examples, tips and tricks about LilyPond. Nevertheless, let me tell you more about it.
A lot more, in fact (as you may notice, this mail is a bit long...). I'm currently the main LSR editor; it's a relatively quiet job (but I'm counting on you folks to give me some more work in the next weeks and months). Basically, I review the snippets, correct them, expand them if needed, organize and tag them before approve them. Most of the time, I have nothing to do but check the "approved" box so anyone can see it. http://lsr.dsi.unimi.it/LSR/html/whatsthis.html But what /is/ a snippet? A snippet is made of four things. - a title (it has to be short and clear: most of the time it's better to make a full continuative sentence like "Adding fingerings to your score") - a longer description, in plain text or HTML. --> HTML is generally better since it allows basic formatting, and a much nicer result. --> The description has to be clear, and preferably include all the important stuff for better indexation in the database: for example, feel free to explicitely mention the command demonstrated in your snippet (e.g. "You can add clusters using the \makeClusters command".) --> Feel free to define and explain the musical terms you use: not everyone is supposed to know what an "accordion Discant" is, or a "piobaireachd"... - the snippet itself. --> First rule of LSR is: do not add a \version line. --> Second rule of LSR is: do NOT add a \version line. The LSR is always running a *stable* LilyPond version. If you have built your snippet with a different version... see below. --> The better your code looks, the more useful it can be. Remember to use proper indentation, add comments every now and then, etc. http://lsr.dsi.unimi.it/LSR/html/contributing.html I'm aware you already know all that, but I thought it was worth a reminder. Now for the really interesting part. As you might have noticed, LSR is deeply evolving. With almost 250 snippets (there were a lot more, but I had to remove some duplicates), it has become a major LilyPond resource -- by the way, as you may have noticed, the new user documentation (codename GDP) will be built around the LSR, with an advanced integration of some snippets. To provide easier snippets ordering, browsing and searching, we (well, mostly Sebastiano) have implemented a whole new system: instead of putting your snippets in one single directory, you can now mark them with one or more *tags*. Yes, I did say "tags"; welcome to all web2.0 geeks, welcome to the Youtube generation; you've dreamt of it, now it finally has happened. This is actually the only idea I've ever had since I'm here (at least, the only one that was adopted), so I'm particularly happy with it, and I hope most of you guys will be too. How does it work? Very simply: when you post a snippet, you'll see several drop-down menus; just use the frst one to select your first tag, the second one if you need to add another tag, etc. To prevent typo errors, you cannot invent new tags by yourself; in such a case you'll have to suggest a tag publicly on the list, or privately to one of the editors. Now, let's talk about the way tags were chosen. - First of all, you will see many tags beginning with a capital letter. These are directly inspired from the documentation sections. Such tags are more or less mandatory. Here's the full list of Capitalized tags: Pitches Rhythms Expressive marks Repeats Simultaneous notes Staff notation Educational use Text Vocal music Chords Piano music Percussion Guitar Strings Bagpipe Ancient notation Syntax, files, expressions Titles Midi Paper, layoutTag Breaks Spacing Contexts, engravers Tweaks, overrides - Next, you will find a few CamelCase tags (like WikiWords). These indicate common subjects, that one can find in very different snippets (actually, these tags may remind you of the former Documentation). They are much less important than Capitalized tags, but might still be useful. Here's the list of CamelCaseTags: SchemeLanguage SymbolsAndGlyphs ConnectingNotes SpecificNotation AutomaticNotation ContemporaryNotation - The last tags in the menu are lowercase tags. These are not really meant to be added by the users, but you're welcome to play with them. I usually add these "special" tags as tag #6 or #5, to clearly separate them from important topic-related tags #0, #1, #2 etc. Here's the list of lowercase_tags: really_simple really_cool real_music docs workaround version-specific correction -->the "really_simple" tag is pretty self-explanatory; you're welcome to contribute very basic snippets such as "how to ad a g", as long as it hasn't been added yet. -->the "really_cool" tag is... just cool. This is the useless tag where we all can point out what really amazes us in LilyPond (might be useful someday for propaganda purposes). Personally, I tagged as really cool such items as "Adding the current date to a score", "Automatic spacing behaviour" or "Drawing skyline outline"... And i'm looking forward to, someday, mark "Printing music in Braille" (Ralph, where are you?) This is a matter of personal taste, of course. If you find anything else "really_cool", be my guest :-) -->the "real_music" tag is meant for non-minimal examples. It has been suggested that the GDP includes some "inspirational headwords" (tm G.Percival&T.Baca Incorporated); the LSR can as well. For example, I was very happy to mark the "Combining pedal notes with clef changes" example. -->the "docs" tag is very special: adding this tag to a snippet means that the tagged snippet will automatically be added to the relevant section of the Documentation. I always want to add this tag everywhere, but I have to warn you that if it's irrelevant sooner or later Graham will remove it, so you might as well save him some work :) -->the "workaround" tag indicates... workarounds. -->the "version-specific" tag is meant to mark snippets that only work with LilyPond development version, or with an older version. This is the ONLY case where you are allowed to break the first and second rules of the LSR (see above). But beware: the LSR is running the current *stable* LilyPond version; if you're demonstrating some new feature, new syntax or whatever, you'll have to comment part of the code, if not all of the code! In the same way, this tag helps me finding outdated snippets. -->finally, the "correction" tag. If you notice some error or possible improvement in a snippet that has been posted by someone else, you won't be able to edit it directly (we're doing serious stuff here, this isn't Wikipedia, come on :) However, you do have the possibility to post a whole new snippet, as a corrected version of the previous one. If you do so, please mark your new snippet as "correction"; this way, I'll find it very fast, delete the former one, replace it with yours and remove the "correction" tag. OK, I think that's all. Now -- assuming that you've read me so far -- I'd be glad to welcome your questions, suggestions, criticism etc. Graham just told me that contributors could sometimes have great ideas (yeah, that surprised me too --not what he said, but *him* saying that...), so I'm just fishing for ideas here. I am currently tagging the whole LSR, so: -- you can see examples of tagged snippets you you check out the first snippets in the list https://lsr.dsi.unimi.it/list.php?type=snippet (Titles that begin with an A, B, C etc.) -- please don't wait for three months before having a great idea or before realizing my current organization is pure nonsense. The sooner you answer this message, the more your ideas are likely to be accepted. And remember: USE the LSR! Regards, Valentin PS. Oh, and btw please don't seriously consider feeding the "Wikipedia" troll :) _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
