PATCHES - Countdown to July 11
Here is the current countdown list. The next countdown will begin July 11th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1459 Let -dembed-source-code include images and verbatim files - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1459 !1457 Improve document-property-operation - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1457 !1455 Minor improvements in doc build infrastructure - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1455 !1450 CG: add some info about GC - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1450 Countdown: !1456 Draft: Doc-LM + Web: update setup instructions - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1456 !1454 Documentation/GNUmakefile: add info to doc target - John Wheeler https://gitlab.com/lilypond/lilypond/-/merge_requests/1454 Review: !1464 Translator listener cleanup - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1464 !1463 Engraver cleanup - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1463 !1461 Enable C++14 - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1461 !1460 New figured bass glyphs - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1460 !1458 Add \rhythm markup command - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1458 !1452 tex/GNUmakefile: add default target - John Wheeler https://gitlab.com/lilypond/lilypond/-/merge_requests/1452 !1451 Draft: Fix \fine issues - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1451 !1426 Info: build: resolve build issues concerning compiled bytecode - John Wheeler https://gitlab.com/lilypond/lilypond/-/merge_requests/1426 New: No patches in New at this time. Waiting: !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 Cheers, Colin
Re: \fine, pre-process-in-final-translation-timestep & co.
> Le 9 juil. 2022 à 22:08, Dan Eble a écrit : > > Do you have any concern about other engravers might have acknowledged the > grobs that are about to be killed, which might have performed interesting > actions assuming that the grobs would continue to exist on one system or > another? Does the battle-tested algorithm sort out all the consequences of > creating those grobs? I won’t know for sure until it has been tried out and all the code paths can be seen. I don’t anticipate major problems right now, although it has been a long day and I might be missing something. I see that I expressed myself poorly with ‘battle-tested’. It’s more like: the code is written to work that way and has received a lot of thought, so if break-visibility etc considerations are viewed as a sane way of doing the cut, that body of code can be profitably reused. For what it’s worth, doing it that way is _not_ a panacea in general either without some further thought: taken as-is, it will make clef/time/key changes right after fine print a dangling clef/time signature /key signature at the end. I’m not sure how to solve that in general. I think the idea of cutting spanners should work out well enough. For items, some more thinking is needed. Also, one thing you would need to be careful about is how references are rearranged (the equivalent of break substitution). While different systems live mostly independent lives after line breaking, some routines do need to look at other systems. I _guess_ the sanest way would be to eliminate those references completely instead of leaving them as references to dead grobs. In short: this is not the kind of idea I can crank out code for in two minutes.
Re: \fine, pre-process-in-final-translation-timestep & co.
Dan Eble writes:
> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>>
>> Instead of rearranging the translation process to let \fine abort
>> translation, let translation run normally until the end.
>>
>> Then, ‘cut’ the result.
> ...
>> For layout output, there is already a battle-tested algorithm, the
>> one used to break into pieces after determining page breaking. I
>> think it should be feasible to adapt it to run right after
>> translation a first time to eliminate the part after \fine. More
>> precisely, it should be as if a \break was present as \fine and the
>> subsequent systems were not printed.
>
> Do you have any concern about other engravers might have acknowledged
> the grobs that are about to be killed, which might have performed
> interesting actions assuming that the grobs would continue to exist on
> one system or another? Does the battle-tested algorithm sort out all
> the consequences of creating those grobs?
You mean, battle-tested like with
\score {
{
\set Score.skipTypesetting = ##t
\skip 1
}
\midi { }
}
?
--
David Kastrup
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote: > > Instead of rearranging the translation process to let \fine abort > translation, let translation run normally until the end. > > Then, ‘cut’ the result. ... > For layout output, there is already a battle-tested algorithm, the one used > to break into pieces after determining page breaking. I think it should be > feasible to adapt it to run right after translation a first time to eliminate > the part after \fine. More precisely, it should be as if a \break was present > as \fine and the subsequent systems were not printed. Do you have any concern about other engravers might have acknowledged the grobs that are about to be killed, which might have performed interesting actions assuming that the grobs would continue to exist on one system or another? Does the battle-tested algorithm sort out all the consequences of creating those grobs? — Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
> Le 9 juil. 2022 à 18:28, Dan Eble a écrit :
>
> Are you serious enough about this suggestion to propose syntax that you would
> consider acceptably explicit and that could actually be implemented?
To be clear, I’m not trying to find syntax acceptably explicit for me; this is
not a judgement. I just wonder if we can find syntax that is explicit, period,
i.e. syntax that lets the user tell which events that should be kept at \fine
and which that shouldn’t.
My understanding is that there are two use cases for \fine right now: using it
as a kind of memorable shorthand for \bar "|." at the end of the piece, and
using it in \repeat segno to mark the end of the played music so that engraving
can print "fine" and (unfoldRepeats-ed) MIDI can stop.
The problem may be simpler if we accept to make separate commands for these two
uses cases. For example, instead of
\repeat segno 2 {
…
\volta 2 \fine
…
}
one can imagine
\repeat segno 2 {
…
\volta 1 {
…
}
}
Repeats are complicated and I didn’t give this much thought, so it might make
no sense, but you see the basic idea: \unfoldRepeats would be able to unfold
the music in a way that doesn’t need interrupting translation with an event in
the middle. In the above, which … an event at the point of fine was entered in
determines whether it is included at the unfolded end.
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 9, 2022, at 11:56, Jean Abou Samra wrote: > > A third option: get out of this uncomfortable situation by > changing the syntax (it hasn't made it to a stable release > after all) so that which events are included and which > are not is fully explicit in the ly code. This idea is a bit vague to be called an option yet, and "fully" explicit makes me chuckle in light of issue #34. Are you serious enough about this suggestion to propose syntax that you would consider acceptably explicit and that could actually be implemented? I believe that I have done the best I can on it, so working on my own to find a better best would likely be a waste time. -- Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
Le 09/07/2022 à 17:38, David Kastrup a écrit : Unmatched events are a problem in MIDI. MIDI processors and sequencers working with files may to some degree try to repair such problems, partly because they need to do so when cutting and pasting regions as well. But you don't get guarantees. Thanks for explaining this. I guess it would also be an option to emit end events at \fine but not start events, if they can be told apart. A third option: get out of this uncomfortable situation by changing the syntax (it hasn't made it to a stable release after all) so that which events are included and which are not is fully explicit in the ly code.
Re: \fine, pre-process-in-final-translation-timestep & co.
Jean Abou Samra writes: > Le 09/07/2022 à 16:31, Dan Eble a écrit : >> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote: >>> Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while >>> outputting, just stop where \fine was used. >> For the events that are simultaneous with the \fine, would you emit them or >> not? >> If you would emit them, then you would emit note-on events. >> If you would not emit them, then you would not emit note-off events. > > Is it a problem not to emit note-off events at the end of the piece if > it's going to end anyway? Unmatched events are a problem in MIDI. MIDI processors and sequencers working with files may to some degree try to repair such problems, partly because they need to do so when cutting and pasting regions as well. But you don't get guarantees. -- David Kastrup
Re: \fine, pre-process-in-final-translation-timestep & co.
Le 09/07/2022 à 16:22, Dan Eble a écrit :
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
For example, whether an item on the non-musical column at the point of \fine is
included depends on whether its break-visibility makes it visible at EOL. The
fine text itself will thus be included, while a rehearsal mark won’t. That is
just as expected.
Not exactly.
```
void
Mark_engraver::finalize ()
{
if (final_text_)
{
// A mark created at the very end is always visible even if it would not
// be visible at the end of a broken line.
set_property (final_text_, "break-visibility",
scm_c_make_vector (3, SCM_BOOL_T));
}
final_text_ = nullptr;
}
```
Perhaps. On the other hand, would we really want that behavior
for a premature end at \fine? The most likely case is a
\mark \default marking the start of the section after
\fine, which shouldn't be displayed if that section isn't
printed.
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 9, 2022, at 10:38, Jean Abou Samra wrote: > > Le 09/07/2022 à 16:31, Dan Eble a écrit : >> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote: >>> Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while >>> outputting, just stop where \fine was used. >> For the events that are simultaneous with the \fine, would you emit them or >> not? >> If you would emit them, then you would emit note-on events. >> If you would not emit them, then you would not emit note-off events. > > Is it a problem not to emit note-off events at the end of the piece if it's > going to end anyway? Good point. I assumed it would be, but I would have to research that. — Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
Le 09/07/2022 à 16:31, Dan Eble a écrit : On Jul 8, 2022, at 13:39, Jean Abou Samra wrote: Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while outputting, just stop where \fine was used. For the events that are simultaneous with the \fine, would you emit them or not? If you would emit them, then you would emit note-on events. If you would not emit them, then you would not emit note-off events. Is it a problem not to emit note-off events at the end of the piece if it's going to end anyway?
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote: > > Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while > outputting, just stop where \fine was used. For the events that are simultaneous with the \fine, would you emit them or not? If you would emit them, then you would emit note-on events. If you would not emit them, then you would not emit note-off events. — Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
> For example, whether an item on the non-musical column at the point of \fine
> is included depends on whether its break-visibility makes it visible at EOL.
> The fine text itself will thus be included, while a rehearsal mark won’t.
> That is just as expected.
Not exactly.
```
void
Mark_engraver::finalize ()
{
if (final_text_)
{
// A mark created at the very end is always visible even if it would not
// be visible at the end of a broken line.
set_property (final_text_, "break-visibility",
scm_c_make_vector (3, SCM_BOOL_T));
}
final_text_ = nullptr;
}
```
—
Dan
Re: Does scripts/auxilar/make-regtest-pngs.sh function properly?
On Sat, Jul 9, 2022 at 6:34 AM John Wheeler wrote: > I am trying to get the process documented in CG: 9.5 "Pixel-base regtest > comparison" to run. But, I am not able to get the command > > ./make-regtest-pngs.sh -j4 -o Why are you trying to run this script? David is adamant this script can't be removed (I disagree with him) because it caters for a very specific type of validation. What are you trying to validate? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Does scripts/auxilar/make-regtest-pngs.sh function properly?
John Wheeler writes: > I am trying to get the process documented in CG: 9.5 "Pixel-base > regtest comparison" to run. But, I am not able to get the command > > ./make-regtest-pngs.sh -j4 -o > > to run without error. Using git bisect points to commit > c85e9950a70d1765e4b9a637a737d873975dfb59, "Framework-ps: rewrite > system clipping to be output format-agnostic" as the point at which it > started failing. > > On the other hand, If I have a successfully generated > 'old-regtest-results', > > ./make-regtest-pngs.sh -j4 -n > > will happily run well past that commit. > > I see a lot of discussion on !1272 saying the script should be kept, > which seems to imply that the script should works. > > Is this a known issue? Rereading the script, it would seem like it has a problem if you run it with -o and have the shell variable do_compare set and to a value other than "" before doing so. Does it help to put do_compare="" at the top of the script? -- David Kastrup
Re: Does scripts/auxilar/make-regtest-pngs.sh function properly?
John Wheeler writes: > I am trying to get the process documented in CG: 9.5 "Pixel-base > regtest comparison" to run. But, I am not able to get the command > > ./make-regtest-pngs.sh -j4 -o > > to run without error. Using git bisect points to commit > c85e9950a70d1765e4b9a637a737d873975dfb59, "Framework-ps: rewrite > system clipping to be output format-agnostic" as the point at which it > started failing. > > On the other hand, If I have a successfully generated > 'old-regtest-results', > > ./make-regtest-pngs.sh -j4 -n > > will happily run well past that commit. > > I see a lot of discussion on !1272 saying the script should be kept, > which seems to imply that the script should works. > > Is this a known issue? Likely not. Kind of unusual error conditions. Looking at that commit, it would seem more likely that this commit needs fixing rather than the scripts since they don't seem related at all and the script does not seem to rely on any strange semantics. However, it seems decidedly weird to be running ./make-regtest-pngs.sh instead of, say, scripts/auxiliar/make-regtests-pngs.sh here: it may just be that you are running the script in a directory completely unsuitable for it. I'll take a look at the instructions. -- David Kastrup
