Add a note clarifying the potential change of the repetition context.

[lpugin]

It would be good to make users aware that when using repetitions (groups or measures), the context when the repetition code is being applied might be different than when the group being repeated started. This is certainly important for octaves and durations. Any thing else?

In other words, transcriber needs to keep in mind that the repetitions repeat the code as is and not the notation represented. Or at least, depending on the context, the result might be different. (We probably need an example...)

[ahankinson]

Depending on how the repeated rhythm sequences land, it could also apply — if you have a set of durations and then the repeat group only covers a subset of them.

[BaMikusi]

Sorry, I just see this new issue -- so then I reference the example I just entered elsewhere:
#110 (comment)

[lpugin]

Thinking about this overnight I think we need to evaluate if repetitions indicate a repetition of the code and not of the music is really what was originally meant. It might be just a side effect of renderers like Verovio. It seems to me that reversing this would not be problematic because to have it work with the current behaviour of Verovio, transcribers had to make the code more explicit That is, adding additional context duration and / or octave at the beginning of the group to be repeated.

This means that we could re-evaluate this and change Verovio accordingly without having problems with the old data. Actually, it might be even fixing old data that we haven't identified as problematic because of this. In the end, this would be not only a clarification, but also an improvement for transcribers since the change context side effect in the use of the repetitions always comes "as a surprise" when cataloguing.

[lpugin]

PS another context that might have changed in the course of a repetition declaration is the clef, but since this is visually given in the notation, I don't think it would be necessary - or even correct? to reset it when the repetition is applied. Any thoughts?

[lpugin]

Considering this:

4'D/G{8AB}!{A6B''C}!ff/i/i/

It is currently interpreted as:

When transcribers probably expect:

Verovio can be changed accordingly. We can discussed if this needs to be bound the version change or not.

[BaMikusi]

While the old specs seem vague on this point, I don't think there can be a doubt that what was really intended was the repetition of the music and not the code. So, adjusting Verovio to prioritize the repetition of the rendered notation, rather than that of the code, would IMO be good.

I somewhat wonder, though, where such a decision would leave us with respect to the code itself. I mean, Verovio can supply the context (implied octaves and durations) for the repeated segment, and render the music as expected by the cataloger, but would the code itself still be correct, then, strictly speaking? Or is its imperfection simply rectified by Verovio?

[ahankinson]

Depends on how you define the code and its interpretation. If you simply say something like "When segments are repeated, the context is taken from the initial declaration and not from the repeat" then that provides the rule in how the code should be evaluated. (The wording would need to be finessed, of course.)

So the code is always correct, if you first define what "correct" is. :-D

[BaMikusi]

Fair enough.

As for @lpugin's other question regarding clefs, I think these should also be implied on the repeat, just as durations and octaves. This, for example, is not an unrealistic scenario:
8,C%G-2 'G^E %F-4 ,,B %G-2 'G^F^D/i/

And if Verovio gets adjusted to repeat the notation, the clef quite characteristically belongs to that, too (even if the sounding pitch etc. would still happen to be OK in this case).

[ahankinson]

I think we can simply say that in repeat groups, changes to clef, etc. are not allowed? That is, if you have a repeating clef change figure you’re going to have to spell it out every time, rather than use any sort of repeat group.

[BaMikusi]

If I were a cataloger, I would likely want to make use of chortcuts exactly in the cases when the code is rather tiresome to write -- e.g., for such an accompaniment figure involving recurring clef changes. And I am not sure if it's useful to have too many lower-case explanations to any general rule, for these will presumably not be read anyway.

But to assume the role of the devil's advocate, moving to the other extreme: nowadays, when even the least experienced PC users know how to copy-paste some part of their code, such shortcuts are presumably of much less relevance than they might have been a few decades ago.

[ahankinson]

Yes, just today Claudio asked why we even need repeat groups when copy-paste is freely available.

[lpugin]

I have to look at it but at a first glance I am not sure what would need to be changed here. I can see there is something weird, but fixing it would require an additional clef change to be inserted in the second measure.

This is not quite like an exact copy of the music content since the clef change does not exist in the previous measure - I am thinking of a larger context such as this:

Also, traditionally, the clef changes are always put before bar lines, so I would imagine that something like this would be written like:

In which case this code should (and already does) work properly:

2C%F-4 /8,C%G-2 'G^E %F-4 ,,B %G-2 'G^F^D%F-4 /i/

So there is not much we can do with clefs IMO because they do set a context but are also visible elements, so it is not just about the coded context as for octave and duration.

[BaMikusi]

Thanks, I understand that there is a difference, and can live with that.

And as for the other issue: would it make sense to perhaps do away with these shortcuts in V2 altogether, once they will still be in the old data and so the functionality to render them must remain?

[jenniferward]

I was also going to ask why we need the shortcuts. It was probably convenient for typewriters, but I always use copy/paste.

[lpugin]

I fixed Verovio here. It is still a separate branch but we can make a PR when desired. It works with the case above using repeated figures within repeated measures.

[lpugin]

This is what we would get with this convoluted - and not to be recommended - example. It seems to be right to me, but somebody should double check

8.68!({ABC''A})!f/i/i/i

[lpugin]

PS For the record, what Verovio produces without the improvement