[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shortcut for \repeat unfold

From: Jean Abou Samra
Subject: Re: Shortcut for \repeat unfold
Date: Sat, 25 Sep 2021 16:11:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Le 25/09/2021 à 09:46, Lukas-Fabian Moser a écrit :

In short, I propose to make the first argument to
\repeat optional, making \repeat n music equivalent to
\repeat unfold n music.

Thanks for working on that!

The issue I have with your idea is that to me, \repeat unfold and \repeta volta/tremolo have slightly different semantics:

\repeat volta and \repeat tremolo create "time-honored" visual indicators for repeated music, so they are commands that correspond to special music layouts.
\repeat unfold saves typing while inputting music.

Of course, the distinction is not very strict, in particular since there's \unfoldRepeats. But still I'm not sure it's ideal syntax-wise if users have to use the same command for "saving typing" and for "creating musical repeat signs / tremolo notation". And this, I think, is exacerbated with your suggestion, because if \repeat alone is the keystroke-saving command, then \repeat volta and \repeat tremolo look like variants of that: Adding a qualifier turns the command into something completely different.

The musical validity of this approach might
be questionable, but LilyPond thinks of these
types of repeats in similar ways. \repeat unfold
does not copy the music n times, it just wraps it
in UnfoldedRepeatedMusic.

It would make reasonable sense to write a function
changing unfold to another repeat type, like

\version "2.23.4"

unfoldToPercent =
#(define-music-function (music) (ly:music?)
     (lambda (m)
       (if (music-is-of-type? m 'unfolded-repeated-music)
           (make-music 'PercentRepeatedMusic m)

var = \repeat unfold 4 \relative { c'8 g' c g }

{ \var }
\unfoldToPercent \var

So I do view these kinds of repeats similar enough
to warrant similar syntax.

I think it's a trap to see \repeat unfold as syntactic
sugar for repeating a sequence of characters n times
in the input. For instance,

\relative { \repeat unfold 4 c'1 }

is not the same as

\relative { c'1 c'1 c'1 c'1 }

My experience is that every time I want to repeat a note
four times, I have a half-a-second wonder about whether
typing "\repeat unfold" will be shorter than cut-and-paste.
Absolutely. Of course it depends on which type of music you engrave, but in my "common practice"-heavy everyday work, \repeat unfold 16 d8 comes up _very_ often.
Other possibilities:

- "\rep n music", not as self-telling (and I think Lukas
  only calls his shortcut \rep because redefining \repeat
  is not syntactically valid);
... 'n 'cause it's even shrtr. :-)
- "music * n", attractive but the difference between c1*5
  and { c1 } * 5 would be confusing; also, for longer passages
  one would rather state the number of repetitions from the
  start than having to remember to put it at the end;
Yes, that is confusing to a degree I'm very skeptical if it's possible at all. You've already given the main example.
- "\* n music", very short but doesn't read as nicely I think,
  and I don't view repeats as special enough to warrant
  this kind of syntax with many special characters.

I think I disagree. After David suggested it in the gitlab thread, I used it in some scores and found it to be very convenient. (Maybe I'm biased because on german keybaord layout, \* can be entered in a single movement with a quite enjoyable thumb-midde-finger-pinkie-ring-finger flourish :-).) Also, brevity is key for keystroke-saving commands.

Keyboards may be an important factor. Part of my
dislike for \* comes from the fact that on French
keyboards, the backslash is farther to the left,
on the same key as 8, making it less convenient
than what you describe.

They are not the only factor though. Let's see how
it looks visually:

{ c'1 \repeat 5 dis'8-_ c'1 }

{ c'1 \x 5 dis'8-_ c'1 }

{ c'1 \* 8 dis'8-_ c'1 }

{ c'1 dis'8-_**8 c'1 }

With \x or \*, I find it harder to discern the structure.
They are so small that they seem sprinkled over the input
without grouping other elements -- the third one in
particular looks like \* is some shortcut and 8 is
a duration repeating the previous pitch as in { c'1 8 }.

I said \repeat unfold was overly long, but that is not
to say that we should try to squeeze the command in as
few characters as possible ;-) Syntax readability matters
a lot to me, for editing scores after writing, for
communication on mailing lists, and just to navigate
in the input.

I like Werner's suggestion with ** better already.
What worries me a bit is the difference with the
existing use of *, which might be confusing. R1*5
will be (most of the time) equivalent to R1**5,
whereas c'1*5 will not be the same as c'1**5.
Something like c'1\p**5 will be valid, contrary to
c'1\p*5; c'1*4/5 will work but not c'1**4/5; …

I have to think about it a bit more.

Just as a counter-point, while I'm a light user / copyist, I don't think I've EVER used repeat unfold, while repeat percent happens a lot.

I actually quite like the "\x16 d8" idea as a shortcut, but what I'm saying is don't think it's a good idea, just because YOU do it a lot. Other people may have completely different work patterns ...

Yes of course, and LilyPond is a great tool for all different kinds of work patterns. But it's not a question of making one job easier for the price of making others harder, in which case your argument would be more relevant.

But is it a case of making a niche case easier, when the same trick could be used instead (mutually exclusive) to make the common case easier?

IS unfold the best candidate? Just because the OP makes extensive use of it, doesn't mean everyone else does. I'd rather it was percent, but I suspect I genuinely am a minority.

Well, if we are at gauging use…

$ git grep "\\\\repeat percent" -- Documentation/snippets/ | wc -l
$ git grep "\\\\repeat tremolo" -- Documentation/snippets/ | wc -l
$ git grep "\\\\repeat volta" -- Documentation/snippets/ | wc -l
$ git grep "\\\\repeat unfold" -- Documentation/snippets/ | wc -l

where Documentation/snippets/ is the folder that holds LSR
snippets included in the official documentation.

However, that was not the main point for me: \repeat unfold
is a command that you can use with the only purpose of saving
typing, so it would make sense to have it save more typing,
to take out the burden of wondering "will it be shorter if I
cut-and-paste". It can also be used with musical significance
(my example changing unfold to percent above). \repeat percent
only has the musical significance.

Another reason is that \repeat unfold is often used for filler
music in short snippets, like on the LSR or the mailing lists,
making it desirable for it not to be distracting.

One of the reasons I argue against making \repeat $n \music equivalent to some \repeat X $n \music.

An implementation that doesn't require changes in the lexer/parser would have the advantage of allowing you to re-define it according to your needs. LilyPond is so great it even allows you to do:

\version "2.22"

repeat-shorthand = unfold

"\*" =
#(define-music-function (n mus) (index? ly:music?)
   #{ \repeat $repeat-shorthand $n { #mus } #})

  \*8 c'4

  #(set! repeat-shorthand "percent")
  \*8 d'4

  #(set! repeat-shorthand "tremolo")
  \*8 e'16

  #(set! repeat-shorthand "volta")
  \*2 { f'4 e' d' c' }

But I expect also Jean's way of re-defining \repeat would allow for such a configurable option.

But what if more people would benefit if that tweak were applied to figured bass, rather than tablature?

Then we should find a way to make both happen (or let the user select according to their needs). :-)

I wouldn't push it so far -- it's easy enough to write
a music function for the repeat style you use most
often, just like you can shorten a lot of things
with variables and music functions, even more
conveniently now that we have \etc (let's hope the
latter would start working with \repeat someday).

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]