Re: DOC: NR Dynamics context and postfix dynamics (issue3743045)
Thanks Keith - checked and pushed to origin/master. Trevor - Original Message - From: "Keith OHara" To: ; ; ; ; ; ; Cc: ; Sent: Thursday, December 23, 2010 11:02 PM Subject: Re: DOC: NR Dynamics context and postfix dynamics (issue3743045) Original Message From: tdanielsmu...@googlemail.com Keith, could you please fix the haripins, decide on the wording you prefer, and let me have a patch to push. Patch attached, and issue closed. -Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lily dances
Federico Bruni wrote Wednesday, December 22, 2010 4:10 PM 2010/12/22 Mike Solomon 1) svgdance.svg (best viewed in something that's not Internet Explorer - click on the notes and/or accidentals and see what happens!) Actually, only clicks on notes work here (FF4 and Opera), nothing happens if I click on accidentals. Opera is the best (as usual with SVG), because the cursor changes when hovering upon clickable items. In spite of Mike's warning the dancing actually works perfectly in IE8 - both notes and both accidentals dance beautifully! But the cursor doesn't change shape. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 4.4.2 \fooDown \fooUp (and how about \textDown?)
Carl Sorensen wrote Tuesday, December 21, 2010 10:22 PM On 12/21/10 1:14 PM, "Valentin Villenave" wrote: Oh, and by the way: we have \textSpannerDown for text spanners, but not \textDown for simple TextScript objects (that are quite likely to be needed by new users). Anyone against adding textDown, textUp, textNeutral? Why should we add \textDown, \textUp, and \textNeutral? TextScript is markup text, IIUC, and markup text attached to a note is always preceded by ^ - or _, isn't it? It seems to me that having special commands will just cause confusion. I agree. The predefined commands that exist are useful because the preceding direction indicator may be omitted, but it may not be omitted from a \markup. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 4.4.2 \fooDown \fooUp (and how about \textDown?)
Valentin Villenave wrote Tuesday, December 21, 2010 8:14 PM I've been looking at the LM 4.4.2 Placement of objects > Within-staff objects, and I'm not sure we want to use "Down/Left" and "Up/Right" in the table. Yes, we all know that -1 and 1 may respectively mean either "down" or "left" and either "up" or "right", but in this table we're *only* documenting objects that are aligned vertically! I think I wrote the heading as it is because down stems are on the left and up stems on the right, but I've no objection to removing the "left" and "right". Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc indexing confusion
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
Mark Polesky wrote Tuesday, December 21, 2010 5:12 AM
In texinfo:
@cindex foo-- add foo to the concept index
@findex foo-- add foo to the function index
@kindex foo-- add foo to the keystroke index
@printindex cp -- print the concept index
@printindex fn -- print the function index
@printindex ky -- print the keystroke index
In Documentation/common-macros.itexi, @funindex is defined:
@macro funindex {TEXT}
@findex \TEXT\
@kindex \TEXT\
@c
@end macro
The last two appendices of the NR are:
E. LilyPond command index
F. LilyPond index
In Documentation/notation.tely:
@printindex ky -- makes appendix E. "command index"
@printindex cp -- makes appendix F. "index"
There is some discussion of the rationale behind the
indices in
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
Questions:
1) Everything marked with a @funindex in the docs ends up in
*both* NR indices. How and why do these items end up in
appendix F?
@syncodeindex merges two indices. This is called by
the @lilyTitlePage macro to place both f and v indices
into the c index. This in turn is called in the .tely
file for each manual.
There is some discussion of the original rationale
behind the indices in
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
2) Why do we need @funindex? Why don't we just use these:
@findex
@printindex fn
I think it is to get round the vagaries of @syncodeindex. See
http://lists.gnu.org/archive/html/lilypond-devel/2006-05/msg00275.html
Graham might remember ...
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
Phil Holmes wrote Friday, December 17, 2010 10:12 AM From: "Trevor Daniels" 64 bit vista. 6 Gigs RAM. The odd 1 Gig for a VM has no effect :-) Lucky you ! It certainly does on my 3Gb laptop (at its maximum). Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
Colin Campbell wrote Friday, December 17, 2010 4:44 AM Hi Colin - pleased you found this easy. Just one comment .. 3. Working with source code (was section 2) * left as is, although why do we use git on Windows if we can't build? If we're pointing Windows and MacOS users to lilybuntu, let's just drop (2).5 entirely I use both a VM and git under Windows, but I always use git under Windows for doc work (and I've done a lot of it :) The reason is it is a lot faster and integrates much better with my usual work, which is under Windows. I only use the VM for development, as my usual work under Windows becomes much slower when the VM is running. That's not surprising as the VM takes away 1Gb of RAM from Windows, so there's a lot more paging going on - both real and virtual machines have to run in quite constrained amounts of RAM. The disk is being hammered all the time. So, to answer your question, doc work under Windows works best, at least for me, and is easier to set up and use. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scripts/auxiliar/update-with-convert-ly.sh appears not to work on Documentation/notation/rhythms.itely
Graham, you wrote Thursday, December 16, 2010 5:25 PM Could you try replacing it with an -o ? apparently -or is not posix compliant, but it doesn't say that -o is not posix. find Documentation/ -path 'Documentation/snippets' -prune -o -name '*.itely' | grep rhythms In case it's helpful, using the mingw command line under Vista find Documentation/ -name '*.itely' | grep rhythms produces Documentation/de/notation/rhythms.itely Documentation/es/notation/rhythms.itely Documentation/fr/notation/rhythms.itely Documentation/notation/rhythms.itely Documentation/snippets/rhythms-intro.itely find Documentation/ -path 'Documentation/snippets' -prune \ , -name '*.itely' | grep rhythms simply returns with no output and find Documentation/ -path 'Documentation/snippets' -prune \ -o -name '*.itely' | grep rhythms produces Documentation/de/notation/rhythms.itely Documentation/es/notation/rhythms.itely Documentation/fr/notation/rhythms.itely Documentation/notation/rhythms.itely Replacing -o with -or gives the same output. Is this as you would expect? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accidental.ly regtest
Carl Sorensen wrote Tuesday, December 14, 2010 12:55 PM On Dec 14, 2010, at 5:45 AM, "Dmytro O. Redchuk" wrote: I fail to see why this test (accidental.ly) would be less valuable if there would be "\key c \major", let's say. Because you want to ensure that it behaves properly. The best fix, IMO, would be to add "The first note has a natural followed by a sharp" at the beginning of the description. +1 The test also shows the cancelling natural behaves properly too- appearing once but only only once in the bar. A key of C would not show this. You could argue that this should be in a separate test, but why not combine them? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clarifying the 'padding alist-key
Mark Polesky wrote Thursday, December 09, 2010 3:15 PM Mark Polesky wrote: 1) padding - the minimum required amount of vertical whitespace between two items, measured in staff-spaces. When available, skylines are used in the spacing calculation. 2) padding - the minimum required amount of vertical whitespace between the skylines of two items, measured in staff-spaces. Carl Sorensen wrote: I prefer 2. Trevor Daniels wrote: 2, but is "skylines" explained anywhere in the docs? If it is, it is not indexed. Interesting. I just assumed you'd both prefer #1, because IIUC most items don't have skylines for padding. For example, do things like title/toplevel markups, lyrics, etc. have skylines? If not, I think the wording of #1 is more accurate. Well, it depends on how "skylines" is defined. If it's defined as a horizontal line at the extreme values of Y for title, toplevel markups, lyrics, etc the second wording is OK. Trevor: when I `git grep' for "skyline" in the Documentation directory, I get nothing, so to answer your question: no, skylines are not explained anywhere in the docs. So we have free rein to describe it how we like :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clarifying the 'padding alist-key
Mark Polesky wrote Wednesday, December 08, 2010 5:52 PM But which one is better? 1) padding – the minimum required amount of vertical whitespace between two items, measured in staff-spaces. When available, skylines are used in the spacing calculation. 2) padding – the minimum required amount of vertical whitespace between the skylines of two items, measured in staff-spaces. 2, but is "skylines" explained anywhere in the docs? If it is, it is not indexed. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4: Minor edits. (issue3406041)
Neil http://codereview.appspot.com/3406041/diff/6001/Documentation/notation/spacing.itely#newcode1297 Documentation/notation/spacing.itely:1297: c4 c c~ | \break % this \break works On 2010/12/02 08:34:52, Trevor Daniels wrote: indent; needs another c adding another c will make the break invalid You're right. Clearly this example is confusing, with at least two people from three demonstrably confused! I think it should be split into two, one showing that a hanging note prevents a line break, and another showing that a tied note over a bar line doesn't. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git history, Savannah
Francisco Vila wrote Tuesday, November 30, 2010 2:31 PM
Hello. As you probably know, Savannah has been down for days; now
it
is almost restored but latest backups are not newer than those of
November 24th. We should look at our local repos, try to restore
the
history and find out whether are there any missing commits.
- 1a7951329 Ties: Print out a warning for unterminated ties
- f0f0f0648b PartCombine: part-combine texts on first real note
rather than rests
- 8e43cb8e5 PartCombine: Shuffle functions around so
unisono/solo1/solo2/chords_together/apart are together in the
code; No
code changes
- 9189a4acb Doc-fr: new language option for musixml2ly
- 54913d988 Doc-fr: conflicting node name
- 67e7cb936 Doc-es: translate some new snippets, fix repeated
typo.
- 0960af56b76 Doc-es: markers for newly translated snippets.
- 7ba0a2264 Doc: cleanup @file{}, take 2: remove all @/ escaping
sequences.
- 95a4237d0a Merge branch 'master' into lilypond/translation
The latter is from Valentin.
I have these, plus
- fff96cc1a9 Doc: @file entries clean-up, take3 (add line-breaks)
on the translation branch, also from Valentin.
I think you are a good candidate to push
the most recent history once passwords and all that jazz is
working
again.
Looks like Valentin is best placed to do this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
Graham Percival wrote Tuesday, November 30, 2010 8:04 AM On Mon, Nov 29, 2010 at 06:37:08AM -0700, Carl Sorensen wrote: What about option 0 -- try to coordinate the resources we currently have available on the critical issues? I would like that. I'm a bit surprised to see so many people talking about branching a stable/2.14 -- I don't think that would solve anything. I'm willing to try it as an experiment, but I really doubt that having a separate branch would encourage more people to spend more time on critical issues. It wouldn't, but that wasn't the point of the suggestion. There's a history of new code not working quite right due to bugs, oversights, etc that only come to light a few weeks later. These then require input by experts to patch them up, often over several weeks. We don't want such code in a stable release, nor do we want experts, who might be working on critical problems, diverted to sort out bugs in new code. Branching 2.14 now would prevent new, relatively untested, code going into it, while not holding up development in 2.15. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now (part 2)
Graham Percival wrote Monday, November 29, 2010 7:33 AM With that in mind, I'm reopening the same question as the 24 Oct email. 2) release 2.14 ASAP with no critical flaws, but with some kind of code freeze. I prefer a variant on this. Branch 2.14 now and apply only patches to critical problems to it. That will at least prevent new bugs arising from new code. Continue to allow development in 2.15 unrestrained. Do not start GOP or GLISS until 2011. That allows time over the holiday period for critical bugs to receive attention, permitting (hopefully) a release of 2.14.0 early in 2011. Announce (to development) a target date for releasing 2.14.0, say 15 Jan 2011, to encourage work on bugs, translations, docs, etc over this period. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Graham Percival wrote Saturday, November 27, 2010 12:59 AM On Fri, Nov 26, 2010 at 11:31:06PM +0100, Valentin Villenave wrote: On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels wrote: > OK; I agree. Patch looks good. Thanks! I've pushed this patch, and merged translation onto master What. You pushed a huge patch onto git, with only a few hours of review time. Notably, without any review or comments from Mark -- the developer who first questioned the original commit. I don't think that was unreasonable. This was correcting an equally big patch which we all agreed was wrong, and which was already in master. It was equivalent to reverting the bad patch, but without destroying the good bits within it. Both Carl and I had approved it. The reprehensible behaviour was pushing the first big patch without review, not the second. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify fret calculation algorithm (issue3320041)
Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM Neil found a bug in the code. What happens when someone requests an open string that isn't present in the tuning? I've got the code fixed to issue a warning. After issuing the warning, we have two choices: 1 -- leave the improper pitch out of the tablature (which will leave a 0 fingering in the Staff and no corresponding pitch in the tablature) 2 -- calculate that pitch as part of the tablature, will will leave a 0 fingering in the Staff and a non-zero fret in the tablature. Which would be preferable? Isn't the 0 fingering in the Staff equally incorrect? As it is impossible to determine whether the pitch or the fingering is wrong this should really be classed as a syntax error - the combination is invalid. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Carl Sorensen wrote Saturday, November 27, 2010 12:03 AM
On 11/26/10 4:26 PM, "Valentin Villenave"
wrote:
I've fixed all @file refs that were more than 50-chars long
(there
were only a dozen or so, so this really was no big deal).
Most of these file references aren't actually more than 50
characters. They
get over 50 when you include the @var{} inside the file, or in one
case when
the greedy regex gets a closing } at the end of the line.
I don't think that matters. 50 was fairly arbitrary anyway.
Adding the soft break manually as Valentin has done ensures
bad breaks can't occur, even if the name is quite short.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Valentin Villenave wrote Friday, November 26, 2010 10:31 PM Thanks! I've pushed this patch, and merged translation onto master Great! Appreciated! On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels wrote: Ideally, yes. But who is going to look manually through all the docs? Er... Hello? :-) What do you think I've been doing for the past week or so? :) Oh, I thought you were doing it with fancy regexps. No I was just suggesting better English, but the spacing went awry - "that" should have been under "who" - "Long entries are those /that/ contain ...". (You once asked us to do that, IIRC :) Oh, thanks! I do tend to get confused between these: "the people who", "the things that", "the things which" (does "which" even work with plural?). Yes, it's fine with plurals. The last two are both OK, although some maintain that "which" should only be used to introduce a parenthetical clause: "the things, which John brought, were ..." although "that" wouldn't be seriously wrong here either. But "who" is a no-no unless the subject is a real person or maybe an animal that is considered to be almost a person, like a pet. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Carl Sorensen wrote Friday, November 26, 2010 6:43 PM
On 11/26/10 10:51 AM, "Valentin Villenave"
wrote:
Please have a look at the attached patch:
http://dl.free.fr/pMyOkyICo
I like the new patch, I think. I believe that it
would be preferable to do this instead of reverting
the previous patch.
OK; I agree. Patch looks good.
Er, are you suggesting that
@file{this/is/a/very/long/path/towards/myfile.scm}
should be printed without a line break?
I am suggesting this. I would much prefer to keep file paths on
one line as
long as they fit.
Yes, /as long as they fit/, but fit into what?
Hhm. Not sure. I think I'd prefer "more than three dashes or
slashes",
if we are to do it that way, but really it depends more on the
total length
of the name rather than the number of dashes and slashes. I'd
prefer
"if the name is longer than 50 characters (say)".
And if the name is too long then I'd prefer to place a single
optional break
near to the middle, so we don't get tiny fragments at the end or
start of
lines.
Both suggestions seem reasonable and easy enough to achieve.
(50 chars are really long, though.)
But a file name really *is* a single piece of information, so it
should be
kept on one line. If it's so long it won't fit on one line, then
we should
decide where to break it, rather than having it be done
automatically at any
slash.
Ideally, yes. But who is going to look manually through
all the docs? Better to do it automatically first, then
fix up any that stand out as poor when we notice them.
Otherwise we might have some names running over the right
margin in 2.14. Don't forget we've now lost the ones
that were done manually before - and some of them /were/
correct.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Valentin Villenave wrote Friday, November 26, 2010 5:51 PM
On Fri, Nov 26, 2010 at 4:47 PM, Trevor Daniels
wrote:
Long entries are those who contain either more than one dash or
more
that :)
than one slash (not counting "../").
Er, are you suggesting that
@file{this/is/a/very/long/path/towards/myfile.scm}
should be printed without a line break?
No I was just suggesting better English, but the spacing
went awry - "that" should have been under "who" - "Long entries are
those /that/ contain ...". (You once asked us to do that, IIRC :)
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Valentin Villenave wrote Friday, November 26, 2010 3:00 PM
Here's what I'm thinking (I'll update the doc guidelines if you
guys agree):
@file{} entries should not contain a @/ escape sequence, unless
these
are long enough to justify a possible line break.
Tick, as a policy statement.
Long entries are those who contain either more than one dash or
more
that :)
than one slash (not counting "../").
Examples:
Write
@file{scm/lily.scm}
or
@file{scm/backend-library.scm}
but
@file{scm/define@/-markup@/-commands.scm}
or
@file{input/@/regression/@/note-names.ly}
Hhm. Not sure. I think I'd prefer "more than three dashes or
slashes",
if we are to do it that way, but really it depends more on the total
length
of the name rather than the number of dashes and slashes. I'd
prefer
"if the name is longer than 50 characters (say)".
And if the name is too long then I'd prefer to place a single
optional break
near to the middle, so we don't get tiny fragments at the end or
start of
lines.
Or as Graham suggests, use @example.
[Optionally:
@file{} entries in @seealso sections should not contain @/
escaping,
no matter how long they are.]
Tick
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line breaks in @file{} entries?
Valentin Villenave wrote Friday, November 26, 2010 1:40 AM
On Fri, Nov 26, 2010 at 1:11 AM, Graham Percival
I don't think that @/ is appropriate. Certainly not for a short
@file{filename.ext}. I'm willing to entertain the notion of using
them inside a @file{long/directory/location/with/filename.ext},
although my preferred solution to those would be to put them in a
separate @example or @smallexample.
Removing them is way easier than adding them (besides adding @/
everywhere, my commit actually _added_ quite a bunch of @file
entries
whenever these were missing, e.g. in the CG. "programming work".
I'd prefer this patch to be reverted. That way the information
about
the long filenames that previously contained @/s is retained, making
it easier to change these to @examples (if this is indeed
desirable).
I never said it was. Which is why I wanted to address it as
quickly
and discretely as possible, and pushed it elsewhere than master.
It's already been merged into master :(
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cueDuring and its various settings
Reinhold Kainhofer wrote Monday, November 22, 2010 7:56 PM Am Montag, 22. November 2010, um 18:57:01 schrieben Sie: Would it not be better to define these properties using \addInstrumentDefinition #"flute" ... and then simply refer to "flute" in \cueDuring, as \instrumentSwitch does? Actually, quite often the cue text is not just the instrument, but something like "Str.". Also, depending on how long the cue notes are, one needs either "Tenor", "Ten." or "T." (all example from one of my recent scores, in particular during a fugue, when instruments set in at strange moments). I think that's doable even with an instrument definition. Use \addInstrumentDefinition to set up the default values then individual values can be changed with \set and restored to the default with \unset. E.g. \addInstrumentDefinition #"tenor" #`(( ... ) (instrumentCueName . "Tenor") ( ... )) ... % use "Tenor" \set instrumentCueName = "Ten." ... % use "Ten." \unset instrumentCueName ... % use "Tenor" Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cueDuring and its various settings
Carl Sorensen wrote Monday, November 22, 2010 4:54 PM
On 11/22/10 9:35 AM, "Reinhold Kainhofer"
wrote:
Do you have any idea how to properly add options for the
cueDuring command in
LilyPond???
I think you define cue-during-details as a music property, and
then do
\cueDuring
\withMusicProperty #'cue-during-details #(list '(clef .
"treble_8")
'(cue-name .
"Vl.1")
`(transposition .
(,ly:make-pitch 1
0 0))
{...}
Would it not be better to define these properties using
\addInstrumentDefinition #"flute" ...
and then simply refer to "flute" in \cueDuring, as
\instrumentSwitch does?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cueDuring and its various settings
Reinhold Kainhofer wrote Monday, November 22, 2010 4:35 PM I'm currently trying to make cue notes much better supported in LilyPond. In particular, it's not as simple as quoting the notes in a CueVoice. In real scores, there are several different options to take into account: -) Transpose the cue notes (usually by an octave, e.g. when quoting a piccolo flute), already possible using \transposedCueDuring -) Add a the proper clef for the quoted instrument (and automatically reset the clef to the clef of the quoting instrument) -) Add a cue instrument name (i.e. an InstrumentSwitch grob) to display the quoted instrument name There might be even more possible options, but these are really needed in my scores. Since we have 3 different options, which might or might not be needed in a cued part, we have 8 different combinations of necessary option settings. Not another option, but the use of cue notes in vocal scores requires these to be inserted in parallel with normal notes. In this case, of course, no change in clef is possible (or required). It might be necessary to change the positioning of the cue instrument name, but that should be possible and acceptable with the usual overrides. There is an example of the use of cues for this purpose in the Musical cues section of recent versions of NR 2.1.6 Vocal music. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Trevor Daniels wrote Sunday, November 21, 2010 11:58 PM Graham Percival wrote Sunday, November 21, 2010 11:18 PM On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote: Graham Percival wrote Saturday, November 20, 2010 8:40 PM >Who wants to edit the CG for this? James is away for a few >days, >so there's no point leaving it as a "learn how to use git" >exercise. Somebody please edit the CG and push (no reitveld >necessary). Graham: please check the commit to be sure you're happy with this. bf4298556820ead4deff2d667c362c2d7d045e67 Looks fine, but I have a vague memory of some special case for @item inside @multitable...? or am I confused? I think you're right, but it's @table not @multitable. I've not done a test, but I think in @table the first of the two items /must/ be on the same line as @item and the second starts a new line. I didn't put that very clearly. I should have said "the text for the first column /must/ be on the same line as @item, and must be separated from the text for the second column by a newline." In @multitable, @tab starts the second and subsequent lines so here the distinction between the items is clear and I don't think the positioning is important. and here, "@tab introduces the text for the second and following columns, so here the distinction between the text for the several columns is clear and newlines are not significant." Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Graham Percival wrote Sunday, November 21, 2010 11:18 PM On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote: Graham Percival wrote Saturday, November 20, 2010 8:40 PM >Who wants to edit the CG for this? James is away for a few >days, >so there's no point leaving it as a "learn how to use git" >exercise. Somebody please edit the CG and push (no reitveld >necessary). Graham: please check the commit to be sure you're happy with this. bf4298556820ead4deff2d667c362c2d7d045e67 Looks fine, but I have a vague memory of some special case for @item inside @multitable...? or am I confused? I think you're right, but it's @table not @multitable. I've not done a test, but I think in @table the first of the two items /must/ be on the same line as @item and the second starts a new line. In @multitable, @tab starts the second and subsequent lines so here the distinction between the items is clear and I don't think the positioning is important. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Graham Percival wrote Saturday, November 20, 2010 8:40 PM Who wants to edit the CG for this? James is away for a few days, so there's no point leaving it as a "learn how to use git" exercise. Somebody please edit the CG and push (no reitveld necessary). Done Graham: please check the commit to be sure you're happy with this. bf4298556820ead4deff2d667c362c2d7d045e67 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Graham Percival wrote Saturday, November 20, 2010 8:40 PM On Sat, Nov 20, 2010 at 08:29:35AM -, Trevor Daniels wrote: Graham Percival Saturday, November 20, 2010 12:44 AM >@itemize >@item >foo far This is best, but I'd prefer a blank line before and after every @item including the first one (IOW after @itemize as well) as long as this looks OK in info. I'm ok with that. For clarify, you mean "a blank line before every @item, and before the @end itemize". I mean, you don't want Exactly. Sorry for the misleading wording. @itemize @item foo @item bar @end itemize Definitely not this! Who wants to edit the CG for this? James is away for a few days, so there's no point leaving it as a "learn how to use git" exercise. Somebody please edit the CG and push (no reitveld necessary). Watch out for @table and @multitable. All the @item's in these should have the first entry on the @item line. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Trevor Daniels wrote Saturday, November 20, 2010 8:29 AM
Graham Percival Saturday, November 20, 2010 12:44 AM
On Fri, Nov 19, 2010 at 08:55:26AM -0800, Mark Polesky wrote:
CG 4.3.6 says:
"Always put �...@item’ on its own line, and separate
consecutive items with a blank line."
In fact, we literally have thousands of cases:
$ git grep -c "^...@item\s*.\+" |
sed -n 's/.*://p' |
awk '{total+=$0}END{print total}'
5103
GDP only covered about 30% of the docs, and didn't strictly
enforce the doc policy even within those areas, that's not a good
reason to change the policy.
+1. In the GDP'd parts of the NR there are only 7 exceptions.
(and in vocal none :)
Further, many if not all of the exceptions will be within
@multitable,
where it is sensible to have @item foo.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: questioning doc policy for @item
Graham Percival Saturday, November 20, 2010 12:44 AM
On Fri, Nov 19, 2010 at 08:55:26AM -0800, Mark Polesky wrote:
CG 4.3.6 says:
"Always put �...@item’ on its own line, and separate
consecutive items with a blank line."
In fact, we literally have thousands of cases:
$ git grep -c "^...@item\s*.\+" |
sed -n 's/.*://p' |
awk '{total+=$0}END{print total}'
5103
GDP only covered about 30% of the docs, and didn't strictly
enforce the doc policy even within those areas, that's not a good
reason to change the policy.
+1. In the GDP'd parts of the NR there are only 7 exceptions.
(and in vocal none :)
Ok, how about saying that you can have
@itemize
@item foo
@item bar
@end itemize
as long as each item is less than a line.
I'm happy with this
If there's multiple lines involved, then do the full
@itemize
@item foo
far
No, I don't like this. Too cluttered.
or
@itemize
@item
foo far
This is best, but I'd prefer a blank line before and after every
@item
including the first one (IOW after @itemize as well) as long as this
looks OK in info. That makes it easier to see the start and end of
the list when editing.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: music function
Valentin Villenave wrote Wednesday, November 17, 2010 10:47 AM
On Wed, Nov 17, 2010 at 10:41 AM, Trevor Daniels
wrote:
Sounds like a good candidate for an enhancement request.
my brain seems to be in low-power mode today, could you help me
rephrase this request so I can add it to the tracker?
Sure. How does this sound?
It would be good to have an optional setting, off by default, which
causes the repeat count in a volta repeat to be printed above the
repeat bar line when no alternatives are present. For example,
\voltaCountOn
\repeat volta 4 { ... }
% no alternatives follow
would print "x4" above the bar line closing the repeat.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: music function
This is the second time this has come up recently.
Sounds like a good candidate for an enhancement request.
Trevor
- Original Message -
From: "jakob lund"
To:
Sent: Wednesday, November 17, 2010 9:22 AM
Subject: music function
Hi
I have two questions that I hope someone here can answer.
I have something like this
\repeat volta 4 { ... music ... }
There are no alternative endings, so the number 4 doesn't show up in
the output.
I would like the text "×4" to appear below the closing repeat mark
(dotted bar line). Is there already a way
to do that? (there ought to be but I can't seem to find it...)
Using \mark is no good, because I already have a mark on that bar
line. Thus far I came up with:
repeatTimes = #(define-music-function (parser location r) (integer?)
#{
\bar ""
\once \override Score.TimeSignature #'stencil = ##f
\time 1/32
s32-\markup{\concat{ $(markup (number->string r)) "×" } }
\once \override Score.TimeSignature #'stencil = ##f
\time 4/4
#})
(the technique is adapted from the snippet titled "Creating
simultaneous rehearsal marks"
from the lilypond documentation.) So now I write
\repeat volta 4 { ... music ... \repeatTimes #4 }
which gives sort of the desired result. My second question is: Can
I,
perhaps using the 'parser' argument, access
(a) the `current time signature' (so I can get rid of the
hard-coded 4/4 at the end) and
(b) the argument to `\repeat volta' (so I won't have to supply
the
argument #4, which is redundant 'cause I already put `volta 4') ?
Regards
Jakob Lund.
___
lilypond-user mailing list
lilypond-u...@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oddHeaderMarkup and its kin are \paper variables?
Mark Polesky wrote Monday, November 15, 2010 5:18 AM These are essentially \paper variables, right? oddHeaderMarkup evenHeaderMarkup oddFooterMarkup evenFooterMarkup You have to set them in the \paper block, it seems, so I would like to categorize them alongside things like system-separator-markup. Would that make sense? Yes. At present I don't think they are documented at all (other than appearing in an @example.) So maybe this is something for GLISS, but in keeping with the naming format of \paper variables, we should probably change these to: odd-header-markup even-header-markup odd-footer-markup even-footer-markup Hopefully this doesn't require much discussion. I'd do it now if there is no objection. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vert. spacing: Rename properties (lily, scm). (issue3031041)
Mark, you wrote Saturday, November 13, 2010 12:50 AM I think I made every suggestion except one. I didn't change "grob" to "layout object", just because "grob" appears as a word so often in define-grob-properties.scm, and "layout" doesn't appear once: That may be so, but it's a standard term in the IR and the documentation. See IR 3.1 which is called All layout objects. Grob is the name of those layout objects that actually deal with something pictorial rather than positional. No big deal, though. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vert. spacing: Rename properties (lily, scm). (issue3031041)
markpole...@gmail.com wrote Friday, November 12, 2010 10:48 PM On 2010/11/12 21:53:41, Mark Polesky wrote: I might like to keep staff-staff-spacing for the StaffGrouper prop. I'm thinking it over, and I'll get back to you. Guys, I'd rather not change StaffGrouper's 'staff-staff-spacing to 'default-staff-staff-spacing. The big reason for me is that it is no more a "default spacing" than its companion property 'staffgroup-staff-spacing, and it would be very weird to call that one 'default-staffgroup-staff-spacing. [snip] If you're okay with that logic, then all that remains is to find a better way to explain both #1 and #2a using a single property-description, since they share the same name. I propose this: staff-staff-spacing When applied to a staff-group's StaffGrouper grob, this spacing alist controls the distance between consecutive staves within the staff-group. When applied to a staff's VerticalAxisGroup grob, it controls the distance between the staff and the nearest staff below it, replacing any settings inherited from the StaffGrouper grob of the containing staff-group, if there is one. What do you think? All LGTM. Time to get this launched, I think. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
Trevor Daniels wrote Tuesday, October 19, 2010 8:34 PM Keith E OHara wrote Monday, October 18, 2010 11:40 PM I suggest (diff attached) removing the part about instrumentCueName in favor of a fuller example for \killCues. The manual teaches markup elsewhere; the challenge with cue-note labels is to let the label appear with the cue notes in parts, but not in the score. Your patch is a definite improvement, IMO. If no one objects soon I shall push it. I think it might be further improved by a little more text, as someone coming to this for the first time might still find it rather difficult as it is. But I'm happy to add that. Done. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Mark Polesky wrote Monday, November 08, 2010 7:14 PM Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more option -- just remove the "withingroup" prefix altogether: \override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing Thoughts? LGTM (As I've said before, I admire your persistence :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamicsperformergroup
Valentin Villenave wrote Monday, November 08, 2010 11:16 AM On Mon, Nov 8, 2010 at 11:13 AM, Trevor Daniels wrote: There might even be an argument for adding something which made compilation fail - in a way that clearly indicated the problem, of course. Bold idea... or insane, I can't decide which one it is. :-) I had users unfamiliar with grep, console messages and log files in mind. I believe these are in the majority. Anyway, this whole insert-comments thing is now known as http://code.google.com/p/lilypond/issues/detail?id=1387 Meanwhile, do I have your LGTM to push my regexp patch? As long as it's been tested on snippets or docs I'm happy to see it pushed. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamicsperformergroup
Reinhold Kainhofer wrote Monday, November 08, 2010 12:09 AM Am Sonntag, 7. November 2010, um 20:46:54 schrieb Trevor Daniels: I think this would be an improvement, but I don't think it's essential. The file will be left in an erroneous state so the user will be forced into further investigation anyway, and the usual LilyPond error messages will indicate what is wrong. Not necessarily. Some things like property names (e.g. I think we had this case with modifying text for spanner beginn/end) will not necessarily print an error or a warning. In these cases, if you don't save the convert-ly output somewhere you will not notice that anything is wrong possibly until a score went to a publisher and it is too late... In these cases perhaps it would be best to do as Carl suggested and add a comment to the head of the file, as well as sending a message to the console. There might even be an argument for adding something which made compilation fail - in a way that clearly indicated the problem, of course. When running convert-ly on many files (like the LSR) inspecting every file for a comment would be laborious, although a simple script to look for the comment would be an alternative. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Mark Polesky wrote Monday, November 08, 2010 1:24 AM Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing Let's stay with these. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup
Graham Percival wrote Sunday, November 07, 2010 1:07 PM On Sun, Nov 07, 2010 at 12:50:20PM +, Graham Percival wrote: The normal method would be for convert-ly to print a warning message to the console. Why is this Dynamics thing so different from previous changes? Another option is to argue that in-file comments are much more noticeable than console warning messages, and thus _any_ change which we current display a NOT_SMART rule on the console should instead be placed inside the file as a comment. I think this would be an improvement, but I don't think it's essential. The file will be left in an erroneous state so the user will be forced into further investigation anyway, and the usual LilyPond error messages will indicate what is wrong. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup
Graham Percival wrote Sunday, November 07, 2010 12:50 PM On Sun, Nov 07, 2010 at 12:26:59PM -, Trevor Daniels wrote: Valentin Villenave wrote Sunday, November 07, 2010 10:35 AM >I'm not sure if we've ever used convert-ly to insert comments in >.ly >files, but I do think we should in this specific case: the >piano-centered dynamics template has been used by a *lot* of >people in >the past, and it's much more safe IMO if convert-ly puts a >comment >as >some kind of a placeholder. Well, I never did master regular expressions, so I can't vouch for the accuracy of this, but I agree with inserting a comment when these lines are removed. The normal method would be for convert-ly to print a warning message to the console. Why is this Dynamics thing so different from previous changes? Because otherwise there is no indication left in the file of any change having been made. I think if this applies in other cases a note should be made in the file to that effect in the place where the removed code used to be. But when the code is either changed or left intact a console message is fine. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Mark Polesky wrote Sunday, November 07, 2010 3:30 PM All right, hopefully everyone here won't mind one last vote, so please state your preference among the following: SPACE MINIMUM-DISTANCE -- -- 1) basic-distanceminimum-distance 2) initial-distanceminimum-distance 3) basic-separation minimum-separation 4) initial-separation minimum-separation Alexander: Carl: David: Joe: Mark: 1 Trevor: 4 Valentin: Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Mark Polesky wrote Sunday, November 07, 2010 4:40 PM Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing In this thread, there are at least 11 people with a vested interest (I added Joe even though he's been silent). Anyone else wanting to vote, feel free to add your name to this list. Please enter your preference among the 2 choices above. I've already entered mine. Carl: David: James: Jan: Jean-Charles: Joe: Keith: Mark: 1 Trevor: 2 Valentin: 1* Werner: 2 *was 2, then changed it to 1? Which one is it? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup
Valentin Villenave wrote Sunday, November 07, 2010 10:35 AM
Greetings everybody, here's a patch that (hopefully) addresses the
low-priority issue 1365.
I'm not sure if we've ever used convert-ly to insert comments in
.ly
files, but I do think we should in this specific case: the
piano-centered dynamics template has been used by a *lot* of
people in
the past, and it's much more safe IMO if convert-ly puts a comment
as
some kind of a placeholder.
Please have a look at the patch (since it's basically a one-line
patch, I think using Rietveld here would be overkill).
http://code.google.com/p/lilypond/issues/attachmentText?id=1365&aid=-4862281631302526021&name=0001-Convert-ly-fix-regexp-for-Dynamics-context.patch
-str = re.sub
(r'(\\context\s*\{{1}[^\}]+\\name\s+"*Dynamics"*[^\}]*\}{1})',
- '', str)
+str = re.sub
(r'(\\context\s*\{{1}[^\}]+\\type\s+\"?Engraver_group\"?\s+\\name\s+"*Dynamics"*[^\}]*\}{1})',
+ '% [Convert-ly] The Dynamics context is now
included by default.', str)
Well, I never did master regular expressions, so I can't vouch for
the
accuracy of this, but I agree with inserting a comment when these
lines
are removed.
I guess this would also remove a user-defined engraver-group context
named Dynamics too, but maybe there aren't many of those and the
comment at least will raise a flag.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Mark, since you were the only one to vote for this openly and Carl, Alexander and I didn't (well, Carl did initially, then changed his mind) perhaps you need to be a little more open about the voting process or you'll have Valentin after you :) Since you chose to have an open vote it should remain open and transparent to the end. Trevor - Original Message - From: "Mark Polesky" To: "lilypond-devel" ; "Carl Sorensen" ; "Trevor Daniels" Cc: "Joe Neeman" Sent: Sunday, November 07, 2010 8:59 AM Subject: Re: Renaming the 'space alist-key After polling some of you individually, the clear winner is to change the 'space key to 'basic-distance. Joe, can you take it from here? Thanks all. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: non-technical help for spacing issues
Keith E OHara wrote Sunday, November 07, 2010 1:19 AM On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival wrote: >On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: >This is directed at people saying "I can't do anything to >help..." > I need a committing, not necessarily committed, partner to close this. I think this should be Mark, so he can coordinate it with his name-changing. The 2.13 default spacing is shown as a small image at (http://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00692.html) while the proposed spacing is at (http://k-ohara.oco.net/Lilypond/score.usedPatch.pdf). This looks pretty good now. The only things I would want to change are unrelated to spacing (doubled dynamics, one or two instances of bad placing of markup, etc) 2a) Lyrics get less space in the new system, but all the choral-music folk seem to want is a but a touch more padding from Lyrics to any non-associated grobs on the next staff. Maybe right, but has anyone really tested all the different forms of lyrics yet? There might be no unique best default settings. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Mark Polesky wrote Sunday, November 07, 2010 12:46 AM Carl Sorensen wrote: 9) initial-separation * longer but describes the meaning more accurately now we have an item-item-spacing format I vote for 8 or 9. 9. Does this entail changing 'minimum-distance to 'minimum-separation? I prefer both to use the same noun. Yes, it would. I think the choice between the two comes down to how the descriptive text looks. At present I have no clear preference. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Keith E OHara wrote Sunday, November 07, 2010 2:54 AM On Sat, 06 Nov 2010 18:20:08 -0700, wrote: [...] And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go ahead with the proposals listed above I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. We might convince Mr Daniels that this is good enough reason to support your (unabbreviated) preference, or he might come up with an even better suggestion for the variable that chooses which direction is the 'related' direction. My rationale is to choose words that stand-alone and carry a clear indication of both the underlying concept and the relationship to other properties. I like "staff-affinity" because it means an attraction to or relationship with a staff. Sounds just right. "reference-direction" is OK too, but suffers from not indicating "staff" as the relevant object. "referencestaff" in itself satisfies my criteria, and I'd be happy with that, but I don't like "oppositestaff". It has no meaning in itself, as there is no indication in its name what it is opposite to. You have to remember it is it is one of a related pair and its partner is called "referencestaff". OTOH "relatedstaff"/"unrelatedstaff" both stand alone with clear meanings, and with a clear association with "staff-affinity", as one of the meanings of "affinity" is "having a relationship". All that said, I'm not going to protest against any of the recent proposals; they're all an improvement over existing wording. All I have is a preference, nothing stronger. Others have other preferences, and, having stated my case, I'm happy to go along with the majority view. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming the 'space alist-key
Mark Polesky wrote Saturday, November 06, 2010 5:32 PM 7 proposals for renaming the 'space alist-key have been discussed, but a decision has not yet been made. And I just added an 8th proposal (initial-distance). To recap, I think the arguments *for* each of these are mostly self-evident, so the list here only includes the arguments *against* those that have been opposed: 1) default-distance * sounds like the program's default, not the user's 2) optimal-distance * sounds like the resulting trade-off between the desired distance and situational spacing constraints 3) desired-distance 4) requested-distance 5) base-distance * sounds like the distance between "bases" 6) unstretched-distance * sounds like space can only stretch, not compress 7) basic-distance 8) initial-distance I vote for either 7 or 8. What about you? 9) initial-separation * longer but describes the meaning more accurately now we have an item-item-spacing format I vote for 8 or 9. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: solved: reference points for non-staff lines
Valentin Villenave wrote Saturday, November 06, 2010 12:00 AM On Sat, Nov 6, 2010 at 12:44 AM, David Kastrup wrote: "Trevor Daniels" writes: I'd prefer to see your image in the docs rather than text. Just be sure you look your best. ROTFL! Me too! Nice one, David. On a more serious note, please keep in mind that we have blind users, so we don't want any information to be available only as an image... Ideally, I think Mark should put both. Good point. Text and image then (yes, Mark, definitely without verbatim, but keep your tie on.) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: solved: reference points for non-staff lines
Good work, Mark.
I'd prefer to see your image in the docs rather than text.
Trevor
- Original Message -
From: "Mark Polesky"
To: "lilypond-devel"
Sent: Friday, November 05, 2010 11:17 PM
Subject: solved: reference points for non-staff lines
In case anyone cares, I finally was able to determine the
reference points for the individual non-staff lines. Here
they are:
CONTEXT REFERENCE POINT
--- ---
ChordNamesbaseline
NoteNames baseline
Lyricsbaseline
Dynamics vertical center
FiguredBass highest point
FretBoardsguitar nut
I'll add this to the doc patch and push it:
http://codereview.appspot.com/2642043/
The test file I used follows below; I attached a png too.
- Mark
* * * * * * * * * * * * * * *
\version "2.13.39"
#(define zero-line
'((padding . -inf.0)
(space . 0)))
\paper {
left-margin = 15\mm
line-width = 90\mm
ragged-right = ##f
score-system-spacing =
#'((padding . 0)
(space . 10)
(stretchability . 0))
}
\layout {
\context { \ChordNames
chordNameLowercaseMinor = ##t
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
% only because I put a NoteName line in the way (below)
\override VerticalAxisGroup #'inter-loose-line-spacing =
#zero-line
}
\context { \Dynamics
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
}
\context { \FiguredBass
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
}
\context { \FretBoards
\override VerticalAxisGroup #'staff-affinity = #DOWN
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
}
\context { \Lyrics
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
}
\context { \NoteNames
\override VerticalAxisGroup #'inter-staff-spacing = #zero-line
}
\context { \Score
\override TextScript #'staff-padding = #2
\override TimeSignature #'stencil = ##f
\override BarLine #'stencil = ##f
}
}
%% These contexts have reference points at the baseline:
%% ChordNames, NoteNames, and Lyrics
<<
\new ChordNames { \chords { g1:m | } }
\new NoteNames { s1 | g1 | }
\new RhythmicStaff {
\set RhythmicStaff.instrumentName = #"baseline "
\textLengthOn
s1^\markup { \typewriter ChordNames } |
s1^\markup { \typewriter NoteNames } |
s1^\markup { \typewriter Lyrics } |
}
\new Lyrics { \lyrics { \skip 1 | \skip 1 | ghijk1 | } }
%% The reference point for Dynamics is its vertical center
<<
\new RhythmicStaff {
\set RhythmicStaff.instrumentName = #"vertical center "
s1^\markup { \typewriter Dynamics } | s1 | s1 |
}
\new Dynamics { s2\mp s\fp | }
%% The reference point for FiguredBass is its highest point
<<
\new RhythmicStaff {
\set RhythmicStaff.instrumentName = #"highest point "
\textLengthOn
s1^\markup { \typewriter FiguredBass } | s1 | s1 |
}
\new FiguredBass { \figuremode { <6 5>1 | } }
%% The reference point for FretBoards is the guitar nut
\include "predefined-guitar-fretboards.ly"
<<
\new FretBoards { \chordmode { e1 | } }
\new RhythmicStaff {
\set RhythmicStaff.instrumentName = #"guitar nut "
\textLengthOn
s1^\markup { \typewriter FretBoards } | s1 | s1 |
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Valentin Villenave wrote Thursday, November 04, 2010 12:10 AM > On Thu, Nov 4, 2010 at 12:58 AM, Trevor Daniels wrote: >>> Renaming proposals, round 3: >>> >>> CURRENT NAME PROPOSED NAMETD's PREFERENCE >>> ---- >>> next-staff staff-staff >>> default-next-staff default-staff-staff >>> inter-staffnonstaff-refstaffnonstaff-relatedstaff >>> inter-loose-line nonstaff-nonstaff >>> non-affinity nonstaff-oppstaffnonstaff-unrelatedstaff >>> between-staff within-group-staff-staff withingroup-staff-staff >>> after-last-staff group-staff staffgroup-staff > IMO that's the best proposal I've seen so far. :) > So, I don't know what this "TD" stands for (Tropical Depression? > Treasury Department?), but it has my vote :-) It's on the back of my car. Many people think it stands for Turbo Diesel, but they're wrong. > Cheers, > Valentin. Turbo, aka Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Carl Sorensen wrote Wednesday, November 03, 2010 11:00 PM On 11/3/10 2:49 PM, "Mark Polesky" wrote: Trevor wrote: I wonder if affinity/nonaffinity are optimal. Are they better than relatedstaff/unrelatedstaff? Or target/opposite, reference/opposite, refstaff/oppstaff? Actually, now I really like refstaff/oppstaff: ref and opp are abbreviations and not good for non-native-english speakers. +1 Abbreviations are bad, bad. nonstaff-associatedstaff-spacing nonstaff-nonstaff-spacing nonstaff-freestaff-spacing or nonstaff-isolatedstaff-spacing Looking at a thesaurus, I have some more ideas: nonstaff-relatedstaff vs. nonstaff-unrelatedstaff That was my original suggestion :) nonstaff-linkedstaff vs. nonstaff-separatestaff nonstaff-attachedstaff vs. nonstaff-detachedstaff nonstaff-affixedstaff vs. nonstaff-releasedstaff nonstaff-alliedstaff vs. nonstaff-foreignstaff nonstaff-alliedstaff vs. nonstaff-disjoinedstaff I still prefer nonstaff-relatedstaff/nonstaff-unrelatedstaff How do you feel about staffgrouped-staff-staff-spacing ? If we're going with this idea, I'd prefer groupedstaff-staff-staff-spacing since it's better english than staffgrouped IMO. I could live with this, although groupedstaves-staff-staff-spacing is even clearer. It's the same length as within-group-staff-staff-spacing but it has one less hyphen, which for some reason I consider an advantage. Although I might prefer within-group anyway. Now, if we do use within-group-staff-staff-spacing Maybe it's withingroup-staff-staff-spacing. This looks the best so far to me. I thought we might as well shorten staffgroup-staff-spacing to group-staff-spacing . What do you think? I prefer staffgroup-staff spacing, since it's a staffgroup object, not a group object, that we're trying to space. +1 Renaming proposals, round 3: CURRENT NAME PROPOSED NAMETD's PREFERENCE ---- next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-refstaffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-oppstaff nonstaff-unrelatedstaff between-staff within-group-staff-staff withingroup-staff-staff after-last-staff group-staff staffgroup-staff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Mark Polesky wrote Tuesday, November 02, 2010 8:56 PM
Renaming proposals, round 2:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-staff
I'd go with Carl's suggestion of nonstaff-affinity
here. But is this really strictly top-down directional,
or does this apply even when the nonstaff is below the
staff? (The usual placement for lyrics is below the
staff to which they have an affinity, and there is no
staff-nonstaff.)
I wonder if affinity/nonaffinity are optimal.
Are they better than relatedstaff/unrelatedstaff?
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-nonaffinity
between-staff (see below)
after-last-staff staffgroup-staff
* * * * * * * * * * * * * * *
Notes:
1) "nonstaff" beat out "loose" by a large margin.
Sorry Carl! (:
2) all the ideas for "between-staff" so far:
* names consistent with the item1-item2 format
a) groupstaff-groupstaff (Trevor)
b) groupedstaff-groupedstaff (Trevor)
c) grouped-staff-staff (Mark)
* shorter names
d) inside-staffgroup (Mark)
e) grouped-staff (Carl)
f) grouped-staves (Carl)
Should we vote on this? I'd vote for either c or f. Here
are some of my observations.
I think (c) could easily be interpreted to mean
groupedstaff-ungroupedstaff, since ungroupedstaff is
the meaning of staff elsewhere. So my preference is
for (b). It is long, but it's meaning is clearest,
especially as staffgroup exists to help dispel confusion.
I would also be happy with (a) (so no surprises there :)
If we go for the shorter names I prefer (f).
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming "vertical spacing inside systems" props
Mark Polesky wrote Friday, October 29, 2010 11:27 PM Here are my proposals for renaming the properties related to "Vertical spacing inside systems". * * * * * * * * * * * * * * * I've thought about it, and I think I slightly favor the term "loose line" over "non-staff line"; the word "loose" is distinctive and much less likely to get tangled up with the word "staff" (in the user's head, that is). On the other hand, "nonstaff-staff-spacing" may be more intuitive than "loose-staff-spacing". But if we call the property "nonstaff-staff-spacing", I'd want to replace all references to "loose lines" with "non-staff lines" (or maybe "nonstaff lines", without the hyphen?). I dislike "loose lines". It doesn't immediately make me think, Ah, yes, that means my lyrics. Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. "Nonstaff lines" is definitely better, I think, and, yes, without the hyphen for consistency with the names of the spacing properties. Lastly, one property resists the "item1-item2-spacing" name format: currently named 'between-staff-spacing, it controls the spacing between staves within a staffgroup. I don't like the current name because it sounds like it controls the spacing between ungrouped staves too, but it doesn't. I'm proposing 'inside-staffgroup-spacing, which is clearer (I think) but not consistent with the "item1-item2-spacing" format. groupstaff-groupstaff-spacing ? groupedstaff-groupedstaff-spacing ? But I'm not unhappy with inside-staffgroup-spacing. BTW, what happens to nonstaff lines within staff groups? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
Graham Percival wrote Sunday, October 24, 2010 4:22 AM We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. There's no problem with that, of course -- this is a volunteer project, and we have no strict schedule. If we want to work on non-Critical issues, that's fine. Along those lines, I'm wondering if it's worth starting GOP, the Grand Organization Project, now. We probably should. I don't see it affecting the fixing of the remaining critical issues much, as many of us are unable to contribute to those anyway. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Fix #903: Add shortcuts for note names languages.(issue2606042)
Valentin Villenave wrote Saturday, October 23, 2010 9:54 PM On Thu, Oct 21, 2010 at 4:53 AM, wrote: I like this idea as a way to get the functionality you want in the short term. But I don't like it for the long term. I think the long-term syntax needs to be \language "foobar" So I thought, but here's a way to do it anyway: see attached patch. Well, I tried it under Windows Vista and it seems to work fine, at least on a simple test with english.ly. I can't vouch for the purity of the coding though, and of course we'll need some doc changes, reg test, and a convert-ly change. It doesn't work for arabic.ly, as you say, nor for bagpipe.ly, but as neither of those are languages (arabic.ly is for Arabic music rather than the Arabic language) I don't think that's a problem. All genuine language files should be OK. As a way of introducing the improved syntax this LGTM. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Query about sentence in Notation Reference
James Lowe wrote Saturday, October 23, 2010 8:00 PM
While scanning through NR 1.2.2 the last section I came across the
line
When a multi-measure rest immediately follows a @code{\partial}
setting, resulting bar-check warnings may not be displayed.
Does anyone therefore know when I wouldn't get bar-check warnings
displayed in this case?
The sentence was added by Carl on 9 Jul 2008, commit
86b87221fd0edf9a495e512247cb708cd6f4217a
Maybe he can remember why.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 suggestions
Valentin Villenave wrote Wednesday, October 20, 2010 7:48 PM On Wed, Oct 20, 2010 at 7:20 PM, Trevor Daniels wrote: Many thanks for your comments. At first glance they all seem pertinent. I'll have a look at fixing them up tomorrow. I've taken the liberty to apply James' suggestions myself: Many thanks! Nice work James! Indeed! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 suggestions
James
Many thanks for your comments. At first glance they all seem
pertinent. I'll have a look at fixing them up tomorrow.
I'm actually dealing with TODOs dotted around the file in no
particular order, so there is no high-water mark for the changes
I've made. You could read and comment down to 2.1.7.
Trevor
- Original Message -
From: "James Bailey"
To: ; "Trevor Daniels"
Sent: Wednesday, October 20, 2010 5:55 PM
Subject: NR 2.1 suggestions
These are just some things that I noticed.
2.1.1 Entering Lyrics.
Lyrics are entered in a special input mode, which can be introduced
by the keyword \lyricmode, or by using \addlyrics or \lyricsto. In
this mode…
Which mode? This has bugged me for a while, and since changes are
being made, can I request one here? As far as I understand, it's a
statement referring to the generic mode used for entering lyrics,
but because a keyword and two other things which haven't yet been
defined have been mentioned in the same sentence as this mode for
entering lyrics, it would be very helpful for a clearer sentence,
i.e.,
Lyrics are entered in a special input mode, which can be introduced
by the keyword \lyricmode, or by using \addlyrics or \lyricsto. In
this special input mode…
Punctuation, lyrics with accented characters, characters from
non-English languages, or special characters (such as the heart
symbol or slanted quotes), may simply be inserted directly into the
input file, providing it is saved with UTF-8 encoding.
Can I request/suggest an example that more clearly shows this?
Maybe »Schad‘ um das so schö -- ne grü -- ne Band« (Slightly adapted
from Die Schöne Müllerin to fit the notes already in the example.)
The first stanza is not aligned with the notes because the durations
were not specified, and the default value of 2 is used for each
word.
Doesn't this use the value of 2 because that was the last explicit
value used? If the preceeding note has a value of 4, then it uses
the value 4.
\version "2.13.36"
<<
\new Voice = "one" \relative c'' {
\time 2/4
c4 b8. a16 g4. f8 e4 d r4 c
}
% uses previous explicit duration 4;
\new Lyrics \lyricmode {
Joy to the earth!
}
% explicit durations, set to a different rhythm
\new Lyrics \lyricmode {
Life4 is love,2. live4 life.2
}
Why is "Keeping Contexts Alive" a "see also" for "Manual syllable
durations"? Nothing regarding why this is necessary is mentioned
there. If anything, it should be in the section on "Automatic
syllable durations"
Thanks for reading, and I really like a lot of the changes. For
context, up to which section is the rewrite finished?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
Keith E OHara wrote Tuesday, October 19, 2010 10:34 PM On Tue, 19 Oct 2010 13:34:05 -0700, Trevor Daniels wrote: If no one objects soon I shall push it. James Lowe made comments that you might not have seen yet. I see where he is coming from, but I hope my answer explained the purpose of the changes well enough. Yes, I saw that. That was why I felt a little more text and perhaps an earlier example without the tags would help. (For future reference, please avoid trailing whitespace, and if possible save the diff or patch with unix line endings - makes life easier :) Can do (but with extra steps that I might forget despite best intentions). No problem if you forget - it just means extra steps for me :) I think we need a clearer description about using instrument definitions in relation to cued notes I searched, but found no reason to use these features together. I merely lacked the confidence to suggest removing those sentence altogether. I too couldn't see how they helped here. If no one suggests otherwise I'll simply remove that sentence. (I have used \instrumentSwitch and \addInstrumentDefinition in NR 2.1.6 under Character names. Seems to work well for that.) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
Trevor Daniels wrote Tuesday, October 19, 2010 9:35 PM Keith E OHara wrote Tuesday, October 19, 2010 12:21 AM Suggestions attached as a diff, I'm happy to push this as is. Many thanks Keith. Pushed to git pretty well as you suggested, Keith, and snippet updated in git. Changed version will appear in the 2.13.37 release. Thanks again Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
Keith E OHara wrote Tuesday, October 19, 2010 12:21 AM
One thing worth discussing is that I use the verb "to cue"
differently from the original author.
I believe that to cue is to *give* a signal for someone else to
begin action. So the instrument playing just before the singer
begins is the cue-ing instrument (or the quoted instrument) and
the singer is cued. Similarly, the notes are 'cue notes', which
we might have hyphenated fifty years ago, rather than 'cued
notes'.
Suggestions attached as a diff,
except that the cueWhile function is in a snippet, not the .itely,
so the corresponding change is below :
cueWhile =
#(define-music-function
(parser location instrument name dir music)
(string? string? ly:dir? ly:music?)
#{
\cueDuring $instrument #$dir {
\once \override TextScript #'self-alignment-X = #RIGHT
\once \override TextScript #'direction = $dir
s1*0-\markup { \tiny $name }
$music
}
#}
)
I'm happy to push this as is. Many thanks Keith.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody understand the instrumentCueName docs?
Keith E OHara wrote Monday, October 18, 2010 11:40 PM
I suggest (diff attached) removing the part about
instrumentCueName in favor of a fuller example for \killCues. The
manual teaches markup elsewhere; the challenge with cue-note
labels is to let the label appear with the cue notes in parts, but
not in the score.
Your patch is a definite improvement, IMO. If no one objects soon I
shall push it. I think it might be further improved by a little
more text,
as someone coming to this for the first time might still find it
rather
difficult as it is. But I'm happy to add that.
(For future reference, please avoid trailing whitespace, and if
possible
save the diff or patch with unix line endings - makes life easier :)
Related changes (in the same diff) that you can take if you like :
1) \cueDuring #"flute" may be used *before* \addQuote "flute"
\flute appears in the source file, and knowing that empowers
users to write parts that quote each other.
It's worth mentioning this - I'll add it.
2) Two pieces of instruction were a bit vague :
"It is possible to tag cued parts with unique names in order to
process them in different ways."
"[...] when cue notes end, the name of the original instrument
should be printed, and any other changes introduced by the cued
part should be undone. This can be accomplished by using
@code{\addInstrumentDefinition}"
I think the intent was to teach how to handle clef changes (as in
the thread
<http://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00278.html>)
As replacement I suggest, after the fuller \killCues example, :
+The @code{\killCues} command removes only the notes and events
+that were quoted by @code{\cueDuring}. Other markup associated
+with cues, such as clef changes and a label identifying the
source
+instrument, can be tagged for selective inclusion in the score;
+see @ref{Using tags}. Clef changes and instrument labels can be
+collected into an instrument definition for repeated use, using
+...@code{\addinstrumentdefinition} described in @ref{Instrument
+names}.
I think we need a clearer description about using instrument
definitions
in relation to cued notes (at least I do!) I shall need to
investigate this
aspect further. Unless you can provide an example ... ?
3) The description of transposedCueDuring might have been wrong
(or I interpreted it wrongly) in the case of transposing
instruments.
My suggested replacement comes from experiment and inspection of
quote-iterator.cc.
Happy to take this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: TODO in vocal
Valentin Villenave wrote Monday, October 18, 2010 1:47 PM On Mon, Oct 18, 2010 at 12:03 PM, Trevor Daniels wrote: There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff << Voice \lyricsto >> bug If it really is a bug then we shouldn't be documenting it anyway, but I'd like to know what it means first. Do you know which bug it is referring to? I don't know, it seems that Han-Wen added it in the first place: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=7fd51755d9bdf40766a612b3c3e9a00f68238082 Of course, we didn't use the tracker back then, so it's hard for me to pinpoint what he was referring to. Perhaps something like http://lists.gnu.org/archive/html/bug-lilypond/2004-01/msg00190.html or http://lists.gnu.org/archive/html/bug-lilypond/2004-01/msg00276.html ? Well, neither of those problems still exist ... Anyway, back then lyricsto had just appeared (replacing \newaddlyrics), the syntax was still quite different from what we now know, so I guess this todo: can just go away quietly. .. so, yes, I'll just quietly remove this TODO Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
TODO in vocal
Valentin There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff << Voice \lyricsto >> bug If it really is a bug then we shouldn't be documenting it anyway, but I'd like to know what it means first. Do you know which bug it is referring to? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with 2.13.30?
Valentin Villenave wrote Sunday, October 17, 2010 4:57 PM On Tue, Sep 7, 2010 at 1:01 AM, Trevor Daniels wrote: Looks good to me. I'll confirm when the GUB 2.13.33 for Windows is available. sorry for bumping this discussion, but: where are we wrt this problem? Whoops, sorry, I forgot to report this. Reinhold's patch did fix it. Do we need to open a tracker page about it? No need now. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup wrote Thursday, October 14, 2010 10:05 AM "Trevor Daniels" writes: Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is just another. \override permits appropriate setting to be made at each point in the score. You don't know in advance where the pagebreaks are. And you don't get coherent document design if you have to place a bunch of manual parameters at every element. Well IWBN if LilyPond could be clever enough to deal with all possible layouts perfectly, but a music score is much more complex that textual layout, and that is hard enough. There is also a fair amount of personal preference involved to, so I don't see how manual tweaks can be avoided. One possibility is to define a number of different settings which might give tight spacing, loose spacing, one suitable for a book of songs, one for a vocal score, etc. That might get users off to an acceptable start. Variables or music functions can be used to make this less painful, e.g. \editorialNote could be defined to set the spacing parameters, set \noPageBreak, print the following markup and then revert the spacing parameters. I don't think that this is a sensible change for 2.14. I do. If at some time in the future the code is changed to recognise the distinction between a title and a footnote the names of the new spacing parameters would naturally follow the new naming pattern, although I think that change is unlikely to happen. And it is particularly unlikely to happen, because then we need to invent and maintain score-footnote-spacing, system-footnote-spacing, markup-footnote-spacing, footnote-footnote-spacing, footnote-score-spacing, footnote-markup-spacing, footnote-system-spacing, footnote-bottom-spacing, top-footnote-spacing and the associated page break penalties. In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. OK, I take that point. This clearly can't happen. So we're back to making this easier by defining suitable music functions for common situations which employ \markup, like the \editorialNote I suggested earlier to place an editorial note underneath a system. That would seem to deal with that example. Do you have any others? Could they also be handled in a similar way? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup wrote Thursday, October 14, 2010 8:42 AM Carl Sorensen writes: On 10/13/10 2:40 PM, "David Kastrup" wrote: The point is that we want a sane way of specifying document layout parameters. The current naming scheme resembles that desire. The current code not. Adapting the naming scheme to the deficiencies of the code is going the wrong way in my opinion. As far as I can see, we have no plans to change the code. And certainly not before 2.14 is released. So the decision we have to make is what documentation we place in the 2.14 release. Let me put it bluntly: the new scheme cements the decision to make markups and titles have the same spacing. A score followed by a title needs a solid amount of spacing and is an excellent position for a page break. A score followed by an editorial note "* this may be f# instead" needs a small amount of spacing and is an awfully bad position for a page break. If those cases are treated the same, it is a bug. We are now transplanting this bug from the code into the user interface where it will be rather cemented. Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is just another. \override permits appropriate setting to be made at each point in the score. Variables or music functions can be used to make this less painful, e.g. \editorialNote could be defined to set the spacing parameters, set \noPageBreak, print the following markup and then revert the spacing parameters. I don't think that this is a sensible change for 2.14. I do. If at some time in the future the code is changed to recognise the distinction between a title and a footnote the names of the new spacing parameters would naturally follow the new naming pattern, although I think that change is unlikely to happen. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Valentin Villenave wrote Wednesday, October 13, 2010 4:03 PM Hi Trevor, here's a minor patch for Vocal music. Nothing too extraordinary so far, I quite like what you've done! I've done about a third of the file, I plan to work on the rest later (though it may have to wait for a while :) Great! Thanks Valentine. As I'm still working on the file I took the liberty to push this for you. That way I could make sure we don't get any conflicts. I also pushed a supplementary which changed a couple of things further (or back). As I haven't yet dealt with any of the TODOs that remain could you please leave these in (unless you deal with them yourself. :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Graham Percival
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git grep
"@rgloss{system}"
I would recommend adding this to Learning 2 Tutorial. Maybe
somewhere in 2.3 Multiple notes at once; maybe somewhere in
2.5 Final touches. I'll let somebody else think about it in more
detail and produce a patch.
OK, I just pushed these changes. I left out an image
for system, as this is defined wrt the width of the
page, which is not well-defined in the docs (the image
width is less than the page width, and the page width
is variable in html).
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
James wrote Tuesday, October 12, 2010 1:27 PM On 12/10/2010 12:54, David Kastrup wrote: James writes: Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? Because there is no system after the bottom? ? I'll stop if I am really showing my ignorance (I am not a code developer), I'm afraid you're showing your ignorance as a musician. System and score are not synonomous. A system is a "line" of music which includes the all the staves which are grouped together. Conductor scores will usually have one system per page; vocal scores of SATB plus piano reduction will usually have two systems per page. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky wrote Saturday, October 09, 2010 4:46 PM It's not that I want to split hairs; I want to get the new variable names right the first time. My apologies to any of you who are getting tired with this process. :) Yes, thanks! I'm afraid I'm no longer following this discussion sufficiently carefully to tender sensible comment, and I wonder if the law of diminishing returns didn't kick in a couple of variations ago. Whatever is decided, and the final decision rests with you and Joe, Mark, the change in the names, together with the changes to the documentation, are going to result in a big improvement in 2.14. I think now it would be better to push the changes, fix the documentation, and let us try using it to see if any more tweaks are worth making. It will be much easier to judge the efficacy when we try using it practically rather than thinking about it in abstract. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NR 2.1 Vocal music
Graham
I've just pushed a patch to NR 2.1 Vocal music which provides a
first draft for the last of the blank sections marked TBC ("To Be
Completed"). I believe it's now in a much better shape than it was,
even though much of the chapter is in "first draft" state.
Next up are the 19 TODOs, and I'd like to work through them before
inviting a review of the whole chapter, although if you or anyone
else wishes to comment on the work so far I'd be happy with that
too.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky wrote Wednesday, October 06, 2010 4:46 PM I also think the name 'space is misleading; I propose 'default-distance. Opinions? I'd be happy with that change too. Mark Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staff sizes...
Arno Waschk wrote Wednesday, October 06, 2010 1:27 PM why does the following: [snip> give a small piano part (which i expected) but a normal sized bassPart Staff? It does give a small bassPart here (2.13.34). What do you have in bassPart? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
Mark Polesky wrote Tuesday, October 05, 2010 7:09 PM http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html Let me know what you guys think; it would be nice to achieve consensus on this one. I'm with Carl on this. I agree with all his comments. Further to my suggestion to leave the renaming to GLISS, so far there have been only comments supporting the renaming, even from Joe. Since no discussion seems to be necessary, do you think it might be better to change the names before 2.14? That way users would only have to understand one change in the stable releases rather than two. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: docs addition, beaming cadenzas
Keith E OHara wrote Tuesday, October 05, 2010 7:18 AM In the existing @knownissues for cadenzaOn, I suggest adding one sentence (in context below) encouraging manual beams. Users might *think* autobeaming works through cadenzas, and it does for a while, but it will not through longer cadenzas. Thanks, Keith. I made this change pretty much as you suggested. [Graham: I believe it is right to include issues marked as enhancements in the known issues list, especially those with low priority. If these are ever implemented the docs will need to be changed anyway, unlike bug fixes, so the known issue list can then be amended.] The immediately-following example depended on autobeaming, I made its beam manual. (While I'm at it, I suggest this one be an @example, because in this case the _code_ is the point, and the image gives no useful information.) Agreed Two earlier examples use autobeaming in their cadenzas, so I marked the two affected lines below, but this detail is not worth much effort. I fixed them anyway as you suggested Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky wrote Monday, October 04, 2010 11:14 PM Usually when I propose things like this, they're shot down pretty fast, but here goes anyway. It took me a while to mentally connect the names of the vertical spacing variables with their specific domains. For example, I think it's counterintuitive that 'after-title-spacing does *not* affect the spacing after a title when it's followed by another title or markup. The appropriate one for that is 'between-title-spacing. Also, some confusion arises before getting used to the fact that markups are also referred to as "title". [snip] Regardless, I prefer the consistency and predictability of the proposed names. Comments appreciated, thanks! Looks a good suggestion to me, but discussion is better deferred until GLISS is launched. Don't lose it! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What am I doing wrong here?
David Kastrup wrote Sunday, October 03, 2010 3:22 PM
push = -\tweak #'side-axis #X ^\markup { \musicglyph
#"accordion.push" }
pull = -\tweak #'side-axis #X ^\markup { \musicglyph
#"accordion.pull" }
\score {
\repeat unfold 8 { c'-1\push c'-1\pull }
}
Why does this work nice with \push, and not so nice with \pull?
Is this
supposed to work at all?
Well the character box is defined differently for the two
glyphs. See mf/feta-accordion.mf. The box for the pull
glyph is set further to the right.
I presume that is why, but I don't know if there is a good
reason for the difference.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
markpolesky wrote Saturday, October 02, 2010 5:09 PM Okay, here we go... Hooke's law: F=-kx "x" is the displacement of the end of the spring from its equilibrium position (in SI units: "m"); "F" is the restoring force exerted by the material (in SI units: N or kg·m/s^2); and "k" is the force constant (or spring constant) (in SI units: N/m or kg/s^2). So, according to Joe, stretchability is equal to 1/k. So, if we use "s" for stretchability, then F=-x/s That's not really needed. Here's the point: For each spring y = -sF, so dy = -sdF (1) When the contents of a page are being stretched the same force is applied to every spring, so the ratio of the increase in length of any two springs is equal to the ratio of their stretchabilities. So if you need to stretch the contents of a page by an amount y, y = sum(dy's) = -dF sum(s's) sum(s's) is known, a constant, so that gives dF, and then all the separate dy's can be calculated from (1). Units are irrelevant, as it's only the ratios of the s's that are important. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Help with trying to alter an @lilypond example in the NR for Tracker item 1033
James Lowe wrote Wednesday, September 29, 2010 10:57 PM The current example I am having problems with is in 5.1.4 Modifying context plug-ins. The example in the current document is: --- @lilypond[quote,relative=1,ragged-right,verbatim,fragment] This should be @lilypond[quote,verbatim] otherwise the whole thing is placed in a \relative block, which doesn't work with \score. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 1.5.2: Clarify voice order; \shiftOn etc. (issue2226045)
markpolesky wrote Thursday, September 23, 2010 3:51 PM On 2010/09/22 14:53:15, Graham Percival wrote: Documentation/notation/simultaneous.itely:392: @example Can't this @example be removed, now that there's the @lilypond just below it? as I think more about visual-impairment accessibility, I feel that the @example is immediately readable without the code clutter. I'll remove it if you feel strongly. As this is the only point of this small section I'd prefer to keep the @example. Okay to push? OK by me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: targeting specific context ID's from within \layout?
Mark Polesky wrote Tuesday, September 21, 2010 6:35 AM % Is there a way to target a specific context (eg. one of % several Staff contexts) from within the \layout block? I don't believe so. Modifying a single named context is the only reason for the continued existence of the ungainly \with clause. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.2.1 keyboards, staff changes
Keith E OHara wrote Monday, September 20, 2010 12:38 AM I am suggesting a new @knownissues for the Notation Reference 2.2.1. The corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is solved, the second paragraph of my suggestion will become obsolete. I wrote the text below based on observed behavior of LilyPond 2.12.3 and 2.13.33 (as opposed to understanding its code). I have been using the workaround for six months, including about three piano pieces where the work-around-able issue came up. Keith Although this would seem to be a valuable addition to the Notation Reference, the policy is not to add bugs which are in the bug tracker to @knownissues. With 420 open bugs, adding each of them to the documentation is both impractical and wasteful of resources, as they would need to be removed as soon as they were fixed, often within a few weeks. An exception might be made for defects marked "postponed", as that means they will not be fixed in the foreseeable future. But that doesn't apply to any of these bugs at present. But thanks for taking the trouble to do this. Even if it doesn't make it to the docs your post will remain available in the archives where it can be found by others. [Graham: I know this is, or at least was, the policy, but I don't see it in the CG.] Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Doc: LM 3.2: Entering voices in the correct order.
Mark Polesky wrote Sunday, September 19, 2010 7:51 AM Carl Sorensen wrote: Well, the Notation Reference is supposed to contain all the information necessary to understand all the notation. If the information on voices isn't in the Notation Reference, then we'll need to have links from the NR to the LM for fundamental operation of commands. We don't want to have duplication. Although I didn't mention it this way before, I think that we need this information in the NR. Hmm. Now I'm inclined to agree with Carl. Here's a new patch. What do you guys think of the new placement. Do you think the text flows well in this order, etc.? I'm not particularly opposed to placing this in the NR, but it's not clear what you are suggesting here. Do you mean to leave the LM unchanged, or do you intend to remove or change the corresponding section there? Also, if it is to go in the NR it needs a separate section heading. At the moment it appears under "The double backslash construct", whereas it applies equally to explicitly instantiated voices. Maybe something like "Voice order"? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Doc: LM 3.2: Entering voices in the correct order.
Mark Polesky wrote Saturday, September 18, 2010 7:23 PM This patch should prevent the type of confusion that leads to bug #45: http://code.google.com/p/lilypond/issues/detail?id=45 Comments/objections? Okay to push? I like it; much improved! I (more or less[1]) agree with Graham's comments, but unlike Carl I think this section should remain in the LM. It is part of a much longer logical layout which would be broken if these two sections were lifted out. One comment. The example which follows the first part of the patch, Chopin's Deux Nocturnes, Op 32, does not follow this new advice! Should it be reworked also? [1] I like the list of voices. Also doesn't @enumerate introduce blank lines between items? That would spoil it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Absolute dynamics as postfix text (issue2220041)
wrote Wednesday, September 15, 2010 3:05 PM [snip the meat] This breaks the doc build. *cough* make sure that David isn't looking>you idiot I implore you, oh kind and gentle contributor, to check a full build, from scratch, before proposing a large change. I like it! This is even more entertaining! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
Valentin Villenave wrote Wednesday, September 15, 2010 12:42 AM On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival wrote: On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels wrote: You know, after rebuffs like this it's hardly surprising you don't get many people offering to help you. Seeing this, anyone thinking of offering will likely think again. Valentin is a personal friend, and the grumpy/fluffy interplay has been a constant between us. I take much more liberties with him than I would anybody else. Yes, I know that, and I know Valentin's coefficient of restitution is amazingly high! But some of us are more brittle, and don't (immediately) bounce back. You just need to be reminded of that from time to time :) Whilst I do understand that such tactless rebuttals might look impressive and unappealing to newcomers That was my point. Long-standing members of -devel enjoy the lively interchange, but newcomers don't know the background. But after this exchange they do, so please bicker on :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Indentation in parser.yy
Graham Percival wrote Tuesday, September 14, 2010 2:24 PM On Tue, Sep 14, 2010 at 03:11:53PM +0200, Valentin Villenave wrote: It's not much, but since it does change quite a few lines (in a such critical source file, on top of that), there's no way I'm gonna try and push that myself :-) Rejected. Don't manually screw with indentation, especially in a critical source file. If this is part of work on 746, we can talk, although since I offically Started work on it... err... oops, I forgot to claim the issue. /me runs off and does that. Ok, basically, I'm preparing the background for our discussion about indentation, *after* 2.14 is out, and *after* I have enough information to lay out the positive and negative aspects. I don't see much potential for positive outcomes until that's done, so I urge you to withdraw the patch and everybody else to ignore this. You know, after rebuffs like this it's hardly surprising you don't get many people offering to help you. Seeing this, anyone thinking of offering will likely think again. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: texinfo @ mangling
Damn! Hit the send key accidently before I'd finished. Here's the full reply: Mark Polesky wrote Sunday, September 12, 2010 7:45 PM Is there a way to bypass the automatic "obscuring" of email addresses on any of the mailing list servers? There may be, but I think the recent discussions about the mailing lists have made it pretty clear that the LilyPond lists are not going to be changed. I get the feeling Graham is not inclined to even discuss changes any more. Can anything be done about it? Yes. Patches should be posted on Reitveld. Anyone with a gmail address can do this, and anyone can easily get a gmail address. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: texinfo @ mangling
Mark Polesky wrote Sunday, September 12, 2010 7:45 PM Is there a way to bypass the automatic "obscuring" of email addresses on any of the mailing list servers? There may be, but I think the recent discussions about the mailing lists have made it pretty clear that the LilyPond lists are not going to be changed. I get the feeling Graham is not inclined to even discuss changes any more. Can anything be done about it? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Graham Percival wrote Saturday, September 11, 2010 8:30 PM On Sat, Sep 11, 2010 at 9:08 AM, Trevor Daniels wrote: 2.1.8 Opera and stage musicals ready for review Err... 2.1.6 in today's current git? ok, doing so. I've forgotten anything else we've discussed about 2.1 vocal music, which may or may not be a good idea for this doc review. My mistake - it used to be 2.1.8 before I reorganised the first two sections. - I see significant material in the "top" of 2.1.6. Remember that some people only look at the "leaves" of the documentation. In this case, that's "References for opera and stage musicals". In the html view the pages are split only at the numbered sections, so the whole of 2.1.6 appears as a single page. So I think this is fine at this level. I'm not certain how important the definition of conductor's score, orchestral parts, libretto, etc., are, but if they stay where they are, then the rest of this subsection should not assume that the reader has seen those definitions. See previous comment. I'd also be tempted to move some of these definitions to the Glossary, and omit the others. I mean, I'd expect that people are sufficiently familiar with "conductor's score" and "orchestral parts", whereas "libretto" could definitely use a Glossary entry. At first glance, I'd then make this material merely: The music, lyrics and dialogue to opera and stage musicals are usually set out in one or more of the following forms: a conductor's score, the orchestra parts, a vocal score, a vocal book, and a libretto. ... actually, I think I definitely recommend moving this material into the References, and splitting the long list of References into their relative sections. i.e. have two lists: "... one or more of the following forms:" * Conductor's score: - grouping staves, nested staff groups. (you're missing a comma before the "see Nested staff groups, btw) - hiding parts - separating systems NB: umm, aren't those all the subsections of 1.6 ? I'd be sorely tempted just to say "Many useful techniques for preparing conductor scores are presented in Staff notation". I mean, it's a short section, and at least 80% of it is highly relevant to preparing scores. It's not too much to suggest that the user to read the whole thing. - is Page formatting any more relevant to musicals than other forms of music? I suppose it might be important for preparing a small booklet (i.e. print on 4 sides of a folded a4 sheet). OTOH, I'd expect that to be relevant to hymn as well, and possibly choral stuff in general. I'm quite willing to believe that we should improve the docs for spacing (especially since I've been publicly saying that I wanted a complete rewrite of that chapter for the past 3 years :). And in particular, it might be good to have a dedicated section for small booklets / alternate forms of music display / etc. OK, let's drop the page formatting bit. - notwithstanding all the above, I like the specific mention of instrument names for character names. I still think that you should only have a single link to Staff notation, but I think it's definitely worth having 1-2 sentences explaining about the instrument name trick. Alternately, this could be done with a @lilypond . For comparison, see 2.3.1 Bowing indications, Harmonics, etc. None of that is *new* notation (pretty much everything is already in the articulation appendix), but we decided that it's worth giving a few short examples for clarity. I think I'll do this in a separate subsubsec - Character names. And I think I'll make separate sections for cues as well. Then I'll see if the remaining references need re-arranging as you suggest. ... err, does anybody know why snap pizzicato is a snippet? Yes, you replied on 6 Oct 2008 to my query: = "Trevor Daniels" wrote: => What do you think about including the Bart__k pizzicato as a => @lilypondfile in this section? It's quite technical, so I've left it => as just a marker for now while I canvass opinion and let my own => thoughts gel. = = Sure. = = Cheers, = - Graham The snippet already existed. I can't remember who prepared it. anyway, although we really discourage duplicating material, we make allowances for small, well-focused cases of specific instrumental (and vocal) writing. Nothing to do with vocal though ... err, "dialogue over music" just says TBC. Am I looking at an old version? I'm pretty certain that I just compiled the docs from scratch (testing Carl's funky fix)... did you push everything? I'm wondering again about the 2.1.8 vs. 2.1.6 question... I'll stop reviewing whatever it is that I'm r
Re: source code on windows
Graham Percival wrote Saturday, September 11, 2010 8:36 PM Does anybody deal with lilypond source code on windows itself, instead of lilybuntu? Trevor? I do _all_ my doc work on Windows, with a Windows git repository. I have ubuntu available in a VM, but it causes a significant slow-down of all my normal work when it's loaded due to increased paging (I have 3 Gb RAM, the maximum available in my laptop), so I try to avoid using it. In fact I only use it for code development, and I've done none of that for several months. I'm looking at CG 2, and I'm not certain it makes sense to keep the "git on windows" stuff. If somebody can't build lilypond, then the source code is of limited use, and lilybuntu seems to be working well for people. So I'm thinking about removing all instructions for windows development, and instead directing people to CG 1.3 Lilybuntu. Thoughts? It is certainly of limited use but, with the script I provided and Carl improved and installed, it is very easy to do doc work on Windows. For someone totally unfamiliar with Unix this would be an easier way in. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Trevor Daniels Thursday, August 26, 2010 10:41 PM Trevor Daniels wrote Thursday, August 19, 2010 6:40 PM I've finished and pushed the first pass through 2.1.7 Choral. I'll begin work on 2.1.9 Chants hymns and psalms next. First pass through 2.1.9 Chants etc done. I'll look at 2.1.8 Opera and stage musicals next. 2.1.8 Opera and stage musicals ready for review Any chance you could look over and comment on 2.1.7 and 2.1.9, please? Thanks for the review Graham - all suggested changes done. I'll continue working through the TBC's. Next up is Lyrics and repeats in 2.1.2 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Graham Percival wrote Friday, August 27, 2010 9:54 PM Pointing a psalm - I got a bit lost here. Could you add a @lilypond to illustrate some (or all) of those points (no pun intended)? I've just pushed an expanded version of this section with several illustrative examples. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Trevor Daniels wrote Wednesday, September 08, 2010 12:15 AM
Graham Percival wrote Tuesday, September 07, 2010 8:14 PM
On Wed, Sep 01, 2010 at 09:15:26AM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, August 27, 2010 9:54 PM
>- can't you do \layout { \context { \dynamicsUp }} ? After
>mentioning
>\dynamicsUp, it feels really weird to see the arcane \override
>command
>in there.
No, it seems predefs are not permitted in \context
blocks:
Oh yes, another of our bugs that IIRC doesn't have an issue
number. Could you report it to the Bug Squad, or add it to the
tracker yourself? (after checking that I Did Recall Correctly,
and that it really isn't in the tracker)
Will do
Issue 1254.
BTW, we've both specified \dynamicsUp, whereas the
(current) correct name is \dynamicUp. I bet everyone
makes this mistake. Something to change in GLISS, I
think.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
