Le 19/10/2020 à 22:44, Martín Rincón Botero a écrit :
Hello Jean,
thank you for your answer. It’s not a critical thing, but since I
moved all my workflow to Python to be able to use its automating
capabilities for producing Lilypond files, today I started using OLL’s
partial compilation together with a couple of subprocesses that are
run at the end of the Python file (the ones that actually write my
Lilypond file), so that with the help of partial compilation and a pdf
utility, it produces a separate partially compiled pdf of only one
page (the page I’m working on), then the script merges that
headerless, indentless pdf with a “memory pdf” (say, the first page),
so that I can see a single merged pdf with all the music at all times,
and I only need to compile one page at a time: whenever I need a new
page I just tell the partial compilation the measure the next page
begins with and write the page number I want compiled. This pdf
“grows” out of compiling page by page. This has exponentially
increased the efficiency of my workflow, since Lilypond’s compilation
times get only larger with more information, whereas compiling only
one page gets done quickly. Certainly this pdf is not gonna be the
final pdf. When I’m finished, I’ll run a full compilation. But it
seems to me that to get things done quickly, the actual Lilypond
command should only be used as a sort of “refresh all layout” command.
This approach works very well, except for unexisting page numbers
(basically unimportant for a temporary pdf, although from a user
perspective you might wonder why partial compilation doesn’t just put
the page number I manually gave it...), and a tempo and time signature
marking at the beginning of every page. It’s not the end of the world,
because this is not a final pdf, but it would be nice if I didn’t have
those markings at all (to be honest, I don’t like them either when
using “plain” showLastLength et al. without my Python pipeline, and
can’t see any reason why they show by default anyways unless the first
measure shown has an explicit tempo or time signature change).
Other than my way of working with Python, I can see this method as
having potential for a sort of page by page compilation mode in
Frescobaldi, but that would need said Lilypond commands to not give
extra information to the user unless explicitely told to do so.
Hello,
This is an interesting workflow; I'll have to think of it.
As mentioned before, you could use the header from this example:
\version "2.23.0"
\paper {
print-first-page-number = ##t
}
\layout {
\context {
\Staff
\remove Time_signature_engraver
}
\context {
\Score
\remove Metronome_mark_engraver
}
}
{
\tempo "Vivace"
\time 3/4
\key cis \major
c'2.\break
c'2.
}
I'd just comment out the header block, reintroducing it later when the
work is done.
Best,
Jean
PS: There is also a trick to speed up compilation for large scores:
\paper {
page-breaking = #ly:minimal-breaking
}
www.martinrinconbotero.com
On 19. Oct 2020, 22:11 +0200, Jean Abou Samra <[email protected]>, wrote:
Le 19/10/2020 à 17:32, Martín Rincón Botero a écrit :
Hello,
I wanted to ask if there's a way to prevent
showLastLength/Score.skipTypesetting from showing tempo and time
signature (and header information if possible).
Regards,
Martín.
Hi,
I don't know an obvious way to do this, though you could
remove the appropriate engravers. The question is, why do you
want this? showLastLength and Score.skipTypesetting
are for faster development, so you usually don't much care
about the look of the output. This sounds like there could
be better tools to achieve your objectives.
Best,
Jean
