Re: Doc music examples should be on 1 line
Graham Percival wrote Tuesday, February 16, 2010 4:12 AM
On Tue, Feb 16, 2010 at 12:34 AM, Trevor Daniels
wrote:
While answering a user question I noticed that
some examples in the LM which were earlier on
a single line now spread undesirably over two
lines in both html and pdf versions. You can
see several examples in 4.5.3.
I'm happy to fix these, but I'm not sure what
I should change. Can you suggest anything?
IIRC, the default lilypond-book options were changed some time
around
2.13.6 or so. It caused all the regtests to be marked as
"changed",
which prompted a round of work on lilypond-book and the regtest
checking script, or something. Oh wait, it was the hashing: we
ended
up keeping the regtests with their original filenames.
I think this happened in Nov or Dec... it was definitely between
Sep and Jan.
A quick glance at the exact .ly files of the first item in 4.5.3
in
2.13.13 and 2.12.3 supports this:
2.13.13:
\paper {
indent = 0\mm
line-width = 5.5\in
line-width = 5.5\in - 2.0 * 0.4\in
ragged-right = ##t
force-assignment = #""
line-width = #(- line-width (* mm 3.00))
}
OK, I started some research.
I fixed exactly this problem for LM 4.5.3 on
13/9/2009 by adding line-width = 5.5\in to the
@lilypond[] commands which invokes these examples.
That was effective at the time, but the lilypond
book settings of line-width are now overridden by
the insertion of line-width = 5.5\in - 2.0 * 0.4\in.
That line was not being inserted last Sept -
it renders all explicit settings of line-width
in the @lilypond[] command ineffective.
The change happened sometime after 2.13.4-1. I'll
try to narrow down when it happened more closely.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Marc Hohl writes:
> I have also thought about implementing this properly.
>
> I had the idea to extend the \repeat syntax:
>
> \repeat segno {.A.}
> \alternative {{ .B. }{ .C.}}
That appears quite preferable to me. One problem I see is that there
sometimes is a number of repeat structures. And sometimes a number of
ways to keep them unnested.
I have here a piece. This has more or less the following parts:
[unlabeled], 2, 3, Coda. Those parts are more or less formatted as
separate movements (possibly with vertical space above them, all
starting on a system of their own) but have to be played continuously.
Each of the parts (except the Coda) has its own repeat structure. And
pretty much each of them are not anticipated in Lilypond.
Ok, here to the parts.
Part1:
<><><><>
Here we start at the beginning and go through once into the first
alternative labelled "Folge" and jump over the second alternative
labelled "Fine" into the repeat volta. We do the first alternative
"1.", repeat the repeat volta and go into the second alternative "2.".
Then we jump back to the segno at "Valse 1", now using the "Fine"
alternative.
The advantage over a D.S. al Coda is that it is nuisance to have to
visually jump over a long part just for a single chord Coda.
Note that "Fine" has just two beats and anticipates a key change to B
flat major.
Ok, now part 2 is a bit too subtle for my taste.
<><><>
We start with the missing upbeat from part 1's "Fine" in B major. There
is a repeat volta which is not uncommon. At the end of the second
repeat alternative, we have "D.S. al ||". It turns out that "||" is not
a double bar, but rather the caesura/breathmark before the repeat volta.
There is no other caesura, and part 3 begins with a 2/4 upbeat
complementing the bar before the caesura.
Now we might be of the opinion that this score has provided us with
enough crazy tasks for typesetting (the anticipated key change at the
end of something formatted as a movement is rather tricky, I guess) and
for \unfoldRepeats, but no such luck.
Here is part 3:
<><><><>
Now part 3 is unique in that it has an optional repetition. I can't
actually reliably guess the meaning.
The first alternative is labelled "(ad lib)" and has a parenthesized
segno and key change. If you take the ad lib, execution is back to
parenthesized segno and then into second repeat alternative.
What happens if you don't take the ad lib repetition? In that case,
three interpretations:
Play alternatives 1&2
Play just alternative 1
Play just alternative 2
It makes most sense musically to skip the first repeat alternative
completely (1&2 is conceivable, but changes the character of the
ending). Which makes it somewhat nonsensical to have everything inside
of that alternative parenthesized, since once you decide you take the
first alternative, the material inside is not optional.
The last part, "Coda", obviously, starts in F major. It has no repeats
and is off-topic.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
"David Pounder" writes: >> --- Original Message --- >> From: Ian Hulin >> To: David Pounder > > Apologies for the blank replies - my e-mail client has been playing > up. While you are at it: could you _please_ cut out anything from your article quotes that is not relevant to your reply, and only provide the immediate context you are referring to instead of the whole thread so far? If I want to read the entire previous article, I can ask my newsreader to fetch it. If you are replying to several points, intersperse your replies with the relevant original points. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Hi David,
On 16/02/10 07:00, David Pounder wrote:
--- Original Message ---
From: Ian Hulin
To: David Pounder
Sent: 15.2.10, 22:18:25
Subject: Re: [frogs] Da Capos, Codas and Segnos
On 15/02/10 18:47, David Pounder wrote:
--- Original Message ---
From: Ian Hulin
To: Lilypond Frogs List
Sent: 15.2.10, 17:40:48
Subject: [frogs] Da Capos, Codas and Segnos
Hi Frogs and Developers,
This is by way of limbering up for a discussion on the GLISS list when
it gets going.
I'm trying to think of all the commoner combinations of Segnos, Codas
and Da Capo instructions so maybe we can work out a consistent syntax
for addressing what are, after all, variations on the theme of repeat
blocks.
Here are the ones I can think of off the top of my head
Da Capo al Fine:
A "Fine" B "Da Capo al Fine" ==> A B A
Dal Sego Al Fine
A "§" B "Fine" C "Dal Segno Al Fine" ==> A B C B
Da Capo Al Coda
A B "©" C "Da Capo al Coda" "©" D ==> A B C A B D
Dal Segno Al Coda
A "§" B C "©" D "Dal Segno al Coda" E ==> A B C D B C E
Firstly, can anyone think of any more combinations I may have missed here?
To Trio.
Thanks for that, David, but isn't that a variant of "Da Capo al Coda" ?
A B "second time to Trio" C "Da Capo" D "Trio" ==> A B C A B D .
Maybe need to think about adding alternate text for \tocoda.
Apologies for the blank replies - my e-mail client has been playing up.
I was thinking that if you want to represent the musical structure of a piece
in terms of repeated sections then a trio is different to a coda, and both are
often present in the same piece. Added complication is that the trio may
contain volta repeats.
David.
A volta repeat or repeats is simply a musical expression, so can be left
to the stage when the music expression passed to \dalsegno or \dacapo is
evaluated
\version "2.13.nn"
Asection = { c1 | c1 | } %Section A
Bsection = { f1 | f1 | }% Section B
Csection = { g1 | g1 |} % Section C
Dsection = {\repeat volta 2 {bes1 bes1 | es1 | f1 |} \alternative { {f1
|} {f2 g2} }} % Coda or Trio
\relative c {
\clef treble
\time 4/4
%{ proposed syntax
\Asection \dalsegno coda {\Bsection \tocoda \Csection \enddalsegno
\Dsection}
%or
\Asection \dalsegno coda {\Bsection \tocoda "to Trio" \Csection
\enddalsegno \Dsection}
%}
\Asection \Bsection \Csection \Dsection
}
However, there may be a problem if a \repeat block is included as part
of Bsection and/or Csection, as the current \repeat doesn't need to have
a clear end delimiter and may get confused if you try to nest \repeat
volta blocks with \alternative clauses. We're sort of nesting repeats
if we have \repeat volta ... \alternative in Bsection or Csection here,
so it may be a corner condition. I'll have to get prototyping to check.
Hope your e-mail client is feeling better, David.
Marc, any thoughts?
If we go with \repeat segno that would mean \repeat would *have* to be
able to be nested, and would need to have counter of how deeply nested
we are in repeat blocks: each new \repeat would need to increment it and
there would need to be some consistent point at which to decrement it -
possibly a \endrepeat statement.
Btw, if anyone thinks you never need to nest \repeat volta blocks, check
out the vocal score for Ariel Ramirez, Misa Criola, Gloria (there's
always a cheap-skate publisher somewhere trying to save paper al all costs).
We may need this stuff anyway if we use \dalsegno \dacapo - hence why I
think this is a GLISS-type discussion.
Thanks, guys for all the feedback so far,
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Hi all, I've been lurking a bit on this thread, but felt I should comment. I personally think we need a more general structure than \repeat will ever be able to reasonably offer. Essentially, we need to be able to say that a single movement/piece [of Lilypond code] consists of one or more \section blocks, where a \section would have at least the following independent options: 1. indent value[s] and/or line lengths; 2. section title (e.g. "Trio"). Then, each section can or cannot include standard Lilypond \repeat structures, as necessary. BTW: I'm *not* saying that Lilypond's \repeat structure shouldn't be improved -- I'm just suggesting that we might be looking at two different problems here. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Kieren MacMillan writes: > Hi all, > > I've been lurking a bit on this thread, but felt I should comment. > > I personally think we need a more general structure than \repeat will > ever be able to reasonably offer. My take on this is that we need the equivalent of (multiple) "goto" and function calls in the basically notation-linear music flow for establishing a performance-linear music flow. The latter would be instantiated when \UnfoldRepeats is in action. Since in essence the number of imaginable repeat constructs is infinitive (I posted such a sequence right now), those performance-linear operators need to be accessible to a normal user, so that a normal user can pepper his score with the respective "to be performed in this order" instructions. Those "goto" and "function calls" should be able to have some basic effects not just on performance, but also on typesetting: ties starting before a branch point (or function return) need to be ended in each branch, the same for slurs and so on. Meter/key changes need to be preannounced when the performance-linear order will make them come up next. Once appropriate low-level primitives/events for the performance-linear "goto/branch/call" are established, repeat volta and everything else can be implemented in terms of them, and cautionaries, preannouncements (which pretty much should be identical to prebreak behavior) and stuff can be made to work in terms of the low-level events, not needing to cater specifically for the various repeat/volta/segno/whatever categories. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Hi David, Excellent points -- in particular: > Those "goto" and "function calls" should be able to have some basic > effects not just on performance, but also on typesetting: ties starting > before a branch point (or function return) need to be ended in each > branch, the same for slurs and so on. [!!!] > Meter/key changes need to be preannounced when > the performance-linear order will make them come up next. I hope Lilypond eventually has such capabilities. Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc music examples should be on 1 line
Trevor Daniels wrote Tuesday, February 16, 2010 9:59 AM
Graham Percival wrote Tuesday, February 16, 2010 4:12 AM
On Tue, Feb 16, 2010 at 12:34 AM, Trevor Daniels
wrote:
While answering a user question I noticed that
some examples in the LM which were earlier on
a single line now spread undesirably over two
lines in both html and pdf versions. You can
see several examples in 4.5.3.
I'm happy to fix these, but I'm not sure what
I should change. Can you suggest anything?
IIRC, the default lilypond-book options were changed some time
around
2.13.6 or so. It caused all the regtests to be marked as
"changed",
which prompted a round of work on lilypond-book and the regtest
checking script, or something. Oh wait, it was the hashing: we
ended
up keeping the regtests with their original filenames.
I think this happened in Nov or Dec... it was definitely between
Sep and Jan.
A quick glance at the exact .ly files of the first item in 4.5.3
in
2.13.13 and 2.12.3 supports this:
2.13.13:
\paper {
indent = 0\mm
line-width = 5.5\in
line-width = 5.5\in - 2.0 * 0.4\in
ragged-right = ##t
force-assignment = #""
line-width = #(- line-width (* mm 3.00))
}
OK, I started some research.
I fixed exactly this problem for LM 4.5.3 on
13/9/2009 by adding line-width = 5.5\in to the
@lilypond[] commands which invokes these examples.
That was effective at the time, but the lilypond
book settings of line-width are now overridden by
the insertion of line-width = 5.5\in - 2.0 * 0.4\in.
That line was not being inserted last Sept -
it renders all explicit settings of line-width
in the @lilypond[] command ineffective.
The change happened sometime after 2.13.4-1. I'll
try to narrow down when it happened more closely.
The change seems to have started after commit
c258b7788db8a717b4741f02d9f5cc52862338d4
which was applied by John on Christmas Eve.
As part of his tidying up, the option list is
sorted in line 1236, which places the line-width
lines in a different order, and causes the default
to be applied after the override, rendering the
override ineffective. I'll push a fix to comment
out the sort for now, until John can check this
out more carefully.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Is ssh to Savannah failing?
I've not been able to push to Savannah this afternoon. I get: ssh: connect to host 199.232.41.69 port 22: Bad file number fatal: The remote end hung up unexpectedly Same error with pull. Is this a problem at the Savannah end or mine? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Helping translators do their work
2010/2/13 Graham Percival : > But until/unless that happens, > we'll maintain the status quo. I understand it. But to put it simple: I'm not smart enough to guess what did happen in such a complex commit, and that leads to nearly undoable translation updates. Others may be smarter than me, so it is maybe easier for them. Not everybody has time enough to solve hard puzzles like this. I am just asking for small things that would lead to big improvements: this is all efficiency. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Doc: CG: add lily-git instructions.
Any objections? Okay to push?
- Mark
From 8bdf00a89df764363d02972bca571464dc50f650 Mon Sep 17 00:00:00 2001
From: Mark Polesky
Date: Tue, 16 Feb 2010 10:10:44 -0800
Subject: [PATCH] Doc: CG: add lily-git instructions.
---
Documentation/contributor/source-code.itexi | 102 ++-
1 files changed, 101 insertions(+), 1 deletions(-)
diff --git a/Documentation/contributor/source-code.itexi b/Documentation/contributor/source-code.itexi
index 0c837b8..9e371ac 100644
--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -20,7 +20,107 @@
@section Using lily-git
-FIXME: Add instructions for using @command{lily-git} here.
+If you haven't already, download and install Git. Go to
+...@uref{http://git-scm.com/download}, and in the @qq{Binaries}
+section, select the appropriate package for your operating system.
+Windows users should visit
+...@uref{http://code.google.com/p/msysgit/downloads/list} and
+download the @file{.exe} file labeled @qq{Full installer for
+official Git}.
+
+...@c don't change the cgit link below to gitweb; gitweb uses
+...@c long filenames like "scripts_auxiliar_lily-git.tcl"
+
+The lily-git script is located at
+...@uref{http://git.sv.gnu.org/cgit/lilypond.git/plain/scripts/auxiliar/lily-git.tcl}.
+Using a web browser (or @command{wget}), save the page as
+...@file{lily-git.tcl}.
+
+To run the program from the command line, navigate to the
+directory containing @file{lily-git.tcl} and enter:
+
+...@example
+wish lily-git.tcl &
+...@end example
+
+
+...@subsubheading The @qq{Get source} button
+
+When you click the @qq{Get source} button, @command{lily-git} will
+create a directory called @file{lilypond-git/} within your home
+directory, and will download the complete source code into that
+directory (around 55Mb). When the process is finished, the
+...@qq{command output} window will display @qq{Done}, and the button
+label will change to say @qq{Update source}.
+
+Navigate to the @file{lilypond-git/} directory to view the source
+files. You should now be able to modify the source files using
+your normal text editor.
+
+
+...@subsubheading The @qq{New local commit} button
+
+A single commit typically represents one logical set of related
+changes (such as a bug-fix), and may incorporate changes to
+multiple files at the same time.
+
+When you're finished making the changes for your first commit,
+click the @qq{New local commit} button. This will open the
+...@qq{git Commit Message} window. The message header is required,
+and the message body is optional. See @ref{Commits and patches}
+for more information regarding commits and commit messages.
+
+After entering a commit message, click @qq{OK} to finalize the
+commit.
+
+
+...@subsubheading The @qq{Amend previous commit} button
+
+You can go back and make changes to the most recent commit with
+the @qq{Amend previous commit} button. This is useful if a
+mistake is found after you've clicked the @qq{New local commit}
+button. To amend the most recent commit, edit the source files
+as needed and click the button. The earlier version of the commit
+is not saved, but is replaced by the new one.
+
+Note that this does not update patch files; if you have a patch
+file from an earlier version of the commit, you will need to make
+another patch set when using this feature. The old patch file is
+not saved, but is replaced by the new one.
+
+
+...@subsubheading The @qq{Make patch set} button
+
+...@warning{before making a patch set from any commits, you should
+click the @qq{Update source} button to make sure the commits are
+based on the most recent remote snapshot.}
+
+When you click the @qq{Make patch set} button, @command{lily-git}
+will produce patch files for any new commits, saving them to the
+current directory. The command output will display the name of
+the new patch files near the end of the output:
+
+...@example
+0001-CG-add-lily-git-instructions.patch
+Done.
+...@end example
+
+Send patch files to your mentor if you have one. Otherwise, write
+an email to @email{lilypond-devel@@gnu.org} briefly explaining
+your work, with the patch files attached. Translators should send
+patches to @email{translations@@lilynet.net}.
+
+
+...@subsubheading The @qq{Abort changes -- Reset to origin} button
+
+...@warning{only use this if your local commit history gets
+hopelessly confused!}
+
+The button labeled @qq{Abort changes -- Reset to origin} will copy
+all changed files to a subdirectory of @file{lilypond-git/} named
+...@file{aborted_edits/}, and will reset the repository to the
+current state of the remote remote repository (at
+...@code{git.sv.gnu.org}).
@node Starting with Git
--
1.6.3.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is ssh to Savannah failing?
Trevor Daniels wrote: > I've not been able to push to Savannah this afternoon. I > get: > > ssh: connect to host 199.232.41.69 port 22: Bad file > number fatal: The remote end hung up unexpectedly > > Same error with pull. > > Is this a problem at the Savannah end or mine? I did a successful ssh pull at 6:04pm GMT. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is ssh to Savannah failing?
Mark Polesky wrote Tuesday, February 16, 2010 6:19 PM Trevor Daniels wrote: I've not been able to push to Savannah this afternoon. I get: ssh: connect to host 199.232.41.69 port 22: Bad file number fatal: The remote end hung up unexpectedly Same error with pull. Is this a problem at the Savannah end or mine? I did a successful ssh pull at 6:04pm GMT. Thanks Mark. Looks like I have a problem :( Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: Helping translators do their work
Hi guys, Il giorno mar, 16/02/2010 alle 19.07 +0100, Francisco Vila ha scritto: > I understand it. But to put it simple: I'm not smart enough to guess > what did happen in such a complex commit, and that leads to nearly > undoable translation updates. Others may be smarter than me, so it is > maybe easier for them. Not everybody has time enough to solve hard > puzzles like this. > > I am just asking for small things that would lead to big improvements: > this is all efficiency. OTOH we'd like to require that commits don't break docs build, which is incompatible with what you're asking. A compromise might be more detailed commit messages that explain what has been done, and possibly a few hints on *how* it's been done. I used to like the idea motivated by efficiency that such changes are done once in all languages, but given my time available for participating and the available volunteer time for this, this idea must be abandoned for now. Best, John signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc music examples should be on 1 line
Il giorno mar, 16/02/2010 alle 15.23 +, Trevor Daniels ha scritto: > The change seems to have started after commit > c258b7788db8a717b4741f02d9f5cc52862338d4 > which was applied by John on Christmas Eve. > As part of his tidying up, the option list is > sorted in line 1236, which places the line-width > lines in a different order, and causes the default > to be applied after the override, rendering the > override ineffective. I'll push a fix to comment > out the sort for now, until John can check this > out more carefully. Unless the docs output caused by this issue is unbearable even during the two days it may take me to fix it from now, please don't commit this so-called fix. Thanks, John signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Ian Hulin schrieb:
Hi Marc,
On 15/02/10 18:32, Marc Hohl wrote:
Ian Hulin schrieb:
[...]
Secondly, what I had in mind was this kind of thing:
* \dalsegno and \dacapo - both of these start off a segno/dacapo
section. I know it's a bit weird that the \dacapo command would
have to be at the start of the score, but I think it would be
beneficial in terms of syntax checking.
* \dalsegno and \dacapo both take a keyword and a music expression
as parameters. The keyword is either /coda/, /fine/ or it is
omitted. If it is omitted it defaults to /fine/.
* \fine - checks if a \dacapo or \dalsegno block are current and
that the last \dalsegno or \dacapo used a /fine/ keyword. If so
it, generates a double bar and "Fine" markup.
* \tocoda - checks if a \dacapo or \dalsegno block are current,
and that the last \dalsegno or \dacapo used a /coda/ keyword.
If so it generates a double bar and "Al ©" markup. (For © read
the coda hot-cross-bun sign).
* \endDaCapo, \endDalSegno terminate the block. They firstly
check if a block is current, and what kind of keyword was used.
If the block was started with a /fine/ keyword, it generates a
double bar and a markup "Dal Segno"|"Da Capo" al "Fine"|"Coda",
depending on the type of block and the keyword parameter used.
o If the coda keyword was used a \break is generated and the
© markup generated ready for the next music expression.
Comments welcome.
Hi Ian,
I have also thought about implementing this properly.
I had the idea to extend the \repeat syntax:
\repeat segno {.A.}
\alternative {{ .B. }{ .C.}}
could start part A with a segno sign, draw a coda sign at the start
of B,
creates a markup or something similar saying "D.S. al ø-ø", then
does (perhaps) a line break and draws the corresponding coda symbol
at the beginning of part C.
(And if there is no music before part A, this could become "Da Capo"
and no segno signs are drawn).
Not all D.S. or D.C. blocks end with a jump to a Coda, would you want
to have another parameter
\repeat segno coda-or-fine-keyword {A}
\alternative {{B} {C}}.
Also don't \repeat and \alternative at the moment have potential
problems with which \alternative strictly belongs to which repeat,
because there is no explicit function to end the block?
Or were you relying on the whether \alternative has a single music
expression or a list of music expressions to determine whether you're
dealing with Al Coda (if it's a list) or Fine (if there's one music
expression)?
I can see the attraction of using \repeat since it is conceptually
closely related to what happens for segnos and codas, but I feel if we
go down this route, the \repeat and \alternative functions risk
getting overloaded to the extent that they may become difficult to
document and therefore hard for users to learn to use.
After reading through the other posts, I think that overloading \repeat
would not cover *all* possible
cases. On the other hand, there should be *one* consistent way of doing
any kind of repeats.
David's comparison with goto-like structures seems to be the right
approach, so I revert my
proposal about enhancing \repeat for a more universal structure.
[...]
It was your work on issue 659 that started me thinking about this stuff.
:-)
Grüsse aus England,
Thanks!
Greetings from Germany,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: Helping translators do their work
2010/2/16 John Mandereau : > OTOH we'd like to require that commits don't break docs build, which is > incompatible with what you're asking. OK. My apologies for having pushed some changes in the past which led to broken docs; in this case, I was confident in that moving blocks in originals should be updated by moving blocks in translations. My wrong, too confident from my side, because the moving blocks hid "random" (i.e. hardly detectable) edits without which the translation cannot be built. > I used to like the idea motivated by efficiency that such changes are > done once in all languages, but given my time available for > participating and the available volunteer time for this, this idea must > be abandoned for now. So, let's keep the status quo and make translators support all the weight of solving the puzzles. :-( No problem (for me). -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc music examples should be on 1 line
John, you wrote Unless the docs output caused by this issue is unbearable even during the two days it may take me to fix it from now, please don't commit this so-called fix. It's not an urgent problem, and I can't push a fix anyway at the moment, so I'm happy to leave it to you. Thanks. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancements on Issue 659: alternate segno symbol (issue181144)
Carl Sorensen schrieb: On 2/15/10 12:33 PM, "Marc Hohl" wrote: Hello all, I have uploaded some enhancements due to Alexander Kobel's proposals. The first attempt to upload broke on my console with some error messages, so I did it again - now I see that I uploaded two identical versions. And furthermore, the changes to scm/tablature.scm which Carl had pushed already are in this patch set, too, due to a missing "git pull" just before rebasing, so I uploaded another version. When you upload a patch set that has errors in it, you can delete the patch set using the Delete patch set link on the issues home page. Didn't know that option - thanks for the hint! I used to just be embarrassed when I posted bad patch sets; now I just delete them and post a new one right away. The other thing I discovered that helped with my "oops" patches on Rietveld is that I can do "git diff" before I do "git-cl upload" and that gives me a chance to review things locally. Actually, I did a "git diff" but somehow overlooked the spurious tablature entry (WYSIWYWTS: what you see is what you want to see :-) It would be fine to calculate the width of the segno stencil automatically, but I hardcoded the value, so it seems to work fine. Have you checked it with various staff sizes? Yes. The width of the segno sign is 2.5 staff_spacing units, so the hardcoded value is clumsy, but correct. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Obtaining the dimensions of a glyph (or a stencil) within c++
Patrick McCarty schrieb:
Hi Marc,
On 2010-02-15, Marc Hohl wrote:
I have
Stencil segno = Font_interface::get_default_font (me)->find_by_name
("scripts.varsegno");
How can I get the width of the glyph? Or alternatively, can I get
the width of the stencil defined as above?
Untested, but something like this should work:
Stencil segno =
Font_interface::get_default_font (me)->find_by_name ("scripts.varsegno");
Real width = segno.extent (X_AXIS).length ();
Yes, it works, thank you!
Marc
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 659: alternate segno symbol (issue181144)
carl.d.soren...@gmail.com schrieb: Looks good to me, with the exception of the hardcoded value stuff. Thanks, Carl http://codereview.appspot.com/181144/diff/4008/5018 File lily/bar-line.cc (right): http://codereview.appspot.com/181144/diff/4008/5018#newcode242 lily/bar-line.cc:242: m.add_at_edge (X_AXIS, RIGHT, thick, 2.5 * staff_space + 2 * thinkern); // Urg, hardcoded value If you are going to use the hardcoded value (which I think is not a good idea; you can call ly_stencil_extent to get the width of the segno stencil), then I think it would be better to define a local variable for your hardcoded value, i.e. float segno_width = 2.5 * staff_space // Urg, hardcoded value so that it's clear what the 2.5 is for. I used Patrick's proposal and it seems to work fine (see the uploaded patch set). Moreover, I compiled lilypond a dozen times yesterday, and today, make failed because I "forgot" the closing >"< on several lines, but these chars definitely were already missing yesterday. Marc http://codereview.appspot.com/181144/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is ssh to Savannah failing?
On 2/16/10 10:46 AM, "Trevor Daniels" wrote: > > ssh: connect to host 199.232.41.69 port 22: Bad file number > fatal: The remote end hung up unexpectedly > I got this problem when I had a bad ssh key. I think it was a bad key file, but I may have needed to create a new key pair to get it back working. I can't remember the details, because it was about 3 years ago. Good luck! Carl, ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc music examples should be on 1 line
On Tue, Feb 16, 2010 at 08:02:11PM +0100, John Mandereau wrote: > Il giorno mar, 16/02/2010 alle 15.23 +, Trevor Daniels ha scritto: > > The change seems to have started after commit > > c258b7788db8a717b4741f02d9f5cc52862338d4 > > which was applied by John on Christmas Eve. > > As part of his tidying up, the option list is > > sorted in line 1236, which places the line-width > > lines in a different order, and causes the default > > to be applied after the override, rendering the > > override ineffective. I'll push a fix to comment > > out the sort for now, until John can check this > > out more carefully. > > Unless the docs output caused by this issue is unbearable It's not. I'm perfectly happy releasing 2.14 with this. > even during the two days it may take me to fix it from now, > please don't commit this so-called fix. I'm also unhappy with this fix, although for completely different reasons. There's no good reason to increase the line-width. 1) if the larger line-width looks good on all output, then it should be the default. 2) if it doesn't work on *all* outputs... HTML, info, pdf, pdf printed on A4, pdf printed on USletter, HTML on a screen with 800 pixels wide... then the music should be changed to fit the available space. A thorough examination of the lilypond-book paper options for the docs would be a bit more work than I think we want to do at the moment. I've added it as issue 1015. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: Helping translators do their work
On Tue, Feb 16, 2010 at 08:11:37PM +0100, Francisco Vila wrote: > 2010/2/16 John Mandereau : > > OTOH we'd like to require that commits don't break docs build, which is > > incompatible with what you're asking. > > OK. My apologies for having pushed some changes in the past which led > to broken docs; That's not what John was talking about -- your proposal of splitting doc commits would lead to the English docs being broken "in between" those splits. > > I used to like the idea motivated by efficiency that such changes are > > done once in all languages, but given my time available for > > participating and the available volunteer time for this, this idea must > > be abandoned for now. > > So, let's keep the status quo and make translators support all the > weight of solving the puzzles. :-( It would be nice if we had a dedicated translation translator, pun intended. Somebody who would merge changes from master into lilypond/translation, and merge changes from lilypond/translation back into master. I think it would be about 1 hour a week. > No problem (for me). Look, the problem is that you don't have enough technical people working on the translation infrastructure. You guys have been coasting and relying on John to do it all; he's too busy for that. I'm not going to pick up this slack; I have enough tasks already. And I'm not going to put more of a burden on the main documentation people, since they're already far overworked. If the translations are important, somebody will step forward to help with this technical task. If nobody volunteers, then obviously they're *not* important. Just like most other parts of lilypond... almost nobody is volunteering to work on the docs. Almost nobody is volunteering to work on the build system. Almost nobody is volunteering to work on the regression bugs. Problems for the translations are the *least* of my concerns. Sorry, but that's just how things are in lilypond at the moment. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: CG: add lily-git instructions.
On Tue, Feb 16, 2010 at 10:16:11AM -0800, Mark Polesky wrote:
>
> +The lily-git script is located at
> +...@uref{http://git.sv.gnu.org/cgit/lilypond.git/plain/scripts/auxiliar/lily-git.tcl}.
Could this be inside an @example ?
> +Using a web browser (or @command{wget}), save the page as
> +...@file{lily-git.tcl}.
I'd rather not confuse people with wget. I'd just write:
-
Download the lily-git script from:
@example
@uref{http://git.sv.gnu.org/cgit/lilypond.git/plain/scripts/auxiliar/lily-git.tcl}.
@end example
-
if somebody wants to download it with smoke signals, more power to
them.
> +To run the program from the command line, navigate to the
> +directory containing @file{lily-git.tcl} and enter:
> +
> +...@example
> +wish lily-git.tcl &
> +...@end example
I'd omit the & -- again, let's try to avoid confusing windows
users. Unix people know how to add & if they want it. If
somebody on windows wants to know how to run the command and still
be able to use that particular terminal, they can ask their
mentor.
Based on my experience in teaching programming to newbies, I don't
want to underestimate the cognitive load of looking for an
unfamiliar character on a keyboard.
(yes, cue snarky comments about how bad the younger generation is.
But it's the younger generation of Canadians *and* Scots that seem
to get thrown for a loop trying to find the ; symbol on their
keyboard. :(
> +...@subsubheading The @qq{Get source} button
Could this be
@subsubheading Get source / Update source
? I'd like to have the second label in there as well... also, I
think the double-quotes and "The button" are unnecessary.
> +...@subsubheading The @qq{Make patch set} button
> +
> +...@warning{before making a patch set from any commits, you should
> +click the @qq{Update source} button to make sure the commits are
> +based on the most recent remote snapshot.}
I'd rather not use a @warning here; we should reserve them for
only truly vital things. Plain text should be sufficient.
> +...@subsubheading The @qq{Abort changes -- Reset to origin} button
> +
> +...@warning{only use this if your local commit history gets
hopelessly confused, or under the direction of your mentor!}
Looks great! If you agree with those comments, please change and
then push. If you disagree with them, go ahead and push anyway
(it's definitely good enough to get into git), and we can continue
talking. :)
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Da Capos, Codas and Segnos
Marc Hohl writes: > After reading through the other posts, I think that overloading > \repeat would not cover *all* possible > cases. On the other hand, there should be *one* consistent way of > doing any kind of repeats. > > David's comparison with goto-like structures seems to be the right > approach, so I revert my > proposal about enhancing \repeat for a more universal structure. Oh I think we are not communicating. I liked your proposal quite well, even though it did not cover "everything conceivable". What I was talking about that in order not to have a proliferation of things that work/expand with only a subset of the supported repeats, that the internal music data structures gain a few "linkages" or whatever you want to call it that cover the possible sequencing. For example, one could have an element "multibranch" that contains a sequence of music list tails (or #t to continue on the printed score). When this element is passed/played the first time, it takes the first branch, then the next... It should be reasonably easy to perform this with this info, and reasonably easy to produce the right amount of preannounce material. Doing cautionary accidentals correctly needs the reverse information, namely instead of "where can I be going to from here" the info "where can I be coming from here". But the point is that "repeat volta" and "coda" and whatever else in the music list should be just interesting for the grob engraver, and performer and repeat unfolder and cautionaries and stuff get their info from a lower-level primitive data structure. Like a compiler compiling conditionals to jnz, the high level language with which we specify the structures should be powerful enough to avoid the explicit use of "goto" whenever possible. But there might be some user-level description of the logical structure that can get by without use of "goto" at the input level, even though it may get compiled to such. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: Helping translators do their work
Am Dienstag, 16. Februar 2010 19:59:06 schrieb John Mandereau: > Hi guys, > > Il giorno mar, 16/02/2010 alle 19.07 +0100, Francisco Vila ha scritto: > > I understand it. But to put it simple: I'm not smart enough to guess > > what did happen in such a complex commit, and that leads to nearly > > undoable translation updates. Others may be smarter than me, so it is > > maybe easier for them. Not everybody has time enough to solve hard > > puzzles like this. > > > > I am just asking for small things that would lead to big improvements: > > this is all efficiency. > > OTOH we'd like to require that commits don't break docs build, which is > incompatible with what you're asking. A compromise might be more > detailed commit messages that explain what has been done, and possibly a > few hints on *how* it's been done. OTOH, why it is such a problem if the docs don't build after one particular commit (which only moves completely unchanged sections around)? If the commit to fix the build again is committed immediately afterwards (and both commits pushed to the server at the same time), the current master will always compile, although some intermedient commit might not. That way translators can easily figure out how to move translated sections around and then do the build fixes afterwards. In my eyes, this would be a good middleway to make work easier for translators, while still having buildable docs all the time. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
rebasing multiple git branches at once (part 2)
This is a continuation of an earlier thread:
http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00534.html
I suppose I have a different git style than Carl and Trevor;
I don't really see the value in keeping outdated branches.
Or put another way, I don't see the harm in keeping all my
branches current.
Anyway, in case anyone might benefit from this, here's the
script I'm currently using. With this script, I can select
exactly the branches I want to rebase, or just use "--all"
(which is what I usually do).
As with the previous version, rebases abort at the slightest
sign of a problem, and the output clearly shows which
branches succeeded/failed.
Here's the header:
# rebase-multiple.sh --
# * rebase local master to remote master, and
# * rebase local git branches to updated local master
#
# Usage:
# rebase-multiple.sh
# rebase-multiple.sh --all
See the attachment for the full script.
- Mark
#!/bin/bash
# rebase-multiple.sh --
# * rebase local master to remote master, and
# * rebase local git branches to updated local master
#
# Usage:
# rebase-multiple.sh
# rebase-multiple.sh --all
# exit without a branch list or --all
if [[ ( $# -eq 0 ) || ( $1 == "--all" && $# -gt 1 ) ]]; then
echo -e "Usage:" \
"\n `basename $0` " \
"\n `basename $0` --all" >&2
exit 1
fi
# remember where we started
starting_branch=`git branch | sed -n 's/^\* //p'`
return_from_branch () {
if [[ $1 != $starting_branch ]]; then
echo
git checkout $starting_branch
fi
}
rebase_abort_verbose () {
echo "Aborting rebase on branch '$1'..." >&2
git rebase --abort
git status
}
# exit now if we can't checkout master
if [[ $starting_branch != master ]]; then
git checkout master || exit 1
fi
# update master
if ! git pull --rebase; then
rebase_abort_verbose master
return_from_branch master
echo -e "\nERROR: There was a problem with 'master'." \
"\n No branches were rebased." >&2
exit 1
fi
# parse arguments
if [[ $# -eq 1 && $1 == "--all" ]]; then
# sed removes current branch `* master' from rebase_list
# `--reverse' leaves local branches in order in gitk.
rebase_list=`git branch | sed '/^\*/d' | sort --reverse`
else
rebase_list="$@"
fi
# rebase local branches to master where possible
successful_branches=""
failed_branches=""
for branch in $rebase_list; do
echo
if git rebase master $branch; then
successful_branches="$successful_branches\n$branch"
else
failed_branches="$failed_branches\n$branch"
rebase_abort_verbose $branch
fi
done
# return to starting branch
return_from_branch $branch
# report success/failure
if [[ $successful_branches ]]; then
successful_branches=`echo -e \
"$successful_branches\nmaster" | sort`
echo -e "\nThe following branches are up to date:"
for branch in $successful_branches; do
git branch --no-color | sed -n "/^[* ] $branch$/p"
done
fi
if [[ $failed_branches ]]; then
failed_branches=`echo -e "$failed_branches" | sort`
echo -e "\nThe following branches failed to rebase:"
for branch in $failed_branches; do
git branch --no-color | sed -n "/^[* ] $branch$/p"
done
exit 1
fi
exit
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
