Multiple repeats
How to write multiple repeats? \repeat volta 4 {..} does not indicate that
there is more that 1 repeat.
I'm happy to just write "4X" at the end but am I missing something? What's the
purpose of the
number in the \repeat volta command?
Kees
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Ian Hulin hulin.org.uk> writes: > > What I'd like to have output is something like: > > > > ___ > > | | | _| > > -+--|-|---|---| > > -+--|-|---|---| > > -+--|-|---|---| > > --2--+--2-2---2.--2 > > -+- > > -+- > > Ric, this is a problem. With your proposal the up stem for a half note > will look uncomfortably like an unbeamed eighth note. Ahh, I see how you're interpreting my poor ascii rendition. The thickness of the half note flag should be the same thickness as the stem itself, not a beam. The half note flag is more like a bent stem, instead of a separate flag. Does that shed any light on how to address this? [snipping quoted material that gmane is complaining about...] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Ricdude wrote: Ian Hulin hulin.org.uk> writes: Hi Ric, Ricdude wrote: Quick intro: Mediocre guitarist/composer, Lilypond newbie, Professional programmer. I've got lilypond 2.10.33 (cygwin version), and, as some others have noted, there is no way to resolve whether a straight stem on a tablature staff refers to a half note, or a quarter note. Although there's stuff missing in the default lilypond Tab, this is already fixed. Lily uses beamed, flagged staffs for the tab stems already, so there's no ambiguity between quarter notes (crotchets) and eighth notes (quavers). The flags on the tablature staves work great for eighths, sixteenths, etc. Beaming, ties, slurs, etc. all work well. It's just trying to tell the difference between a half note and a quarter note, since they use the same stems, with no flags. Using upward stems as examples... | e1 | e2 e4 e8. e16 | currently renders as: _ | | | _| -+--|---|--|---| -+--|---|--|---| -+--|---|--|---| --2--+--2---2--2.--2 -+-- -+-- so it's hard to tell just from the output whether the second and third notes are quarters or halves. What I'd like to have output is something like: ___ | | | _| -+--|-|---|---| -+--|-|---|---| -+--|-|---|---| --2--+--2-2---2.--2 -+- -+- Is there a way to customize flags for a staff? It looks like it's handled in the C++ code, and might be difficult to override. Plus, I'm fairly new to Scheme... Ric, this is a problem. With your proposal the up stem for a half note will look uncomfortably like an unbeamed eighth note. Maybe use _ O | | _| -+--|-|---|---| -+--|-|---|---| -+--|-|---|---| --2--+--2-2---2.--2 -+- -+- or _ ||| | _| -+--|||---|---| -+--|||---|---| -+--|||---|---| --2--+--2-2---2.--2 -+- -+- or _ L | | _| -+--|-|---|---| -+--|-|---|---| -+--|-|---|---| --2--+--2-2---2.--2 -+- -+- or | | | _| -+--|-|---|---| -+--|-|---|---| -+--L-|---|---| --2--+--2-2---2.--2 -+- -+- I've seen this ambiguity handled in some tablatures by adding a short straight line perpendicular to the end of the stem for half notes. The result looks kind of like the letter L (sans-serif, and inverted for upstems), about as wide as an eighth note flag. Quarter notes retain their "normal" straight staves in this notation system. So a down-beam half-note tab for A major looks a bit like --- -2- -2- -2- --- --- __ | | | and a three-beat note would just have dots after the string number. indicators. This works around the case nicely where standard notation uses black and white note heads to differentiate between quarter and half-notes. How does this notation system handle whole notes, where standard notation has unstemmed symbols? Or even breves (double notes?) As for your other notation questions: Whole notes are rendered with simply the number with no flags attached. Breves are rare enough in modern guitar that I've never seen them rendered in tab, although in this case, I would tie two whole notes together, myself. Cheers, Ian No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1978 - Release Date: 03/01/09 07:04:00 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
On 3/1/09 12:49 PM, "Ricdude" wrote:
> Quick intro: Mediocre guitarist/composer, Lilypond newbie,
> Professional programmer.
>
> I've got lilypond 2.10.33 (cygwin version), and, as some others have
> noted, there is no way to resolve whether a straight stem on a
> tablature staff refers to a half note, or a quarter note.
If you're going to do development, you'll need to move to the current
version (2.13 for the devel version now). I'm not sure if it compiles in
cygwin or not (I suspect it may not -- I quit trying to compile in cygwin a
couple of years ago).
>
> I've seen this ambiguity handled in some tablatures by adding a short
> straight line perpendicular to the end of the stem for half notes.
> The result looks kind of like the letter L (sans-serif, and inverted
> for upstems), about as wide as an eighth note flag. Quarter notes
> retain their "normal" straight staves in this notation system.
>
> I'd like to see this notation implemented (at least as an option) in
> lilypond. It looks like the code to tweak is in the lily/stem.cc file,
> Stem::flag method, starting around line 603 in the 2.10.33 source.
> Instead of:
>
> if (log < 3
> || unsmob_grob (me->get_object ("beam")))
> return Stencil ();
>
> perhaps something like:
>
> if ( STAFF_IS_NOT_TABLATURE_TBD ) {
> // non-tab staves, only eighths and shorter have flags.
> if (log < 3
> || unsmob_grob (me->get_object ("beam")))
> return Stencil ();
> } else {
> // staff is tablature, allow half-notes to have a flag
> if ( (log < 3 && log != 1)
> || unsmob_grob (me->get_object ("beam")))
> return Stencil ();
> }
>
> where, STAFF_IS_NOT_TABLATURE is, of course, the appropriate check for
> a non-tablature staff type.
>
> Beyond that, it looks like the flag handling relies on a
> "flags.STYLE+DIR+OFFSET+LOG" definition of some sort, so as long as
> the definition for log==1 existed, the remaining logic would handle
> everything appropriately.
>
> Does this logic make sense?
I'm probably not the right person to answer this question, but nobody else
has, so I'll chime in here. I think this logic works.
> How would the staff type be checked?
You need to get the context name and see if it's TabStaff. I think you use
the c procedure ly_context_name_
> And
> where would I find the flags.___ definitions to add the half-note
> definition?
The flags are glyphs in the feta font; you can see them by looking at
Appendix B6 of the Notation Reference for version 2.12.
> Can someone more familiar with the code let me know if
> I'm on the right track here?
> And where else to look to implement (or assist in implementing) this?
>
> Long term, I'd like to see all of the "special" guitar notation
> techniques (bends, dives, slash heads on tab staffs, etc.) implemented
> in some form or another. Some of these unique notation techniques can
> be seen here:
> http://tabs.guitarworld.com/tabs/gwtabpage/4385/1920/back-in-black
>
Some of these features are currently implemented. See the 2.12
documentation for more information on the current state of tab notation.
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Ian Hulin hulin.org.uk> writes: > > Hi Ric, > Ricdude wrote: > > Quick intro: Mediocre guitarist/composer, Lilypond newbie, > > Professional programmer. > > > > I've got lilypond 2.10.33 (cygwin version), and, as some others have > > noted, there is no way to resolve whether a straight stem on a > > tablature staff refers to a half note, or a quarter note. > > > Although there's stuff missing in the default lilypond Tab, this is > already fixed. Lily uses beamed, flagged staffs for the tab stems > already, so there's no ambiguity between quarter notes (crotchets) and > eighth notes (quavers). The flags on the tablature staves work great for eighths, sixteenths, etc. Beaming, ties, slurs, etc. all work well. It's just trying to tell the difference between a half note and a quarter note, since they use the same stems, with no flags. Using upward stems as examples... | e1 | e2 e4 e8. e16 | currently renders as: _ | | | _| -+--|---|--|---| -+--|---|--|---| -+--|---|--|---| --2--+--2---2--2.--2 -+-- -+-- so it's hard to tell just from the output whether the second and third notes are quarters or halves. What I'd like to have output is something like: ___ | | | _| -+--|-|---|---| -+--|-|---|---| -+--|-|---|---| --2--+--2-2---2.--2 -+- -+- Is there a way to customize flags for a staff? It looks like it's handled in the C++ code, and might be difficult to override. Plus, I'm fairly new to Scheme... > > I've seen this ambiguity handled in some tablatures by adding a short > > straight line perpendicular to the end of the stem for half notes. > > The result looks kind of like the letter L (sans-serif, and inverted > > for upstems), about as wide as an eighth note flag. Quarter notes > > retain their "normal" straight staves in this notation system. > > > So a down-beam half-note tab for A major looks a bit like > --- > -2- > -2- > -2- > --- > --- > __ > | > | > | > > and a three-beat note would just have dots after the string number. > indicators. > > This works around the case nicely where standard notation uses black and > white note heads to differentiate between quarter and half-notes. How > does this notation system handle whole notes, where standard notation > has unstemmed symbols? Or even breves (double notes?) As for your other notation questions: Whole notes are rendered with simply the number with no flags attached. Breves are rare enough in modern guitar that I've never seen them rendered in tab, although in this case, I would tie two whole notes together, myself. > Cheers, > > Ian > > > > > No virus found in this outgoing message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.5/1978 > - Release Date: 03/01/09 07:04:00 > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: Named book file suffixes -- regtest?
On 3/1/09 2:44 PM, "Marek Klein" wrote: > > > With your suggestion and one more line of code it works now with > ly:parser-define! > > (define counter-alist '()) Will it work with the above line missing? The whole point of using ly:parser-define! is to avoid having a global variable. When you use (define counter-alist '()) you are defining counter-alist as a global variable. I think you should be able to just remove that line. > > (define (print-book-with parser book process-procedure) > (let* > ((paper (ly:parser-lookup parser '$defaultpaper)) > (layout (ly:parser-lookup parser '$defaultlayout)) > (output-suffix (ly:parser-lookup parser 'output-suffix)) > (counter-alist (ly:parser-lookup parser 'counter-alist)) ^^^ Here you're making a local variable counter-alist by getting the parser value of counter-alist; I don't like to use the same name for both, although Scheme allows it. I would use a variable name like local-counter, so that there would be no confusion between the two. > (output-count (assoc-ref counter-alist output-suffix)) > (base (ly:parser-output-name parser)) ) > > (if (string? output-suffix) > (set! base (format "~a-~a" base (string-regexp-substitute > "[^a-zA-Z0-9-]" "_" output-suffix > > ;; must be careful: output-count is under user control. > (if (not (integer? output-count)) > (set! output-count 0)) > > (if (> output-count 0) > (set! base (format #f "~a-~a" base output-count))) > (ly:parser-define! parser 'counter-alist (assoc-set! counter-alist > output-suffix (1+ output-count))) ^^^Here you do an assoc-set! on the local counter-alist and define the parser value of counter-alist to be the assoc-set! on the local value. So I don't think you ever use the global value of counter-alist. > (process-procedure book paper layout base) > )) > > HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Hi Ric, Ricdude wrote: Quick intro: Mediocre guitarist/composer, Lilypond newbie, Professional programmer. I've got lilypond 2.10.33 (cygwin version), and, as some others have noted, there is no way to resolve whether a straight stem on a tablature staff refers to a half note, or a quarter note. Although there's stuff missing in the default lilypond Tab, this is already fixed. Lily uses beamed, flagged staffs for the tab stems already, so there's no ambiguity between quarter notes (crotchets) and eighth notes (quavers). I've seen this ambiguity handled in some tablatures by adding a short straight line perpendicular to the end of the stem for half notes. The result looks kind of like the letter L (sans-serif, and inverted for upstems), about as wide as an eighth note flag. Quarter notes retain their "normal" straight staves in this notation system. So a down-beam half-note tab for A major looks a bit like --- -2- -2- -2- --- --- __ | | | and a three-beat note would just have dots after the string number. indicators. This works around the case nicely where standard notation uses black and white note heads to differentiate between quarter and half-notes. How does this notation system handle whole notes, where standard notation has unstemmed symbols? Or even breves (double notes?) Cheers, Ian No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1978 - Release Date: 03/01/09 07:04:00 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Named book file suffixes -- regtest?
2009/3/1 Carl D. Sorensen > > I think this error message says that it's expecting a symbol, and instead > it > gets an empty list, which is the value of counter-alist right now. > > So I think you should try > > (ly:parser-define! parser 'counter-alist (assoc-set! counter-alist > output-suffix (1+ output-count))) > > This puts the symbol as the argument, rather than the value of the symbol, > I > think. > > Carl > > With your suggestion and one more line of code it works now with ly:parser-define! (define counter-alist '()) (define (print-book-with parser book process-procedure) (let* ((paper (ly:parser-lookup parser '$defaultpaper)) (layout (ly:parser-lookup parser '$defaultlayout)) (output-suffix (ly:parser-lookup parser 'output-suffix)) (counter-alist (ly:parser-lookup parser 'counter-alist)) (output-count (assoc-ref counter-alist output-suffix)) (base (ly:parser-output-name parser)) ) (if (string? output-suffix) (set! base (format "~a-~a" base (string-regexp-substitute "[^a-zA-Z0-9-]" "_" output-suffix ;; must be careful: output-count is under user control. (if (not (integer? output-count)) (set! output-count 0)) (if (> output-count 0) (set! base (format #f "~a-~a" base output-count))) (ly:parser-define! parser 'counter-alist (assoc-set! counter-alist output-suffix (1+ output-count))) (process-procedure book paper layout base) )) -- Marek Klein http://gregoriana.sk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Quick intro: Mediocre guitarist/composer, Lilypond newbie,
Professional programmer.
I've got lilypond 2.10.33 (cygwin version), and, as some others have
noted, there is no way to resolve whether a straight stem on a
tablature staff refers to a half note, or a quarter note.
I've seen this ambiguity handled in some tablatures by adding a short
straight line perpendicular to the end of the stem for half notes.
The result looks kind of like the letter L (sans-serif, and inverted
for upstems), about as wide as an eighth note flag. Quarter notes
retain their "normal" straight staves in this notation system.
I'd like to see this notation implemented (at least as an option) in
lilypond. It looks like the code to tweak is in the lily/stem.cc file,
Stem::flag method, starting around line 603 in the 2.10.33 source.
Instead of:
if (log < 3
|| unsmob_grob (me->get_object ("beam")))
return Stencil ();
perhaps something like:
if ( STAFF_IS_NOT_TABLATURE_TBD ) {
// non-tab staves, only eighths and shorter have flags.
if (log < 3
|| unsmob_grob (me->get_object ("beam")))
return Stencil ();
} else {
// staff is tablature, allow half-notes to have a flag
if ( (log < 3 && log != 1)
|| unsmob_grob (me->get_object ("beam")))
return Stencil ();
}
where, STAFF_IS_NOT_TABLATURE is, of course, the appropriate check for
a non-tablature staff type.
Beyond that, it looks like the flag handling relies on a
"flags.STYLE+DIR+OFFSET+LOG" definition of some sort, so as long as
the definition for log==1 existed, the remaining logic would handle
everything appropriately.
Does this logic make sense? How would the staff type be checked? And
where would I find the flags.___ definitions to add the half-note
definition? Can someone more familiar with the code let me know if
I'm on the right track here?
And where else to look to implement (or assist in implementing) this?
Long term, I'd like to see all of the "special" guitar notation
techniques (bends, dives, slash heads on tab staffs, etc.) implemented
in some form or another. Some of these unique notation techniques can
be seen here:
http://tabs.guitarworld.com/tabs/gwtabpage/4385/1920/back-in-black
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
(de)cresendi syntax
Hello, I am in charge of the question of (de)crescendo syntax issue in 2.12.2. I have posted this on -user list but received little replies (only support) so it's time now to post on -devel. Here is what lilypond 2.12.2 currently does (in ly/spanners-init.ly): - \< and \cr are equivalent: they start a crescendo event on the previous note: #(make-span-event 'CrescendoEvent START) - \> and \decr are equivalent: they start a decrescendo event on the previous note: #(make-span-event 'DecrescendoEvent START) - \!, \endcr and \enddecr are equivalent: they stop of (de)cresendo event on the previous note: #(make-span-event 'CrescendoEvent STOP), #(make-span-event 'DecrescendoEvent STOP) (is it really equivalent?) - the following commands set the (de)cresendo to be text with dashed line or hairpin forever (until changed to something else): . crescTextCresc -> text "cresc." . dimTextDecresc -> text "decresc." . dimTextDecr -> text "decr." . dimTextDim -> text "dim." . crescHairpin -> hairpin . dimHairpin -> hairpin - the following commands start a text (de)crescendo on the next note (affects only the next (de)crescendo): . cresc -> text "cresc." . dim -> text "dim." - the following commands stop a (de)crescendo on the next note: . enddim . endcresc Current syntax is not satisfactory because: - syntax is different between \<, \>, \! and \cresc, \dim, \enddim, \endcresc (undocumented): . \<, \>, \! apply to the previous note, . \cresc, \dim, \enddim, \endcresc apply to the next note . for example to have a crescendo after a forte we need write things reversed: \cresc c\ff ... c\! - there is no symmetry between \crescText, \dimText commands and \ commands - some people just want cresc. to be printed without dashed line (spanner) - \endcresc does something different from \endcr which is confusing Here are my dreams: - \<, \>, \! are used to start/stop (de)crescendo spanner (hairpin or text), - crescTextXXX, dimTextXXX, crescHairpin, dimHairpin decide if \<, \>, \! produce text or hairpin (applies for ever until changed to something else), I would prefer simpler syntax: \crescCresc, \crescHairpin, \dimDim, \dimDecr, \dimDecresc, i.e. remove Text but these commands have to be typed only once so there is no real overhead in longer command names - \<"cresc.", \<"cresc. poco a poco", \>"dim."... produce a text spanner with corresponding text, the spanner is ended with \!, the text applies only once, i.e. next (de)crescendo produces hairpin if this is the current setting - \cresc, \dim, \decr, \decresc produce a text without spanner, applies only once to the previous note, no need to finish with \! or \endcresc, this could be implemented with a \markup command - remove unnecessary \cr, \endcr, \decr, \enddecr - remove unnecessary \enddim, \endcresc I know that it is not possible to implement this without rewrite of the parser... \<"cresc." syntax could be replaced by \dspan #"cresc." with a little overhead but compatible with current syntax (dspan for dynamic spanner for example). However, as far as I know, this syntax would still apply to the next note. Could you please comment on this. F. Bron --- Frédéric Bron (frederic.b...@m4x.org) Villa des Quatre Chemins, Centre Hospitalier, BP 208 38506 VOIRON CEDEX tél. : (33) 4 76 67 17 27 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Completion_heads_engraver broken?
On Sat, 2009-02-28 at 10:23 +0100, Michael Käppler wrote: > Joe Neeman wrote: > > On Thu, 2009-02-26 at 13:24 +0100, Michael Käppler wrote: > > > >> Both fixed. Other comments? > >> > > > > Just one: can you set the environment variables GIT_AUTHOR_NAME and > > GIT_AUTHOR_EMAIL so that an actual name and email show up in the patch? > > > Done. Applied, thanks for the patch. For future reference, please format the commit message with a short sentence followed by a blank line and the rest of the message. That way, the shortlog is readable. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.0 uploaded
Han-Wen Nienhuys, Sunday, March 01, 2009 3:07 PM it was built with gub3. Essentially untested. Comments welcome. Tried on Vista Home Premium SP1: A minimal run with a file which happened to be to hand produced the message: (lilypond.exe:4848): GLib-WARNING **: Passing a non-NULL package to g_win32_get_package_installation_directory() is deprecated and it is ignored. Otherwise seemed to work fine. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \cresc applies to the next note!
2009/3/1 Frédéric Bron : > Well thank you. I have downloaded your score and found \ind and \nind > but both start on the next note. However, I like the syntax \ind > #"cresc poco a poco". It is a bit more painful than what I propose > \<"cresc poco a poco" but it can be done today without changing the > parser. No, that is not what I have in mind. Actually, I was more referring to Graham's compound dynamics that (through the use of 'tweaks) are attached _after_ the note, such as c'\flegato I have written something like that for text spanners too, but (see below). > I have also seen that you do quite often such thing: > > c\ff \dim c c c\! I do not. I only use \< and \> 2009/3/1 Graham Percival : > Yes. I think that somebody (a Frog?) would need to make \cresc a > built-in command rather than simply being defined in > ly/spanner-init.ly (or maybe dynamics-init.ly ?) No, actually I have been thinking about this and here's what I'd propose. The mail problem with using the 'tweaks method is that you can't pass the text as an argument; you have to first define a meta-function, then define all your strings as follows: flegato = #(make-extra-dynamic "f" "legato") and so on. What I'd really like to see implemented is an equivalent of define-music-function, but that would instead be called define-music-tweak, that could take any argument (strings, numbers, whatever) /except/ music expressions, and that would be entered immediately /after/ the affected note (like an articulation), whereas music-functions have to be entered /before/ the note they affect (that's actually a ly:music? argument). I don't know if I'm making myself clear. And FWIW, I doubt any Frog could implement such a new infrastructure. I certainely can not. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.13.0 uploaded
it was built with gub3. Essentially untested. Comments welcome. -- 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: \cresc applies to the next note!
On Sat, Feb 28, 2009 at 11:56:26PM -0800, Patrick McCarty wrote: > On Sat, Feb 28, 2009 at 10:37 PM, Frédéric Bron wrote: > > Because \dim starts on the next note, you have to put it before \ff > > which is the contrary of what happens really! If you put \dim after > > \ff, the "dim" starts on the next note and it is possible that the > > "ff" and the "dim" are not put on the same line. > > This illustrates perfectly why I would like that \cresc and \dim start > > on the next note. > > You mean that you would like \cresc and \dim to start on the previous > note, right? > g4 \< g g g \! > g4 \cresc g g g \endcresc > > These two examples should have the same behavior, IMO. That is, the > commands apply to the *previous* note. Agreed. I'd love it if this could happen. > I think we need to rework \cresc, \dim, etc. so that they use a > modified version of make-span-event (the procedure \cr, \decr, etc. > use). Right now, with these commands, a SequentialMusic expression is > created, so the behavior will only apply to notes *following* the > command. Yes. I think that somebody (a Frog?) would need to make \cresc a built-in command rather than simply being defined in ly/spanner-init.ly (or maybe dynamics-init.ly ?) It would require a fair amount of understanding about lilypond, but it's definitely a worthwhile project. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
