Re: Why don't we get rid of \chordmode?
On Thu, Apr 29, 2010 at 10:53 PM, Neil Puttock wrote:
> On 29 April 2010 21:36, Graham Percival wrote:
>> That would already be handled by
>> { ...} * 4
>> which is much more intuitive than ;4
I hadn't even considered that: to me, '*' means altering durations, so
I'd expect such a syntax to work in a way similar to
http://lsr.dsi.unimi.it/LSR/Item?id=305
Therefore, ':' seemed much more natural (or, as Carl suggested, ';').
> You took the words straight out of my mouth. :)
>
> I'm afraid I couldn't resist testing this, so if you're interested,
> try the attached patch.
Awesome. I had no idea this would be so frigging simple :-)
I can't stand letting this patch get lost. Added as
http://code.google.com/p/lilypond/issues/detail?id=1067
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Typo in index of Documentation/notation/text.itely
---
Documentation/notation/text.itely |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/notation/text.itely
b/Documentation/notation/text.itely
index d108520..93c4552 100644
--- a/Documentation/notation/text.itely
+++ b/Documentation/notation/text.itely
@@ -398,7 +398,7 @@ syntax called @qq{markup mode}.
@cindex markup expressions
@cindex expressions, markup
@cindex markup syntax
-...@cindex synatax, markup
+...@cindex syntax, markup
The markup syntax is similar to LilyPond's usual syntax: a
@code{\markup} expression is enclosed in curly braces @co...@{
--
1.6.5.3.153.g0670
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Am Freitag, 30. April 2010 10:04:42 schrieb lilyp...@googlecode.com:
> { music expression } * 4
> instead of
> \repeat unfold 4 { music expression }
I don't think this is a good idea with this syntax: How would you explain to
a new user the difference between the following two:
{c1}*4
c1*4
or
{c}*4
c*4
Cheers,
Reinhold
--
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
* LilyPond music typesetting software, http://www.lilypond.org/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Typo in index of Documentation/notation/text.itely
On Fri, Apr 30, 2010 at 1:41 AM, David Kastrup wrote:
> ---
> Documentation/notation/text.itely | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/notation/text.itely
> b/Documentation/notation/text.itely
> index d108520..93c4552 100644
> --- a/Documentation/notation/text.itely
> +++ b/Documentation/notation/text.itely
> @@ -398,7 +398,7 @@ syntax called @qq{markup mode}.
> �...@cindex markup expressions
> �...@cindex expressions, markup
> �...@cindex markup syntax
> -...@cindex synatax, markup
> +...@cindex syntax, markup
>
> The markup syntax is similar to LilyPond's usual syntax: a
> �...@code{\markup} expression is enclosed in curly braces @co...@{
> --
> 1.6.5.3.153.g0670
Thanks, applied.
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Reinhold Kainhofer writes:
> Am Freitag, 30. April 2010 10:04:42 schrieb lilyp...@googlecode.com:
>> { music expression } * 4
>> instead of
>> \repeat unfold 4 { music expression }
>
> I don't think this is a good idea with this syntax: How would you explain to
> a new user the difference between the following two:
>
> {c1}*4
> c1*4
1*4 is a duration, *4 is a repeat factor. If you want to have c1
repeated 4 times, write {c1}*4.
One _could_ thing about allowing c1*1*4 too, but that is a spectacularly
bad idea not just for readability:
You'll notice that when considering what
<< {c1}*4 >> does.
It creates a _sequence_, not a _stack_ of notes. So the operation of *4
is _sequential_ like the sequence in the braces. With << c1*1*4 >>
there is no sequential music inside.
Which makes it interesting to consider what to do about
MUSIC_IDENTIFIER * 4
My personal take would be to not split hairs and make a sequential
repetition regardless of whether MUSIC_IDENTIFIER happens to point to
sequential or parallel music.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Typo in index of Documentation/notation/text.itely
Patrick McCarty writes: > On Fri, Apr 30, 2010 at 1:41 AM, David Kastrup wrote: >> --- >> Documentation/notation/text.itely | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > Thanks, applied. I'm streamlining my patch posting processes. Y'all be begging me to accept commit privileges soon enough. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Am Freitag, 30. April 2010 11:08:02 schrieb David Kastrup:
> Reinhold Kainhofer writes:
> > Am Freitag, 30. April 2010 10:04:42 schrieb lilyp...@googlecode.com:
> >> { music expression } * 4
> >> instead of
> >> \repeat unfold 4 { music expression }
> >
> > I don't think this is a good idea with this syntax: How would you
> > explain to a new user the difference between the following two:
> >
> > {c1}*4
> > c1*4
>
> 1*4 is a duration, *4 is a repeat factor. If you want to have c1
> repeated 4 times, write {c1}*4.
We understand that, because we are programmers. But try to explain that to a
musician, who hasnever written any program, so the concept of scoping via
{...} completely escapes him/her...
I'm sure as soon as this syntax is available, wewill be flooded with
questions/bug reports, why c4*4 does only print the first of the four repeated
quarter notes...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
* LilyPond music typesetting software, http://www.lilypond.org/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
Nicolas Sceaux writes:
> Le 29 avr. 2010 à 20:27, David Kastrup a écrit :
>
>> What type signatures would be actually permissable under the assumption
>> that they are supported by lexer and parser?
>>
>> It is somewhat clear to me that we can't have markup-list followed by
>> markup in the arguments. Anything else?
>
> I'd say, a markup-list command signature should follow the pattern:
>
>scheme* markup* markup-list*
>
> that is, any number of scheme arguments, then any number of single markup
> arguments, then any number of markup-list arguments, even though I don't
> know if having several markup list arguments is useful or not (and if it's
> doable).
I've read the syntax back and forth now and am of the opinion that
{ scheme | markup | markup_list }
should work fine for both markup and markup-list commands: namely no
restrictions regarding order and content. A markup-list is always
delimited and recognizable in the syntax. Some forms may be more
efficient to execute, but that's an implementation detail.
I am not sure yet that the Scheme macro markup builder will be equally
happy with this generality but see no immediate reason why it shouldn't.
There does not seem to be a compelling syntactical reason that a
composed sequence like
\raise #0.5 \bold \italic { }
is restricted to commands with signature
{ scheme } markup
rather than
{ anything } markup
but it currently appears to be an optimization consideration. So I'll
likely keep that around. Strictly speaking, one can always convert
(function markup scheme scheme)
into
(function scheme scheme) or even (function)
using closures. So one would not need to change the original evaluator,
and still get the same efficiency for the old input, while supporting
more forms.
But for now, I'll just keep composition to the existing
{ scheme } markup
signature.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Reinhold Kainhofer writes:
> Am Freitag, 30. April 2010 11:08:02 schrieb David Kastrup:
>> Reinhold Kainhofer writes:
>> > Am Freitag, 30. April 2010 10:04:42 schrieb lilyp...@googlecode.com:
>> >> { music expression } * 4
>> >> instead of
>> >> \repeat unfold 4 { music expression }
>> >
>> > I don't think this is a good idea with this syntax: How would you
>> > explain to a new user the difference between the following two:
>> >
>> > {c1}*4
>> > c1*4
>>
>> 1*4 is a duration, *4 is a repeat factor. If you want to have c1
>> repeated 4 times, write {c1}*4.
>
> We understand that, because we are programmers. But try to explain
> that to a musician, who hasnever written any program, so the concept
> of scoping via {...} completely escapes him/her... I'm sure as soon
> as this syntax is available, wewill be flooded with questions/bug
> reports, why c4*4 does only print the first of the four repeated
> quarter notes...
Sorry, but I think you are wrong. A musician will encounter
multiplicators most likely in the context of
{ R1*20 }
and that _is_ already strictly incompatible with the idea of a duration
modification since it _repeats_ the rest mark for every measure.
How many bug reports do you get about that?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Hi David,
> A musician will encounter multiplicators most likely in the context of
> { R1*20 }
Agreed.
> and that _is_ already strictly incompatible with the idea of a duration
> modification since it _repeats_ the rest mark for every measure.
I'm not sure that's how it works... I personally think of it as a duration
modification -- NOT a repeat -- where Lilypond is smart enough (see also
"Note_heads_completion_engraver") to *display* this modified duration as
multiple MultiMeasureRest objects. And I believe this intuition is supported by
the way that Lilypond collects MultiMeasureRests (with \skipBars).
Cheers,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Kieren MacMillan writes:
> Hi David,
>
>> A musician will encounter multiplicators most likely in the context of
>> { R1*20 }
>
> Agreed.
>
>> and that _is_ already strictly incompatible with the idea of a duration
>> modification since it _repeats_ the rest mark for every measure.
>
> I'm not sure that's how it works... I personally think of it as a
> duration modification -- NOT a repeat -- where Lilypond is smart
> enough (see also "Note_heads_completion_engraver") to *display* this
> modified duration as multiple MultiMeasureRest objects. And I believe
> this intuition is supported by the way that Lilypond collects
> MultiMeasureRests (with \skipBars).
For a real surprise, try
\score { << R1*20 d' >> }
as opposed to r1*20. It's not exactly related, but strange.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Hi David,
> For a real surprise, try
> \score { << R1*20 d' >> }
> as opposed to r1*20. It's not exactly related, but strange.
Why does this surprise you? If you think of R1*20 as a repetition -- as you
claim to -- then this should be exactly according to your expectations: the
whole-note MMR is repeated 20 times, and the following note (d) "inherits" the
duration (whole note) from the previous object (the MMR).
That being said, it does bring the internal workings into question…
Cheers,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
Kieren MacMillan writes:
> Hi David,
>
>> For a real surprise, try
>> \score { << R1*20 d' >> }
>> as opposed to r1*20. It's not exactly related, but strange.
>
> Why does this surprise you? If you think of R1*20 as a repetition --
> as you claim to -- then this should be exactly according to your
> expectations: the whole-note MMR is repeated 20 times, and the
> following note (d) "inherits" the duration (whole note) from the
> previous object (the MMR).
The surprise is that the rests appear in a system _below_ the whole
note. With r1*20, they appear above.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Kieren:
> > It's not obvious to me whether
> > c\chord #'(1 7)
> > should produce "c b" or "c bes". Musically speaking, I'd look at
> > the key signature; if it were c major, I would assume it meant
> > "c b" since "b" is the seventh note of the scale.
> >
> > This may be a problem for the numeric syntax. I suppose we could
> > define each number as being a perfect, major, or minor interval;
> > users can adjust those intervals with + or - as required.
>
> Or... we could use dodecaphonic intervals, i.e.
>
> c\chord #'(1 11) is a minor seventh
> c\chord #'(1 12) is a major seventh
>
> Of course, none of these ideas support systems with
> other-than-12-tones-per-octave
=(
I propose we skip the "number" things and go for a local translate,
see below last in mail.
One could misuse floating poing values:
c\chord_float #'(1 6.5) % minor seventh
c\chord_float #'(1 7.0) % major seventh
To explain that eis == f is doable, but how would one explain
that 3.5 == 4 ??
(That flaw was present in my inital proposal )
Rationals:
c\chord_rational #'(1 5/4 3/2) % "perfect" 3rd and 5th
% replace 5/4 etc. with the proper scheme expression
Cents:
c\chord_cent #'(0 386 702) % just intonation
Or other variants.
One could also define a shorthand translating thing, something like
(though I'm not shure what syntax to use):
"cis\chord_barre " ->
//
If we are discussing shortcuts to notate music (chordal notation are
shortcuts, is it not?), consider the similarity of:
<-> d\chord #'(1 3 5) % "parallell" music
{d fis a} <-> d\seq #'(1 3 5) % "sequential" music
There are two things here:
. replacing a note name with a number, eg. "e" -> 3
. naively replacing 3 for the interval third, gives use the enharmonic
problem of 3.5 == 4, and what does 7 mean, a minor or major 7th?
. using dodecaphonic, cents, retionals or the like somehow misses the
"shortcut"-idéa
. a local transposition, eg. d\chord... == \translate c d { c\chord... }
this would be a "better" \translate, since it would put the music
in the "current" octave
The chords are easily defined, we don't need any special
syntax for that (like \chordmode):
chord_major = \relative c { }
\translate below does not work since the "d" is not relative the
previous music:
... music ...
\translate c d \chord_major
... music ...
Could something like this (or some other syntax) be useful:
... music ...
d\tr\chord_major % --> in the current octave
... music ...
Going this route, one could define whatever complex chord expressable
in an ordinary <...>
Regards,
/Karl Hammar
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1067 in lilypond: Postfix syntax for repeats
On Fri, Apr 30, 2010 at 10:45 AM, Reinhold Kainhofer
wrote:
> I don't think this is a good idea with this syntax: How would you explain to
> a new user the difference between the following two:
>
> {c1}*4
> c1*4
That's why I initially suggested using ':' instead of '*'.
Another possibility (but I suspect it would require to fiddle with the
parser a lot more) would be to only allow this shorcut as a prefix:
4 * { music expression }
As I said earlier, I'd personally expect '{ expr } * 4' to multiply
durations by 4, like in LSR snippet #305. Which would be entirely
consistent with what '*' already does -- but not nearly as useful as
what Neil's patch does.
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
On Thu, Apr 29, 2010 at 5:13 PM, Nicolas Sceaux wrote: >> What type signatures would be actually permissable under the assumption >> that they are supported by lexer and parser? >> >> It is somewhat clear to me that we can't have markup-list followed by >> markup in the arguments. Anything else? > > I'd say, a markup-list command signature should follow the pattern: > > scheme* markup* markup-list* > > that is, any number of scheme arguments, then any number of single markup > arguments, then any number of markup-list arguments, even though I don't > know if having several markup list arguments is useful or not (and if it's > doable). AFAICR the ordering is just there for syntax consistency. If you can make a patch that generalizes markup argument handling like the argument handling for music functions, that would be awesome. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
Han-Wen Nienhuys writes: > On Thu, Apr 29, 2010 at 5:13 PM, Nicolas Sceaux > wrote: >>> What type signatures would be actually permissable under the assumption >>> that they are supported by lexer and parser? >>> >>> It is somewhat clear to me that we can't have markup-list followed by >>> markup in the arguments. Anything else? >> >> I'd say, a markup-list command signature should follow the pattern: >> >> scheme* markup* markup-list* >> >> that is, any number of scheme arguments, then any number of single markup >> arguments, then any number of markup-list arguments, even though I don't >> know if having several markup list arguments is useful or not (and if it's >> doable). > > AFAICR the ordering is just there for syntax consistency. If you can > make a patch that generalizes markup argument handling like the > argument handling for music functions, that would be awesome. I've went to scheme* markup* markup-list* right now (unifying the possible arguments for markup and markup list commands) and that appears to work without regression. The main problem here is that the syntax needs to tell (scheme* markup) markup command argument lists from the rest, because the former can be chained together and worked off with map-markup-command-list. I am not sure that it is worth the trouble: I have my doubts that map-markup-command-list pieces stuff faster together than the bison parser would when left to its own devices. After all, the latter does not need to meddle with closures. Will post patch soon. Docs are missing yet. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup-command and markup-command-list signatures
Han-Wen Nienhuys writes: > On Thu, Apr 29, 2010 at 5:13 PM, Nicolas Sceaux > wrote: >>> What type signatures would be actually permissable under the assumption >>> that they are supported by lexer and parser? >>> >>> It is somewhat clear to me that we can't have markup-list followed by >>> markup in the arguments. Anything else? >> >> I'd say, a markup-list command signature should follow the pattern: >> >> scheme* markup* markup-list* >> >> that is, any number of scheme arguments, then any number of single markup >> arguments, then any number of markup-list arguments, even though I don't >> know if having several markup list arguments is useful or not (and if it's >> doable). > > AFAICR the ordering is just there for syntax consistency. If you can > make a patch that generalizes markup argument handling like the > argument handling for music functions, that would be awesome. Well, they need to be in order yet. But other than that, the dependency appears to be gone. Check out http://codereview.appspot.com/969046> Should I post the patch series to the list? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
xref to @unnumbered* bug
I've noticed that cross-references to unnumberedsubsec's actually link to the section node one level up. For example, in NR 3.4.3 "Alternative output formats", clicking on the link to "Command line options for lilypond" sends me to Usage 1.2 "Command-line usage". Then I have to click on the menu link to actually get where I'm going. I guess this is a texi2html bug, since the problem doesn't happen in PDF. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
Carl Sorensen wrote:
> I disagree with the idea that the simplest solution is to
> move the \relative outside the \repeat.
I've attached a new patch following your suggestions.
Okay to push?
- Mark
From 40270827b0ac9ee4500b36038ee9ca83178e6e71 Mon Sep 17 00:00:00 2001
From: Mark Polesky
Date: Fri, 30 Apr 2010 09:42:15 -0700
Subject: [PATCH] Doc: Clarify \relative inside \repeat issue.
---
Documentation/notation/repeats.itely | 12 --
Documentation/usage/running.itely| 36 +
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/Documentation/notation/repeats.itely b/Documentation/notation/repeats.itely
index 9e2b53e..113b681 100644
--- a/Documentation/notation/repeats.itely
+++ b/Documentation/notation/repeats.itely
@@ -109,9 +109,10 @@ Normal repeats with alternate endings:
c1
@end lilypond
-...@warning{do not include @co...@bs{}relative} inside a
-...@code{@bs{}repeat}. It will cause unwanted staves to appear.
-See @rprogram{An extra staff appears}.}
+...@warning{if you include @co...@bs{}relative} inside a
+...@code{@bs{}repeat} without explicitly instantiating the
+...@code{voice} context, extra (unwanted) staves will appear. See
+...@rprogram{an extra staff appears}.}
@cindex repeat with upbeat
@cindex upbeat in a repeat
@@ -385,6 +386,11 @@ c1
c1
@end lilypond
+...@warning{if you include @co...@bs{}relative} inside a
+...@code{@bs{}repeat} without explicitly instantiating the
+...@code{voice} context, extra (unwanted) staves will appear. See
+...@rprogram{an extra staff appears}.}
+
@seealso
Snippets:
diff --git a/Documentation/usage/running.itely b/Documentation/usage/running.itely
index 93c0c3a..eeba9e8 100644
--- a/Documentation/usage/running.itely
+++ b/Documentation/usage/running.itely
@@ -649,17 +649,17 @@ line to break. For details, see @ruser{Bar lines}.
@node An extra staff appears
@unnumberedsubsec An extra staff appears
-If contexts are not created explicitly with @code{\new} they will be
-silently created as soon as a command is encountered which cannot
-be applied to an existing context. In simple scores the automatic
-creation of contexts is useful, and most of the examples in the
-LilyPond manuals take advantage of this simplification. But
-occasionally the silent creation of contexts can give rise to
-unexpected new staves or scores. For example, it might be expected
-that the following code would cause all note heads within the
-following staff to be colored red, but in fact it results in two
-staves with the note heads remaining the default black in the lower
-staff.
+If contexts are not created explicitly with @code{\new} or
+...@code{\context}, they will be silently created as soon as a
+command is encountered which cannot be applied to an existing
+context. In simple scores the automatic creation of contexts is
+useful, and most of the examples in the LilyPond manuals take
+advantage of this simplification. But occasionally the silent
+creation of contexts can give rise to unexpected new staves or
+scores. For example, it might be expected that the following code
+would cause all note heads within the following staff to be
+colored red, but in fact it results in two staves with the note
+heads remaining the default black in the lower staff.
@lilypond[quote,verbatim,relative=2]
\override Staff.NoteHead #'color = #red
@@ -680,23 +680,25 @@ correct code to color all note heads red is
@end lilypond
As a second example, if a @code{\relative} command is placed inside
-a @code{\repeat} command two staves result, the second offset from
+a @code{\repeat} command, two staves result, the second offset from
the first, because the @code{\repeat} command generates two
@code{\relative} blocks, which each implicitly create @code{Staff}
and @code{Voice} blocks.
@lilypond[quote,verbatim]
\repeat unfold 2 {
- \relative c' { c d e f }
+ \relative c' { c4 d e f }
}
@end lilypond
-The correct way is to reverse the @code{\repeat} and
-...@code{\relative} commands, like this:
+Explicitly instantiating the @code{Voice} context fixes the
+problem:
@lilypond[quote,verbatim]
-\relative c' {
- \repeat unfold 2 { c d e f }
+\new Voice {
+ \repeat unfold 2 {
+\relative c' { c4 d e f }
+ }
}
@end lilypond
--
1.6.3.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
LGTM Trevor - Original Message - From: "Mark Polesky" To: "Carl Sorensen" ; "Graham Percival" Cc: "lilypond-devel" Sent: Friday, April 30, 2010 5:46 PM Subject: Re: PATCH: Doc: Clarify \relative inside \repeat issue. Carl Sorensen wrote: I disagree with the idea that the simplest solution is to move the \relative outside the \repeat. I've attached a new patch following your suggestions. Okay to push? - 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
syntax change discussions
A week ago, I asked "Does anybody have any other syntax changes they want to propose?". This was horribly unclear, and I apologize for completely giving the wrong impression. I /meant/ to ask if there were any long-planned (small) syntax changes that we all agreed on, but which I had previously vetoed as not going into 2.13. I didn't mean to invite lots of proposals of vague possibilities -- even though I this was obviously what I /wrote/. I'm completely in the wrong here. To restate: - I have a vague recollection that there was one patch, similar to the \cresc one (i.e. well-liked and small), which I'd told the author(s) to wait until 3.0. If that describes your / your work, please speak up. - We're not starting a free discussion about syntax yet. - Even if people *do* start/continue a free discussion about syntax, we won't be acting on any of it yet. As Han-Wen recently noted on the bug list, syntax changes look simple, get people very enthusiastic, but use a lot of developer time and are fraught with peril (it's easy to get something wrong, but if it's wrong, we're stuck with it (unless we make users very unhappy)). I know that there's a lot of interest in fixing certain problems in our input syntax; I have a bunch of things as well. However, I also know that I don't know everything, and because of stuff I don't know, some of my suggestions are going to be complete bolloks and would cause huge problems if we implemented them. The problem is that I don't know what I don't know, so there's no way of predicting (by myself) which of my proposals are worth doing. We have a project set aside for this: GLISS. It will happen when lilypond is relatively stable (i.e. after 2.14). It will happen when we can afford to waste (or at least, "spend") a lot of developer time discussing stuff. It will be a structured debate, wherein people with less time to discuss syntax will still have their say. It will be slow; people will have lots of opportunity to think about matters, maybe do some tests, raise an objection after two weeks, think some more, raise another objection after two more weeks, etc. The exact format of the discussion will be decided later. If you're enthusiastic about starting GLISS, the best thing you can do is to help resolve the Critical issues. The easiest, most bite-sized, problems at the moment are the info that's only in the regtests; most items can be solved in 5 minutes or less. Again, I apologize for mispeaking / miswriting so badly. The only possible interpretation of my text at the end of: http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00308.html is that I'm inviting free discussion, even though that wasn't my intention. Sorry, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: order of engravers
On Thu, Apr 29, 2010 at 10:26:21PM -0400, Kieren MacMillan wrote: > Hi Graham, > > > That's just it -- there isn't anybody to guide you gently into > > that good night. The only clue I know about the IR is that it's > > partly generated by scheme functions in scm/documentation*. > > I'll see what I can do. > To be honest, I'd really like to tackle a few other issues which > are far more pressing (in my scores). I'd also like you to tackle a few other issues which are far more pressing. In fact, at the moment I can't think of any issue which is *less* pressing than the IR order of engravers issue. By all means, prioritize your time. James: I still want the NR updated with the manual list; *that* issue is not non-pressing. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Doc: Clarify \relative inside \repeat issue.
Looks good to me. As a matter of fact, I really like it. Carl On 4/30/10 10:46 AM, "Mark Polesky" wrote: > Carl Sorensen wrote: >> I disagree with the idea that the simplest solution is to >> move the \relative outside the \repeat. > > I've attached a new patch following your suggestions. > Okay to push? > > - Mark > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
outdated @knownissues in NR?
There's a @knownissues at the end of NR 1.4.2 "Short repeats * Tremolo repeats" that says: "Cross-staff tremolos do not work well." This comes immediately after a selected snippet that shows just how well those cross-staff tremolos work (quite nicely, in fact). Can we remove the @knownissues? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Flex patterns with " in them
Incidentally, I already happened to have one of those in my patch series
where the consequences were all too bad.
Here goes: flex/bison files need, for lack of better alternatives, to be
edited in c++-mode in Emacs.
Unmatched double quotes throw all syntactic entities off terribly. So
I'd tend to just double those quotes where they occur in a pattern like
[^\\""]{ ...
since duplication in a character set is harmless. An uglier alternative
would be
[^\\"]// "
{ ...
Is the former ok with people? It does no harm, and is not likely to get
confused with anything. And it makes handling those files in c++-mode
smoother in Emacs and likely in other editors as well.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
