Code review - Issue 577180043: Introduce breakingRehearsalMarks for line-breaking RehearsalMarkshttps://codereview.appspot.com/2019-12-17T10:12:14+00:00rietveld
Message from unknown
2019-12-07T14:48:35+00:00thomasmorley651urn:md5:427bc098e48e8b654d2d63a269ef0737
Message from thomasmorley65@gmail.com
2019-12-07T14:50:46+00:00thomasmorley651urn:md5:e469c190cb4c592d58fada3591443a0e
Message from nine.fierce.ballads@gmail.com
2019-12-07T17:48:07+00:00Dan Ebleurn:md5:7c3a72a524f1b36e775c92513a472125
Harm,
I have to prepare for a musical event tonight. I will probably be some time before I can review and understand your changes.
Please clarify whether you are using this for genuine rehearsal marks (e.g. A, B, C, ...) or whether you are expanding the abuse of RehearsalMarks to satisfy another need.
I have some stale patches related to rehearsal marks that I have been hoping to return to after fixing compiler warnings.
There was one that split the mark event into three classes reflecting current use:
* default rehearsal mark (automatic sequence number)
* specific rehearsal mark (user-provided sequence number)
* ad-hoc mark (all kinds of abuse)
https://codereview.appspot.com/340650043/
There was another that added a new \depart command for marks like "D.C." and "Coda" so that we wouldn't need to continue abusing rehearsal marks for those.
https://codereview.appspot.com/337520043/
Message from thomasmorley65@gmail.com
2019-12-07T22:44:16+00:00thomasmorley651urn:md5:226cc5a8fe4bc47dc777386ae9c6e205
On 2019/12/07 17:48:07, Dan Eble wrote:
> Harm,
>
> I have to prepare for a musical event tonight. I will probably be some time
> before I can review and understand your changes.
I've no problem to postpone this for while.
> Please clarify whether you are using this for genuine rehearsal marks (e.g. A,
> B, C, ...) or whether you are expanding the abuse of RehearsalMarks to satisfy
> another need.
This patch makes it possible to write two marks at a line-break, one at the end of a line, the other at start of the new line. This works for _all_ kinds of RehearsalMark: default rehearsal mark, specific rehearsal mark and ad-hoc mark (as you called them).
So far it doesn't "expand" the abuse of RehearsalMark, but hopefully simplifies it. Ofcourse there are other workarounds available in LSR and on the mailing-list, though I like the user-interface, accepting imho most naive use-input.
In one of your linked patches, you define a new grob, DepartureMark. I already thought about something along these lines: we currently have MetronomeMark and RehearsalMark, a new one accepting text only wouldn't be wrong. Though I'd called it TextMark not DepartureMark, it is more general imho, because not all text may be departure instructions.
Though, iiuc this new grob doesn't include the ability to be printed differently at line-end/start, but the here proposed function could do so (with small modifications).
>
> I have some stale patches related to rehearsal marks that I have been hoping to
> return to after fixing compiler warnings.
>
> There was one that split the mark event into three classes reflecting current
> use:
> * default rehearsal mark (automatic sequence number)
> * specific rehearsal mark (user-provided sequence number)
> * ad-hoc mark (all kinds of abuse)
> https://codereview.appspot.com/340650043/
>
> There was another that added a new \depart command for marks like "D.C." and
> "Coda" so that we wouldn't need to continue abusing rehearsal marks for those.
> https://codereview.appspot.com/337520043/
Message from nine.fierce.ballads@gmail.com
2019-12-11T17:25:24+00:00Dan Ebleurn:md5:9625f76f8de062e47be9130b7b3087e4
On 2019/12/07 22:44:16, thomasmorley651 wrote:
> In one of your linked patches, you define a new grob, DepartureMark. I already
> thought about something along these lines: we currently have MetronomeMark and
> RehearsalMark, a new one accepting text only wouldn't be wrong. Though I'd
> called it TextMark not DepartureMark, it is more general imho, because not all
> text may be departure instructions.
Adding a type for jumps (as I think we agreed to call them later in the review) is
important because as a group, they should be styled differently than rehearsal
marks, depending on the kind of score: above the staff in a vocal part, below in
an instrumental part, and with different alignment and break-positioning. The
question is then, would you want all TextMarks to follow along when "D.C." etc.
are moved? I think you might just want to have RehearsalMark and JumpMark,
each with a clear primary purpose, and provide ways to stretch the use of either.
> Though, iiuc this new grob doesn't include the ability to be printed differently
> at line-end/start, but the here proposed function could do so (with small
> modifications).
I'm starting to look at your change now.
Message from nine.fierce.ballads@gmail.com
2019-12-12T01:29:27+00:00Dan Ebleurn:md5:9dbbf7fcfe8a2e3082389f2e545e3767
Harm,
With respect, I'm far from convinced that this is a good idea, but I
will continue to think about it. Thoughts so far:
* The user provides music for the appearance of the mark at the
beginning or end of a line, but can he control what happens in the
middle? They seem to stack vertically. What if the user would
prefer them to be side by side?
* The regression tests cover only line breaks. The unbroken
appearance is not covered.
* I am concerned about the complexity of this function as it deals
with mark sequence numbers. I'm skeptical that it's a fair trade
for what it offers.
* I struggle with the semantics of using one event and grob to do
double duty, e.g. as both a fermata and a rehearsal mark. One of my
stale experiments is a performer that inserts rehearsal marks into
MIDI files. I don't relish the thought of trying to extract a
MIDI-compatible rehearsal letter/number from such a mishmash.
Message from thomasmorley65@gmail.com
2019-12-12T11:14:35+00:00thomasmorley651urn:md5:a3cf18be73ef0b23e7b89d0e35976477
Hi Dan,
up to now we provide only RehearsalMark taking arbitrary text with the possibility to align it to the value taken from 'break-align-symbols.
The other grobs supporting break-alignable-interface are BarNumber and MetronomeMark, even less convenient to take arbitrary text.
So users have no chance to avoid using RehearsalMark for this purpose.
This leads frequently to the need to combine RehearsalMarks, print them differently on top and bottom of a system or print them differently before and after a line-break.
Although this is pretty often requested, we don't provide any functionality to do so. Consequently users write their own workarounds.
A quick search results:
http://lsr.di.unimi.it/LSR/Item?id=202
http://lsr.di.unimi.it/LSR/Item?id=575
http://lsr.di.unimi.it/LSR/Item?id=735
http://lsr.di.unimi.it/LSR/Item?id=736
http://lsr.di.unimi.it/LSR/Item?id=976
http://lsr.di.unimi.it/LSR/Item?id=977
http://lilypond.1069038.n5.nabble.com/Nice-workaround-for-simultaneous-rehearsal-marks-thanks-Neil-td3086.html
Some of them are really ugly, imho.
My current patch tries to tackle a subset of these requests: line-breaking rehearsal marks.
There's some fall-back, if the function is applied mid-line, though.
On 2019/12/12 01:29:27, Dan Eble wrote:
> Harm,
>
> With respect, I'm far from convinced that this is a good idea, but I
> will continue to think about it. Thoughts so far:
>
> * The user provides music for the appearance of the mark at the
> beginning or end of a line, but can he control what happens in the
> middle? They seem to stack vertically. What if the user would
> prefer them to be side by side?
Thus the NR reads:
"Although some defaults are given, it makes litte sense to use this function at the middle of a line."
Actually a function to combine RehearsalMarks mid-line would be better for this use case.
Although I've spent some thoughts in this direction I've not found a nice user-interface for it yet.
> * The regression tests cover only line breaks. The unbroken
> appearance is not covered.
True, I didn't cover this case, because it's discouraged in NR
> * I am concerned about the complexity of this function as it deals
> with mark sequence numbers. I'm skeptical that it's a fair trade
> for what it offers.
As long as default rehearsal mark and specific rehearsal mark are allowed as input for the function, one needs to care about context-property reheasalMark otherwise subsequent calls of \mark \default would appear to be out of order.
So this is a requirement.
> * I struggle with the semantics of using one event and grob to do
> double duty, e.g. as both a fermata and a rehearsal mark. One of my
> stale experiments is a performer that inserts rehearsal marks into
> MIDI files. I don't relish the thought of trying to extract a
> MIDI-compatible rehearsal letter/number from such a mishmash.
I do understand this concern.
Though, until we provide other grob(s) to take arbitrary, break-alignable text, what should users do differently, then use one of the mentioned work-arounds or this patch?
Imho, this patch's user-interface is preferable compared with the others. (Ok, it's my patch, so I'm convinced ofcourse lol)
Otoh, I wouldn't object to postpone this patch for a while until you could revive your own patches.
Nevertheless, for (pseudo code):
{
b1 \whateverMark #1
c' \whateverMark "second time go to coda"
d' \whateverMark "go to mark 1"
\break
\whateverMark "coda"
e'
}
you'd need either some functionality to print "go to mark 1" and "coda" where they belong.
Or different grobs taking those texts.
Can't think of another method.
Message from thomasmorley65@gmail.com
2019-12-17T10:12:14+00:00thomasmorley651urn:md5:7eb3dba75d9573a8e0c660e2eb0ce135
Dan, I've set it to needs_work for now.