Re: (de)cresendi syntax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Montag, 20. April 2009 05:31:20 Carl D. Sorensen wrote: On 4/17/09 11:02 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 17. April 2009 schrieb Frédéric Bron: Hmm, no you are right. It seems that when using a music-function, the scheme expression is: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0 (make-music 'CrescendoEvent 'crescendoText blah.. 'crescendoSpanner 'text 'span-direction -1))) i.e. the CrescendoEvent is outside the EventChord, while with a simple definition like crxxx=#(make-music 'CrescendoEvent ...), it is inside the EventChord: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0)) (make-music 'CrescendoEvent 'crescendoText cresc. 'crescendoSpanner 'text 'span-direction -1))) Does anyone have an idea how to create a function so that the return value is inserted into the note event? Reinhold, I didn't see you get an answer. There are examples in the documentation for tweaks, which are how you get something inserted in a 'NoteEvent. The problem with all these is that either (1) The command needs to be written before the note, since it requires the note as an argument: http://kainhofer.com/~lilypond/ajax/Documentation/user/lilypond/Adding- articulation-to-notes-_0028example_0029.html or (2) it's not possible to pass a parameter to the \mycresc text function: http://kainhofer.com/~lilypond/ajax/Documentation/user/lilypond/Using-Scheme- code-instead-of-_005ctweak.html#Using-Scheme-code-instead-of-_005ctweak I haven't found a way how to define a function \mycresc text, so that c4\mycresc cresc. d4 e f\! creates a crescendo event assigned to the c4 rather than the d4... All I'm able is \mycresc c4 cresc d4 e f\! (using a normal music function) of mycresc=#(create-text-cresc-spanner cresc) c4\mycresc d4 e f\! Unfortunately, the first is inconsistent with the use of \ and the future predefined commands \cresc, \dim,\decresc, etc., while the second is not as flexible as a function taking the argument directly in the score. I'm not sure if you wanted a way to get the CrescendoEvent inside the Chord, as opposed to outside the chord. I don't think you can put the CrescendoEvent inside the NoteEvent. No, I just need it inside the chord, so it is attached to this chord and not inserted into the NEXT chord... 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ7DBETqjEwhXvPN0RAq5tAJ93poVUq4iH8tAPK2gSUDwll2CHkgCgs9zO HGuxpWl4EYDbaTDQE1hYsAs= =teO3 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On 4/17/09 11:02 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 17. April 2009 schrieb Frédéric Bron: Hmm, no you are right. It seems that when using a music-function, the scheme expression is: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0 (make-music 'CrescendoEvent 'crescendoText blah.. 'crescendoSpanner 'text 'span-direction -1))) i.e. the CrescendoEvent is outside the EventChord, while with a simple definition like crxxx=#(make-music 'CrescendoEvent ...), it is inside the EventChord: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0)) (make-music 'CrescendoEvent 'crescendoText cresc. 'crescendoSpanner 'text 'span-direction -1))) Does anyone have an idea how to create a function so that the return value is inserted into the note event? Reinhold, I didn't see you get an answer. There are examples in the documentation for tweaks, which are how you get something inserted in a 'NoteEvent. I'm not sure if you wanted a way to get the CrescendoEvent inside the Chord, as opposed to outside the chord. I don't think you can put the CrescendoEvent inside the NoteEvent. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
Attached is a sample file to show how the definition of spanners could work with my patch. I've also implemented two functions to give the text of the spanner directly in the postfix call. When I look at your dynamic_spanners_postfix.pdf file, it seems to me that on the second line (with the functions that take the text as an argument), the cresc starts on the following note, not on the previous note. Am I wrong? Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
So, I took a look at the issue today and created a patch, which will now allow all dynamic spanner starters to be implemented as postfix-operators. The short (15 quite trivial lines!) patch is up for review at: http://codereview.appspot.com/39047 Basically, my question for now is whether this the right approach. Call it a proof-of-concept patch. If so, we'll need to think about possible upgrade paths for the syntax changes that are introduced by making all dynamic spanners postfix operators... The patch also does not include the actual definitions of things like \dim, \cresc, etc. Wonderful!!! Thanks a lot for this great job! Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Sonntag, 22. Februar 2009 09:25:57 Frédéric Bron wrote: I am in charge of the question of (de)crescendo syntax issue in 2.12.2. Okay, sorry if I'm working on the same issue as you now, but I simply got too frustrated with hundreds of pages of old scores suddenly changing cresc/hairpin behavior (they were created with 2.10 and now I've started revising them with 2.12...) and the huge work I have now with cross-checking every cresc/dim/hairpin. So, I took a look at the issue today and created a patch, which will now allow all dynamic spanner starters to be implemented as postfix-operators. The short (15 quite trivial lines!) patch is up for review at: http://codereview.appspot.com/39047 Basically, my question for now is whether this the right approach. Call it a proof-of-concept patch. If so, we'll need to think about possible upgrade paths for the syntax changes that are introduced by making all dynamic spanners postfix operators... The patch also does not include the actual definitions of things like \dim, \cresc, etc. 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 With my patch, everything applies to the previous note, all spanners are ended with \!, no \endXXX are needed any more. - some people just want cresc. to be printed without dashed line (spanner) That's a global setting of the DynamicTextSpanner, which (IMO) should be changed to no dashed line by default. - \, \, \! 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), Yes, this behavior stays the same with my patch. - \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 This would require a parser change to be able to use \. However, with my patch it's easy to write a function, e.g. mycresc, which can be used as: a4\mycresc cresc. molto a4 a4\fff An example is given in the attached file. - \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 No, using a markup would break e.g. MIDI, which needs information about the end. With my patch, those can simply create dynamic text spanners with or without dashed line, but must be finished with \! - remove unnecessary \cr, \endcr, \decr, \enddecr - remove unnecessary \enddim, \endcresc Yes, unnecessary with my patch I know that it is not possible to implement this only with scheme and lily code but I am sure it is possible in C++. Yes, some simple lines of C++ were required. Attached is a sample file to show how the definition of spanners could work with my patch. I've also implemented two functions to give the text of the spanner directly in the postfix call. Any comments / objections / suggestions? 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 \version 2.13.1 #(ly:set-option 'point-and-click #f) % Some sample text dynamic spanners, to be used as postfix operators crxxx = #(make-music 'CrescendoEvent 'span-direction START 'crescendoSpanner 'text 'crescendoText cresc.) crpoco = #(make-music 'CrescendoEvent 'span-direction START 'crescendoSpanner 'text 'crescendoText cresc. poco a poco) dimxxx = #(make-music 'DecrescendoEvent 'span-direction START 'decrescendoSpanner 'text 'decrescendoText dim.) \relative c' { c4\crxxx d4 e4 f4 | g4 a4\! b4\crpoco c4 | c4 d4 e4 f4 | g4 a4\! b4\ c4 | g4\dimxxx a4\ b4\crxxx c4\! } % Two functions for (de)crescendo spanners where you can explicitly give the % spanner text. mycresc = #(define-music-function (parser location mymarkup) (string?) (make-music 'CrescendoEvent 'span-direction START 'crescendoSpanner 'text 'crescendoText mymarkup) ) mydecresc = #(define-music-function (parser location mymarkup) (string?) (make-music 'DecrescendoEvent 'span-direction START 'decrescendoSpanner 'text 'decrescendoText mymarkup) ) \relative c' { c4\mycresc blah.. c4 c4 c4 | c4\mydecresc ...halb c4 c4 c4 | c4 c4\! c4 c4 } dynamic_spanners_postfix.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On 4/10/09 5:54 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: On Sonntag, 22. Februar 2009 09:25:57 Frédéric Bron wrote: I am in charge of the question of (de)crescendo syntax issue in 2.12.2. Okay, sorry if I'm working on the same issue as you now, but I simply got too frustrated with hundreds of pages of old scores suddenly changing cresc/hairpin behavior (they were created with 2.10 and now I've started revising them with 2.12...) and the huge work I have now with cross-checking every cresc/dim/hairpin. So, I took a look at the issue today and created a patch, which will now allow all dynamic spanner starters to be implemented as postfix-operators. Attached is a sample file to show how the definition of spanners could work with my patch. I've also implemented two functions to give the text of the spanner directly in the postfix call. Any comments / objections / suggestions? Looks good to me. Got at the essential issues in a very straightforward way. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Sat, Apr 11, 2009 at 01:54:22AM +0200, Reinhold Kainhofer wrote: I know that it is not possible to implement this only with scheme and lily code but I am sure it is possible in C++. Yes, some simple lines of C++ were required. Attached is a sample file to show how the definition of spanners could work with my patch. I've also implemented two functions to give the text of the spanner directly in the postfix call. Beautiful... simply beautiful. As you mentioned, we need to be very careful with the upgrade path here. And we should spend at least two weeks discussing the new syntax (\textCresc my personal text vs. \crText vs. hard-coded \crPocoAPoco vs. whatever). I can't speak to the actual C++ patch, but I'm *very* happy with the flexibility those scheme functions give us. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Tue, Mar 17, 2009 at 10:41:36AM +0100, Mats Bengtsson wrote: Graham Percival wrote: I'm not sure why we have both \cr and \. If the two really are equivalent, one ought to be deprecated before it is ultimately removed. I have a vague notion that \cr *was* deprecated. No! If you look in ly/spanners-init.ly, you will see that \cr is used internally in \cresc (though that's easy to fix, of course). Sorry. You know, I now have a vague notion that we've had this conversation before. I really need to start keeping better notes while I advance into my old age. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Tue, Mar 17, 2009 at 10:20:29AM +0100, Valentin Villenave wrote: Le 16 mars 2009 16:31, Graham Percival gra...@percival-music.ca a écrit : I don't think anybody else has replied, so I'll take a stab at it. I've been working at a draft reply for a few days, but never found what I was looking for. And clearly what you were looking for was **me**. :) Again, I'd rather use text for text dynamics. What about \cresc #cresc. poco a poco ? i.e. if \cresc is used by itself, it prints cresc., but if you provide the optional argument, that's used instead of the default text? Yes, but I'd really like to use this \cresc command of yours *after* the note (not before, as it is now). Of course. IMO, that's the most important part of any dynamic work. Which is why, rather than a C++ parser change, what I'd really like to have is a (define-music-tweak) function, that could act like define-music-function but that would *not* take the music as an argument, that would just take the string and cons' it as a 'tweak property. I am absolutely not arguing against this. The only question is who will produce such a wonder. :) If it's doable in pure scheme, then I guess that Frederic (sorry, no accents) can do it without recompiling lilypond? If so, that would be awesome. Anybody want to hazard a guess about this possibility? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
Graham Percival wrote: I'm not sure why we have both \cr and \. If the two really are equivalent, one ought to be deprecated before it is ultimately removed. I have a vague notion that \cr *was* deprecated. No! If you look in ly/spanners-init.ly, you will see that \cr is used internally in \cresc (though that's easy to fix, of course). /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
Le 16 mars 2009 16:31, Graham Percival gra...@percival-music.ca a écrit : I don't think anybody else has replied, so I'll take a stab at it. I've been working at a draft reply for a few days, but never found what I was looking for. What about reserving \ \ \! **only** for hairpins, and \cr \endCr \dim \endDim **only** for text? ok, we'd need extra commands for decresc and decr, but this way we could avoid the \crescTextXXX stuff entirely. Yes. Yes. Yes. We certainly need that. Again, I'd rather use text for text dynamics. What about \cresc #cresc. poco a poco ? i.e. if \cresc is used by itself, it prints cresc., but if you provide the optional argument, that's used instead of the default text? Yes, but I'd really like to use this \cresc command of yours *after* the note (not before, as it is now). This is the sticking point in my mind. Are you able to modify it yourself (including Carl's help in yourself)? If so, then we can have a long discussion about the new dynamic syntax. I'd encourage you to experiment with changing the parser before we get into lots of details about the new syntax, though. The parser can certainly be rewritten (like Reinhold did for \tempo). However, I think we can take advantage of the (make-music ('DynamicEvent ('tweaks ('text trick that you've been using (and so have I). The only drawback for now is that you can't specify a string as an argument without using a music function : instead of a'\cresc #my text you have to first define a make-dyn-from-this-text function, and then predefine your text: crescMyText = #(make-dyn-from-this-text my text) and only then use a'\crescMyText Whereas with a music function, you can simply do: \cresc #mytext a' ... but then again, the command has to be used *before* the note and this has many drawbacks (plus a big deal of inconsistency through the code, that i can tell: see for instance http://repo.or.cz/w/opera_libre.git?a=blob;f=definitions/text-functions.ly#l178 -- or, line 300, the awful mess with text spanners...) Which is why, rather than a C++ parser change, what I'd really like to have is a (define-music-tweak) function, that could act like define-music-function but that would *not* take the music as an argument, that would just take the string and cons' it as a 'tweak property. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Sun, Mar 01, 2009 at 08:47:28PM +0100, Frédéric Bron wrote: 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. I don't think anybody else has replied, so I'll take a stab at it. -snip- 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 What about reserving \ \ \! **only** for hairpins, and \cr \endCr \dim \endDim **only** for text? ok, we'd need extra commands for decresc and decr, but this way we could avoid the \crescTextXXX stuff entirely. - \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 Again, I'd rather use text for text dynamics. What about \cresc #cresc. poco a poco ? i.e. if \cresc is used by itself, it prints cresc., but if you provide the optional argument, that's used instead of the default text? I know that it is not possible to implement this without rewrite of the parser... This is the sticking point in my mind. Are you able to modify it yourself (including Carl's help in yourself)? If so, then we can have a long discussion about the new dynamic syntax. I'd encourage you to experiment with changing the parser before we get into lots of details about the new syntax, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
On Sun, Feb 22, 2009 at 06:37:50PM -0700, Carl D. Sorensen wrote: - \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 I don't like the idea of changing current syntax so dramatically, but I may be in the minority here. It would certainly make the convert-ly rule a pain, or else raise howls of protest from people at the changing syntax. :) Also, how would this version of \cresc work with MIDI volume? Would it just be an instant increase, or spread over a fixed 4 notes, or what? I admit that MIDI volume is a fairly minor point in lilypond. - remove unnecessary \cr, \endcr, \decr, \enddecr I'm not sure why we have both \cr and \. If the two really are equivalent, one ought to be deprecated before it is ultimately removed. I have a vague notion that \cr *was* deprecated. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
Graham Percival gra...@percival-music.ca writes: On Sun, Feb 22, 2009 at 06:37:50PM -0700, Carl D. Sorensen wrote: - \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 I don't like the idea of changing current syntax so dramatically, but I may be in the minority here. It would certainly make the convert-ly rule a pain, or else raise howls of protest from people at the changing syntax. :) Also, how would this version of \cresc work with MIDI volume? Would it just be an instant increase, or spread over a fixed 4 notes, or what? I admit that MIDI volume is a fairly minor point in lilypond. But one should not lose sight of it. One reason is that MIDI might be the most honest reflection of _meaning_ for a lot of musical features (unfortunately, not including fingerings and a few other things), and since we want to import/export not just to PDF but MIDI/MusicXML and whatever, and since we want to be able to meaningfully transform input (like being able to transpose it, or, say, tone down dynamics one notch when handing over the recorder part to a trumpet), making changes that render MIDI interpretation difficult might mean that we are moving to visual rather than logical markup closer than appropriate for Lilypond. I think it is one of Lilypond's strengths that it has a better conceptual grasp of music than, say, MusiXTeX. So it is a bad sign in my opinion when changes in the input are hard to consistently make it to MIDI. Even when one does not want to see MIDI as an output device (and I _do_ use it for accompaniment), it is nice for proofhearing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
Frederic, I have made some comments in your message below. Thanks for taking on this project. This type of proposal probably should go to lilypond-devel, rather than -user, so I'm cross-posting to -devel. On 2/22/09 1:25 AM, Frédéric Bron frederic.b...@m4x.org wrote: Hello, I am in charge of the question of (de)crescendo syntax issue in 2.12.2. 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 - 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 This part of the syntax got hashed out pretty heavily as part of 2.10. I think that the crescXXX and dimXXX syntax is where we want it. The issue is that there are hairpin crescendos and decrescendos, and there are text crescendos and decrescendos. That's why the Text word was put in there. Perhaps we could make a change, but we ought to review this carefully. The previous conversation was at http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/15693/focus=15696 This is all coupled together with the idea that there are dynamic markings that aren't really spanners, but are just markups for the individual note. - \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 I believe that this will require a rewrite of the parser. It will be challenging to identify the difference between \ which starts a crescendo spanner in your proposal above, and \my crescendo text here which starts a text spanner. - \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 I don't like the idea of changing current syntax so dramatically, but I may be in the minority here. - remove unnecessary \cr, \endcr, \decr, \enddecr I'm not sure why we have both \cr and \. If the two really are equivalent, one ought to be deprecated before it is ultimately removed. - remove unnecessary \enddim, \endcresc I know that it is not possible to implement this only with scheme and lily code but I am sure it is possible in C++. Could you please comment on these propositions and give any other ideas. F. Bron PS: attached is a file that show the behaviour of the commands. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel