Re: LilyPondTool bundle
It does sort of work in win 98. I had to get an older version of Java, edit the .cmd file to call that version and then rename it to .bat I made the shortcut start minimized and autoclose so the dos window goes away. Tim Litwiller wrote: So, is there any chance that this will work on windows 98? I'm guessing not, but let me know if it does. My friend that I am hlping with lilypond only has a windows 98 computer. The have all their school stuff in MS Works or I would change them to linux. Actually, I may still have a windows 98, vmware image I could try it on. ... Bertalan Fodor wrote: Hi, I have bundled LilyPondTool along with Java 1.6 and jEdit 4.3pre9 and SumatraPDF as external PDF viewer, preconfigured for a Windows environment. Download it from http://lilypondtool.organum.hu/fileadmin/lilypondtool/lilypondtool.zip (44MB) and unzip it directly into C:\Program Files The folders will be created automatically. After that the editor can be started by clicking C:\Program Files\LilyPondTool\lilypondtool.cmd (You can create a shortcut from it on your toolbar or anywhere) If unzip to elsewhere, or don't have LilyPond at c:\Program Files\LilyPond, you must set the paths in the LilyPondTool\jedit\properties\lilypondtool-defaults.props file appropriately. This way you can create a customized out-of-box package of lilypond and lilypondtool. Please regard this as a proof of concept and don't be afraid to comment it. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partial rearrangement done, technical problems
Trevor Daniels wrote: Well, yes - at least one other likes it. But only if every sub-section within it concerns an actual instrument, and the list of instruments is complete (at least as far as the instrument-specific parts of LP are concerned). There's wide support (well, two people) for promoting Strings and Bagpipes as main sections, so I'll reinstate them. Remember that I'm totally open to renaming this chapter name (if we keep it as a chapter). I'll do it as soon as I get something better than "Purpose-specific notation". So the sub-sections should not include Chord Names nor Ancient Notation - these should be sections in "1. Musical Notation". ... Why do I prefer it? Well, it separates out those parts of the manual which are of interest only if you are writing for that particular instrument. Others can simply ignore sections that don't concern them. In effect it shortens the manual without removing anything. I completely agree with this reasoning (that's why I did it in the first place)... but this applies to Ancient and Chord names. As a string player, I've never used that stuff, so IMO they make sense to be in chapter 2. Whatever we end up calling that chapter. If this is technically possible and does not give rise to serious maintenance issues maybe this could be extended to chapters too. In theory, it's technically possible. In practice, it isn't. Sorry. :( - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: documentation guidelines
I've updated the README.txt with more guidelines about
writing/maintaining documentation. I'll be asking the GDP Helpers to
fix any Section organiztion and Formatting issues, as well as any
Readability or Technical writing issues they feel comfortable updating.
If I've forgotten anything from this list, please speak up so we can add
them now.
Info for Documentation
--
% UPDATING DOCS
convert-ly -e --from=... --to=... --no-version *.itely
% to find the current version number,
grep "version \"" tutorial.itely
% (nobody ever remembers to update this file, so I've stopped
% trying to record it here)
% BOOKS
There are three parts to the documentation: the Learning Manual,
the Notation Reference, and the Technical Details.
* Learning Manual: long, chatty, friendly explanations go here.
This is aimed at users learning something for the first time --
not necessarily just learning lilypond notation, but also things
like learning how to deal with projects, tweaking, preparing parts
for orchestras, etc. Less formal language may be used here.
Users are encouraged to read the complete Learning Manual from
start-to-finish.
* Notation Reference: a (hopefully complete) description of
LilyPond input notation. Some material from here may be
duplicated in the Learning Manual (for teaching). The material is
presented in an approximate order of increasing difficulty, but
the goal is _not_ to provide a step-by-step learning environment.
For example, all material under "Pitches" should remain in that
section, even though microtonal accidentals may seem more advanced
than info about clefs or time signatures -- "Pitches" should be a
one-stop reference about the pitch portion of notes. This section
is written in formal technical writing style.
Users are not expected to read this manual from start to finish.
However, they should be familiar with the material in the Learning
Manual (particularly ``Fundamental Concepts''), so do not repeat
that material in this book.
* Program Usage: information about using the program lilypond with
other programs (lilypond-book, operating systems, GUIs,
convert-ly, etc). This section is written in formal technical
writing style.
Users are not expected to read this manual from start to finish.
% SECTION ORGANIZATION
The order of headings inside documentation sections should be:
main docs
@refcommands
@commonprop
@seealso
@refbugs
(omit any headings which do not apply)
Including at least one link to @lsrdir{} inside @seealso is
highly recommended.
% FORMATTING
* Use two spaces for indentation in lilypond examples.
* Do not use tabs. They expand to nothing in DVI output.
* Do not use spaces at the beginning of a line (except in @example
or @verbatim environments), and do not use more than a single
space between words. `makeinfo' copies the input lines verbatim
without removing those spaces.
* Use two spaces after a period.
* Don't use a @ref{link to another section} in the middle of a
sentence. It looks ok in HTML, moderately bad in PDF, and
utterly horrible in INFO. Instead, reword the sentence so that
users are encouraged to see @ref{link to another section}.
(at the end of the sentence)
* Variables or numbers which consist of a single character
(probably followed by a punctuation mark) should be tied
properly, either to the previous or the next word. Example:
The [EMAIL PROTECTED]@var{a} ...
* To get consistent indentation in the DVI output it is better to
avoid the @verbatim environment. Use the @example environment
instead if possible, but without extraneous indentation. For
example, this
@example
foo {
bar
}
@end example
should be replaced with
@example
foo {
bar
}
@end example
where [EMAIL PROTECTED]' starts the line (without leading spaces).
* Use the `quote' option in @lilypond commands if possible.
Do not compress the input vertically; this is, do not use
Beginning of logical unit
@example
...
@end example
continuation of logical unit
but
Beginning of logical unit
@example
...
@end example
@noindent
continuation of logical unit
This makes it easier to avoid forgetting the [EMAIL PROTECTED]'.
* Non-ASCII characters which are in utf-8 should be directly used;
this is, don't say [EMAIL PROTECTED]' but `Baßtuba'. This ensures that
all such characters appear in all output formats.
* Lines should be less than 72 characters long. (I personally
recommend writing with 66-char lines, but don't bother modifying
existing material.)
* Use @q instead of `...' and @qq instead of ``...''. The latter macro
should be used with care since we use `...' as the default quoting
throughout the manual, except for things related to direct speech.
Warning: @q{} and @qq{} *MUST NOT* come at the end or beginning
of a line (unless it begins the paragraph). If these
GDP: "Predefined commands" vs. "commonly teaked properties"
Should we keep @refcommands independent from @commonprop ? For example, look at Tuplets. Do you like it as it is, or should we move \tupletUp \tupletDown etc inside the "Commonly tweaked properties" ? Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPondTool bundle
So, is there any chance that this will work on windows 98? I'm guessing not, but let me know if it does. My friend that I am hlping with lilypond only has a windows 98 computer. The have all their school stuff in MS Works or I would change them to linux. Actually, I may still have a windows 98, vmware image I could try it on. ... Bertalan Fodor wrote: Hi, I have bundled LilyPondTool along with Java 1.6 and jEdit 4.3pre9 and SumatraPDF as external PDF viewer, preconfigured for a Windows environment. Download it from http://lilypondtool.organum.hu/fileadmin/lilypondtool/lilypondtool.zip (44MB) and unzip it directly into C:\Program Files The folders will be created automatically. After that the editor can be started by clicking C:\Program Files\LilyPondTool\lilypondtool.cmd (You can create a shortcut from it on your toolbar or anywhere) If unzip to elsewhere, or don't have LilyPond at c:\Program Files\LilyPond, you must set the paths in the LilyPondTool\jedit\properties\lilypondtool-defaults.props file appropriately. This way you can create a customized out-of-box package of lilypond and lilypondtool. Please regard this as a proof of concept and don't be afraid to comment it. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: partial rearrangement done, technical problems
On 9/20/07, Graham Percival <[EMAIL PROTECTED]> wrote: > People who offered to help: I'm sorry I still haven't started the actual > documentation work yet. However, these stupid technical problems need > to get sorted out -- or at the very least, I need to be certain that the > technical issues _can_ be sorted out -- before I'm going to commit hours > and hours of documentation editing. I don't want to waste your time. > - > > > I've rearranged the non-instrument-specific portion of the docs; you can > see them here: > > http://opihi.cs.uvic.ca/~gperciva/lilypond/ > > > KNOWN ISSUES (don't bother pointing these out) > > - the subsections in vocal music and ancient music are messed up. > > - some HTML links aren't working. See below. > > > GENERAL DISCUSSION > > - I still like the division of musical notation / instrument-specific? > No? Nobody else? ok, I'll divide up that chapter and stuff it all into > the monster Musical notation. The notation / instrument-specific division is fine, imo. But it does seem odd to have "Chord names" as part of the instrument-specific stuff. Are chord names instrument specific? If you think of chords names as primarily useful in theory class, then "Educational use" might make sense; on the other hand, if you think of chord names for lead sheets, then maybe they should just become their own chapter in the notation section. Either way, maybe move "Chord names" to the notation section. Also, I agree with an earlier comment (somehow lost it in the thread) that both Strings and Bagpipe should promote to full sections in the instrument-specific part. It's OK that they be small; they can just function as placeholders until more such content shows up later. That will get rid of the "other instrument stuff" junk drawer. > - Assuming that the technical issues are solved, how do you want these > merged subsections to look? Specifically, consider 1.2.3. Displaying > rhythms. There's > > Time signature > - @commonprop > - @seealso > - @refbugs > Upbeats > - @refbugs > Unmetered music > - @refbugs > ... > Automatic note splitting > - @refbugs > - @seealso > > > Do you like this format, or would you prefer one @commonprop at the end > of each page? Do you want links to LSR stuff at the end of each > portion, or just one set of links at the bottom of the page? > > ... and are you guys _sure_ you prefer the manual like this? Ew. I don't like. Reading 1.2.3 is choppy. And the bold subsection titles hurt rather than help. Here's an extraction of the 1.2.3 subsection titles right now: 1.2.3 Displaying rhythms Time signature Commonly tweaked properties See also Bugs Upbeats Bugs Unmetered music Bugs Polymetric notation Bugs Automatic note splitting Bugs See also Doesn't flow. And makes us look like we have an undue preoccupation with bugs. A better structure would be: 1.2.3 Displaying rhythms Time signature Upbeats Unmetered music Polymetric notation Automatic note splitting See also We don't need but bug subsections printed as separate subsections with separate headers. Just format the content of the @refbugs as regular old paragraphs with no special headers. The chunking will then look like the revised ex above (focusing on the musical ideas), and we won't appear to be so wrapped around the axle about bugs. As far as the LSR stuff, maybe include all external links (whether LSR or see also, or whatever) in a single "See also" section at page bottom? -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPondTool bundle
Hm. I don't remember, but your suggestions are right. It's a pity I don't really have time to work on LilyPondTool, i have lots of other projects, directly connected to my family's life. Bert http://lists.gnu.org/archive/html/lilypond-user/2007-06/msg00420.html http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00060.html ?) Kindest regards, Germain ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplets (was: GDP for kids :)
On 9/19/07, fiëé visuëlle <[EMAIL PROTECTED]> wrote: > Am 2007-09-17 um 17:00 schrieb Valentin Villenave: > > > Trevor: there can be *no* name for such hideous rhythms... :) > > We may use "rythmes irrationnels" (one "h", two "n"s), or > > "monnayages", but generally speaking the terms we use for such > > *things* are so rude I can't consider posting any of them here... even > > in French ;) :-D > In German the word is "Tupel" vs. "Duole", "Triole", "Pentole" etc. > I never really heard "Tupel" in musical context, only mathemathically. > My musical lexicon doesn't know it - but my favourite online > dictionary doesn't know "tuplet" either. Yeah, I may be spreading unsubstantiated rumours here, but the term seems definitely to have shown up first in English (rather than FR or DE) and I *think* it actually originated in an early version of the Finale user manual (God help us). I've never been able to verify this last bit, but, if true, it would at least explain why the word doesn't seem to exist in any EN dictionaries yet. Henning, is das (?) Tupel the same word that gets used in math to talk about ordered collections of stuff like (17, 18, 29)? EN has "tuple" for such things ... and "tuplet" (with the final t) seems to be a completely novel musical term backformed from triplet, quadruplet, quintuplet, [s|h]extuplet, etc. Maybe DE has to make due with only one form of the word? Or possibly you guys could borrow in "Tuplet"? Or perhaps that simply looks absurd ... -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with slur across voices
Hi Tao, Hi Neil, Nice snippet... Now let's sing together my greatest hit: ready? one, two, three... "L-S-R! L-S-R! Add-it-to-the-L-S-R!" Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with slur across voices
Hi Tao, On 9/21/07, Tao Cumplido <[EMAIL PROTECTED]> wrote: > > hello all, > > I have a problem with slurring across voices in the following snippet. > the output is actually exactly what I want but I get lots of warnings when > compiling, so I was wondering if anyone can come up with a better solution. Since you're quite happy with the (invisible) clashing notes, you can get LilyPond to turn a blind eye to them using the magic incantation \once \override NoteColumn #'ignore-collision = ##t; just add it to your \hide macro. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPondTool bundle
Hi, > Hi, I have bundled LilyPondTool along with Java 1.6 and jEdit 4.3pre9 and > SumatraPDF as external PDF viewer, preconfigured for a Windows > environment. Thank you. My Java's ok, so I probably won't try this bundle UNLESS... ...the embedded LilyPondTool is updated in relation to the standalone 2.10.4 version I've once downloaded, and do use every day !! Is it ? Or would we definitly wait for LP 2.12 to open out and grow, before enjoying a newer LPTool ? (do you remember these threads : "locale problem with jedit + lilypond under Windows XP" http://lists.gnu.org/archive/html/lilypond-user/2007-06/msg00420.html http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00060.html ?) Kindest regards, Germain___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPondTool bundle
2007/9/21, Bertalan Fodor <[EMAIL PROTECTED]>: > Hi, I have bundled LilyPondTool along with Java 1.6 and jEdit 4.3pre9 and > SumatraPDF as external PDF viewer, preconfigured for a Windows > environment. Great! I'll test it as soon as I can find a Windows box. Such a bundle might be a huge asset for introducing new users to LilyPond... Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
LilyPondTool bundle
Hi, I have bundled LilyPondTool along with Java 1.6 and jEdit 4.3pre9 and SumatraPDF as external PDF viewer, preconfigured for a Windows environment. Download it from http://lilypondtool.organum.hu/fileadmin/lilypondtool/lilypondtool.zip (44MB) and unzip it directly into C:\Program Files The folders will be created automatically. After that the editor can be started by clicking C:\Program Files\LilyPondTool\lilypondtool.cmd (You can create a shortcut from it on your toolbar or anywhere) If unzip to elsewhere, or don't have LilyPond at c:\Program Files\LilyPond, you must set the paths in the LilyPondTool\jedit\properties\lilypondtool-defaults.props file appropriately. This way you can create a customized out-of-box package of lilypond and lilypondtool. Please regard this as a proof of concept and don't be afraid to comment it. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ANSWER, Re: problem with full-measure rests in differently time-scaled staves
2007/9/21, Mats Bengtsson <[EMAIL PROTECTED]>: > I hope you have remembered to send it also as a bug report, since > the current behaviour is clearly a bug. Might be related to #453, don't you think? Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ANSWER, Re: problem with full-measure rests in differently time-scaled staves
I hope you have remembered to send it also as a bug report, since the current behaviour is clearly a bug. /Mats Quoting Adam James Wilson <[EMAIL PROTECTED]>: Hi Valentin, I added snippet to LSR under the title: "How to compress full-measure rests (e.g. "R4") in a compressMusic block in a poly-tempo situation." Let me know it passes muster. Best, Adam On 9/20/07, Valentin Villenave <[EMAIL PROTECTED]> wrote: 2007/9/20, Adam James Wilson <[EMAIL PROTECTED]>: > Will the chunk of code I sent to the list suffice for an LSR snippet? Yes, definitely. Maybe you can add some notes on one of the staves to make it look more "realistic" (but thats up to you)... Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: translations
michał poręba writes: Hi Michał, > I'm interested in polish translation of lilypond documentation. That's great! > I have found that someone asked simillar question in the year 2004 > but I can't find anything about it. Does anybody translate the > documentation into polish? There is nothing that I know of, but you can always try to contact that person and propose to work together. > If not, what should I do to start? I wish to have at least the > tutorial translated into my language. We suggest a new translation of the documentation be started with the most popular pages of the website. See also the discussion about french translation that has lead to the french website http://lists.gnu.org/archive/html/lilypond-devel/2005-04/msg00233.html Tranlating the tutorial would be nice but there are many more people reading the website. > I can do it myself. All I need is to know how, or if this mailing > list isn't good for such a questions, to know whom to ask about it. Yes, this is the right place. We have two requirements: the translation must be maintained, and a minimal set of pages must be translated before the website goes live. See http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=TRANSLATION;hb=web and http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=README;hb=web to get started. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
problem with slur across voices
hello all,
I have a problem with slurring across voices in the following snippet.
the output is actually exactly what I want but I get lots of warnings when
compiling, so I was wondering if anyone can come up with a better solution.
when I had the slur attached to the lower voice it collided with the stem of
the upper voice.
Tao
\version "2.11.32"
hide = { \hideNotes \stemDown }
show = { \unHideNotes \stemUp }
\layout { ragged-right = ##t }
\relative c'
{
\clef F
\key es \minor
<< { bes4*3/4( \hide f16) \show es'4*3/4( \hide f,16)
\show bes4*3/4( \hide f16) \show es'4*3/4( \hide f,16) \show } \\
{ bes16 f es f es' f, es f bes f es f es' f, es f } >> |
}
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: translations
2007/9/21, michał poręba <[EMAIL PROTECTED]>: > Dear lilyponders, > > I'm interested in polish translation of lilypond documentation. I have found > that someone asked simillar question in the year 2004 but I can't find > anything about it. Does anybody translate the documentation into polish? If > not, what should I do to start? I wish to have at least the tutorial > translated into my language. I can do it myself. All I need is to know how, > or if this mailing list isn't good for such a questions, to know whom to ask > about it. Hello Michał, the Documentation is currently being fully rewritten, and maybe you'd better wait a few months before translating anything. Anyway, the instructions are here: http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO and the tutorial, in TeXinfo source code, is here: http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=Documentation/user/tutorial.itely;hb=HEAD If you think you can translate it within a couple weeks, maybe it could be worth it -- but that's up to you. Graham, John, any more advice? Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ANSWER, Re: problem with full-measure rests in differently time-scaled staves
Hi Adam, hi all, I'am relativly new to lilypond and already made some attempts to typeset a piece by morton feldman "bassclarinet and percussion"- without success. Now your snippet give me new hope: The piece is written in two systems, the first system changing the meter almost every bar, the second system entirely in 3/4. The two systems are synchronized vertically so that a 7/8 bar use the same space than a 3/4 bar, than a 2/4, than a 3/8 in a small footer it is said: "Every 135 Quarter Notes for both the bassclarinet and percussion" Is it possible to make it more (human) readible on the base of your snippet ( to have meter changes in the lower system of your snippet)? best, ole <><> Am 20.09.2007 um 23:48 schrieb Adam James Wilson: Hi Valentin, I added snippet to LSR under the title: "How to compress full-measure rests (e.g. "R4") in a compressMusic block in a poly-tempo situation." Let me know it passes muster. Best, Adam On 9/20/07, Valentin Villenave <[EMAIL PROTECTED]> wrote: 2007/9/20, Adam James Wilson <[EMAIL PROTECTED]>: Will the chunk of code I sent to the list suffice for an LSR snippet? Yes, definitely. Maybe you can add some notes on one of the staves to make it look more "realistic" (but thats up to you)... Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: partial rearrangement done, technical problems
Graham (late cc to list) > GENERAL DISCUSSION > > - I still like the division of musical notation / > instrument-specific? No? Nobody else? Well, yes - at least one other likes it. But only if every sub-section within it concerns an actual instrument, and the list of instruments is complete (at least as far as the instrument-specific parts of LP are concerned). So the sub-sections should not include Chord Names nor Ancient Notation - these should be sections in "1. Musical Notation". I don't like a the name "Other instrument-specific". Just drop it and promote Orchestral Strings and Bagpipes to sub- sections. This section then becomes easily extensible in the future to include further instruments that also have instrument-specific notation. Why do I prefer it? Well, it separates out those parts of the manual which are of interest only if you are writing for that particular instrument. Others can simply ignore sections that don't concern them. In effect it shortens the manual without removing anything. > - Assuming that the technical issues are solved, > how do you want these > merged subsections to look? Specifically, > consider 1.2.3. Displaying > rhythms. There's > > Time signature > - @commonprop > - @seealso > - @refbugs > Upbeats > - @refbugs > Unmetered music > - @refbugs > ... > Automatic note splitting > - @refbugs > - @seealso > > > Do you like this format, or would you prefer one > @commonprop at the end > of each page? Do you want links to LSR stuff at > the end of each > portion, or just one set of links at the bottom > of the page? Assuming that the links to each of the sub-sections will take you to that sub-section within the page and not the top of the page, then I prefer this format. The bottom of the page is too far away for all the links to be there. > > ... and are you guys _sure_ you prefer the manual > like this? Yes. Although I would prefer a click on, for example, "1.2 Rhythms" to return a monster page containing all the contained sub-sections rather than just the TOC for that section. This would permit a more comprehensive search for anything that was to do with rhythms but which did not fall obviously in any of the sub-sections, for example hemiola (which actually appears nowhere). If this is technically possible and does not give rise to serious maintenance issues maybe this could be extended to chapters too. > > > Cheers, > - Graham Trevor (D) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
translations
Dear lilyponders, I'm interested in polish translation of lilypond documentation. I have found that someone asked simillar question in the year 2004 but I can't find anything about it. Does anybody translate the documentation into polish? If not, what should I do to start? I wish to have at least the tutorial translated into my language. I can do it myself. All I need is to know how, or if this mailing list isn't good for such a questions, to know whom to ask about it. Best regards michal ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
