Menu
▾
▴
#2858 Document \shape music function
Originally created by: *anonymous
Originally created by: tdanielsmusic
Originally owned by: tdanielsmusic
Provide documentation for \shape in NR. This function and two
reg tests were added in commit
[r8ffeb1bd519d051394624b6b24503c7082893808].
Section 5.5.4 is the best place.
Trevor
Discussion
Originally posted by: tdanielsmusic
Doc: improve documentation of Bézier curves (2858)
- add \shape function
- show example of cubic-shaped slur
http://codereview.appspot.com/6561064
Labels: Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: tdanielsmusic
(No comment was entered for this change.)
Owner: tdanielsmusic
Status: Started
Originally posted by: dak@gnu.org
What's the opinion of people about swapping the "offset" and "grob" arguments of the \shape function, renaming the "grob" argument to "item", make it of type string-or-music? (as defined in issue 2859) and, depending on whether the "item" is a string or music, do either an override on the given grob name or tweak the given music directly?
That would allow -\shape #(...) \( for shaping a slur without having to specify a grobname.
Cc: david.na...@gmail.com thomasmo...@gmail.com
Originally posted by: tdanielsmusic
Would -\shape work for \laissezVibre and \repeatTie too? If so, this
follows the increasing trend to move away from \overrides to \tweak-like
commands. If it doesn't work then I'm not sure.
Originally posted by: david.na...@gmail.com
The inability of \shape to work as a tweak always seemed like a shortcoming to me, and I assumed that a separate command would be needed. A quick test (see attached) shows that the approach which David K. outlined does work for curves including LaissezVibrerTie and RepeatTie, and also that it can be used as a tweak with broken slurs as well.
The only misgiving I have is the way the grob name follows the sometimes-rather-long offset in the override form. It looks a little odd to me, that name stranded at the end like that. Further, as I write the command, I generally think: "shape the slur with these values..."
But, really, I think the advantages gained are significant.
Originally posted by: dak@gnu.org
"The only misgiving I have is the way the grob name follows the sometimes-rather-long offset in the override form."
Complete agreement. However, if the grob name becomes optional in front _and_ the music becomes optional at the end, one would need to write \default to actually skip the music argument.
I have for other reasons pondered how to do a mechanism where a skipped optional argument leads to a different remaining argument list and/or the previous arguments can be consulted for forming the rest of the argument list.
In general, it seems like the required complexity in implementing this sort of case-lambdaeque functionality, in applying it, and in understanding the resulting behaviors from a user view of the music functions are not really desirable.
As to "a separate command would be needed": after issue 2717 passes, \single\shape ... could be used, However, you would still need to know the name of the grob. It seems nicer to change the shape function instead.
Offtopic: it uses (define ((shape-curve offsets) item) ... Is there a reason that this is not just (define (shape-curve item) ... and is later used as #shape-curve rather than #(shape-curve offsets) ?
Guilev2 does not support curried definitions by default (it requires loading an extra module), and in this case, the currying seems to serve no purpose.
Originally posted by: dak@gnu.org
"The only misgiving I have is the way the grob name follows the sometimes-rather-long offset"... Come to think of it: why switch the order of arguments in the first place? When used as a \tweak, it will be applied to slurs, ties and similarly brief stuff.
\shape ( #'(...........................)
or even
\shape \laissezVibrer #'(............................)
seems quite tolerable. The reason to stick music arguments at the end is that music arguments tend to be long (which is not the case here) and that often one wants to apply multiple functions with arguments ona music expression. Ok, something like
\shape \tweak #'color #red \laissezVibrer #'(........................) is unnice, but one can write
\tweak #'color #red \shape \laissezVibrer #'(........................) instead.
Hm, only half convinced, but it would save writing a convert-ly rule.
Originally posted by: david.na...@gmail.com
"Offtopic: it uses (define ((shape-curve offsets) item) ... Is there a reason that this is not just (define (shape-curve item) ... and is later used as #shape-curve rather than #(shape-curve offsets) ?
Guilev2 does not support curried definitions by default (it requires loading an extra module), and in this case, the currying seems to serve no purpose."
Nice catch. Absolutely right: what sense is there passing around offsets when it's right there in the environment?
"When used as a \tweak, it will be applied to slurs, ties and similarly brief stuff.
\shape ( #'(...........................)
or even
\shape \laissezVibrer #'(............................)
seems quite tolerable. The reason to stick music arguments at the end is that music arguments tend to be long (which is not the case here) and that often one wants to apply multiple functions with arguments ona music expression. Ok, something like
\shape \tweak #'color #red \laissezVibrer #'(........................) is unnice, but one can write
\tweak #'color #red \shape \laissezVibrer #'(........................) instead."
I like this. Seems to me, the flexibility in ordering is a good thing.
"[...] but it would save writing a convert-ly rule"
Good enough for me!
Originally posted by: k-ohara5...@oco.net
The current \shape works nicely
{
\shape RepeatTie #'((-2 . 1.5)(-1 . 3 )(0 . 3 )(1 . 1.5))
b1\repeatTie }
It is too long to use as a tweak, without making the input harder to read, and too valuable to users to complicate with an optional argument.
Originally posted by: david.na...@gmail.com
Though, as per David K.'s last suggestion, its syntax as an override is exactly the same, with the added bonus that it can be used as a tweak.
Originally posted by: tdanielsmusic
The value of implementing \shape as both an override and tweak is so
the tweak form is available for modifying the ties between individual
notes in chords. (Incidentally, the need for this in current versions
of LilyPond was embarrassingly shown by Bertalan Fodor recently, see
http://bartruffle.blogspot.co.uk/2012/09/musescore-vs-score-vs-lilypond-vs.html#more ) But, like Keith, I think the override form is clearer
for normal single-item use.
Trevor
Originally posted by: dak@gnu.org
Adding to comment #8: the problem with the tweak form having the music first is that it works reasonably well only when \shape is the only function that does things like that. As soon as multiple commands are being used with that convention together, they have to be nested in unsavory ways.
The \no and \hide commands don't have that problem since they have only a _single_ argument. Now of course we can give the \shape command a
string-or-list? argument first, and a list-or-music? command afterwards, and check and complain about the combinations list-list and string-music in the function itself rather than letting the signatures sort this out.
But this seems quite awkward. So I think, for "tweak-or-override-with-parameters", we should likely bite the bullet and place the grob property path last consistently.
Originally posted by: tdanielsmusic
OK, so what needs to be done to implement this? I'd like to complete the
documentation so I can work on other changes to the same file.
Trevor
Labels: -Patch-review Patch-needs_work
Originally posted by: dak@gnu.org
The order of arguments is not much of an issue as that can be brought into line with a convert-ly rule mostly. Personally, I think it makes sense to be consistent regarding "tweak-or-override-with-parameters" functions, putting the tweaked item, whether it be grob name or music, last. The alternative of requiring a trailing \default to indicate an override would have the advantage of being able to specify _both_ grob as well as affected music, as \tweak can also take grob name. However, the additional inconvenience of having to write \default for every override is not offset by this advantage, as one can always, in case of need, use \single on an \override in order to arrive at a grob-specific \tweak.
I'll be proposing a changed patch for \shape presently along those lines. I'll skip the somewhat related support of "context.grob" syntax as slurs, for which \shape is actually important, really only happen at Voice level. I have a change to support this without quotes in the queue, but it still fails with a single regtest because of a parser lookahead issue, and it is not really important for \shape. Also, it is a one-line change, just the predicate for the grob specification.
Originally posted by: dak@gnu.org
There are documentation suggestions from David Nalesnik in comment #1 <URL:http://codereview.appspot.com/6585052/#msg1> of the code review for issue 2873. As written in comment #4 there <URL:http://codereview.appspot.com/6585052/#msg4>, I would not want to add those changes myself as
a) I don't have an overview over the documentation at all
b) it might interfere with this issue.
But one should not lose sight of those suggestions in the light of this issue.
Originally posted by: dak@gnu.org
Issue 2873 has been committed. \single is not going to be interesting in connection with \shape since you can just apply the new form of \shape directly as a tweak. In a similar vein, there is no need for being able to specify the affected context for the override (like TabVoice.Slur) since Bottom will be fine for all the things that you would want to use \shape on.
In other words: I don't think that anything should be blocking _this_ issue any more.
Originally posted by: tdanielsmusic
Doc: improve documentation of Bézier curves (2858)
- add \shape function
- show example of cubic-shaped slur
http://codereview.appspot.com/6561064
Labels: -Patch-needs_work Patch-new
Originally posted by: tdanielsmusic
Doc: improve documentation of Bézier curves (2858)
- add \shape function
- show example of two curves being shaped
- show example of line-broken slur
- show example of S-shaped slur
- relegate setting absolute values to end
and give a more realistic example
http://codereview.appspot.com/6561064
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: tdanielsmusic
Doc: improve documentation of Bézier curves (2858)
- add \shape function
- show example of two curves being shaped
- show example of line-broken slur
- show example of S-shaped slur
- relegate setting absolute values to end
and give a more realistic example
http://codereview.appspot.com/6561064
Labels: -Patch-countdown Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests. Also passes a full make doc - although the subsubsubheading looks odd against the reast of the PDF - output is in italic, which seems to not be in keeping with the rest of the NR
Labels: -Patch-new Patch-review
Originally posted by: tdanielsmusic
Thanks James.
Re subsubsubheading, see Rietveld comment.
Trevor
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown