Incremental compiling
Following one of the tangents from the “Sibelius Software UK office shuts down thread”, here’s a potential algorithm for incremental compiling. It’s only a suggestion: sorry if it’s flawed or you don’t like it! • when Lilypond is compiled, a temp file is created, containing the source file, and page-layout structure of the music. For example: Page 1 has two systems System 1 contains measures 1-4 System 2 contains measures 5-7 etc... Maybe also a database of which measure (if any) the beginning of each line of source is part of. • if Lilypond is invoked with the --incremental option, Lilypond compares its cached copy of the source file with the source file presented, and finds the first point of difference. Then it knows which measure it wants to be on the first page it’s actually publishing • then, beginning at the appropriate page, it lays out one or two pages worth of music, using simple Finale-like rules of page layout (if a measure is too wide, it goes to the next page) • if in doubt, do a full compile With large scores, compile time would be reduced to slightly more than a one- or two-page score. Watching a compile, the “interpreting music” stage is very quick compared to “preprocessing graphic elements” and layout optimization, and the extra work would incur little overhead (and could be done after the PDF file is produced). Vaughan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Incremental compiling
Vaughan McAlley vaug...@mcalley.net.au writes: Following one of the tangents from the “Sibelius Software UK office shuts down thread”, here’s a potential algorithm for incremental compiling. It’s only a suggestion: sorry if it’s flawed or you don’t like it! • when Lilypond is compiled, a temp file is created, containing the source file, and page-layout structure of the music. For example: Page 1 has two systems System 1 contains measures 1-4 System 2 contains measures 5-7 etc... Maybe also a database of which measure (if any) the beginning of each line of source is part of. • if Lilypond is invoked with the --incremental option, Lilypond compares its cached copy of the source file with the source file presented, and finds the first point of difference. Then it knows which measure it wants to be on the first page it’s actually publishing No, it doesn't. As opposed to TeX which makes its _vertical_ break decisions sequentially and independently, LilyPond uses global optimization. One can still save the local decision tree, but it may take a number of pages before it locally collapses to a single choice. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Incremental compiling
Another idea (based on sth so wrote earlier): What I'm doing all of the time (when working on longer pieces) is messing around with \set Score.skipTypesetting I set it - to ##t at the beginning of the piece - to ##f a few measures before the point where I'm working on and - to ##t again a few measures after the point (for this I usually just place a skip after the 'insert' point) An editor could try to figure out the point where on just inserts music, do something similar to compile just a short section of the piece (maybe together with a -dpreview option) and show this snippet in a preview window. Of course I'm aware of the fact that this isn't as trivial as it may sound: If the editor shouldn't be required to parse the whole piece it has to rely on some user provided information in the source file (e.g. barNumberChecks, bar checks or special comments). It may be complex to determine the correct point if we are using variables and changing time signatures etc. Maybe one could start with something as simple as: - find the cursor - go up in the source until you find m bar checks - insert \set Score.skipTypesetting = ##f there (this should be transparent to the user: either use some form of stream to pass to lilypond or write a temporary file) - go back to the cursor and look downwards in the score - if you find n bar checks then insert \set Score.skipTypesetting = ##t there (if you don't find them we assume we're already at the end of the music input) Mmaybe it's something to think about. Best Urs Am 09.08.2012 09:26, schrieb Vaughan McAlley: Following one of the tangents from the “Sibelius Software UK office shuts down thread”, here’s a potential algorithm for incremental compiling. It’s only a suggestion: sorry if it’s flawed or you don’t like it! • when Lilypond is compiled, a temp file is created, containing the source file, and page-layout structure of the music. For example: Page 1 has two systems System 1 contains measures 1-4 System 2 contains measures 5-7 etc... Maybe also a database of which measure (if any) the beginning of each line of source is part of. • if Lilypond is invoked with the --incremental option, Lilypond compares its cached copy of the source file with the source file presented, and finds the first point of difference. Then it knows which measure it wants to be on the first page it’s actually publishing • then, beginning at the appropriate page, it lays out one or two pages worth of music, using simple Finale-like rules of page layout (if a measure is too wide, it goes to the next page) • if in doubt, do a full compile With large scores, compile time would be reduced to slightly more than a one- or two-page score. Watching a compile, the “interpreting music” stage is very quick compared to “preprocessing graphic elements” and layout optimization, and the extra work would incur little overhead (and could be done after the PDF file is produced). Vaughan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
vertical aligning afterGrace notes on multiple staves
Dear all,
I'm trying to code a score of mine in which the end point of a glissando
is notated with a grace note - see the attached EXAMPLE no. 1. This is
become a quite common notation in contemporary music, and it would be
great to find a solution for it.
The \afterGrace (Lilypond )command seems to me a good starting point.
But since the end point must be so close as possible to the next note or
rest or bar line, one needs to change the position of the grace note
defining the afterGraceFraction. So far so good.
%% CODE FOR EXAMPLE No. 1 %%
\version 2.14.2
\include english.ly
\score {
\new Staff {
\set Score.proportionalNotationDuration =
#(ly:make-moment 1 16)
\override Glissando #'thickness = #2.5
#(define afterGraceFraction (cons 15 16)) r2
\afterGrace d''2 \glissando a'8 }
\layout {}
}
%% %% %% %%
If different glissandi recur on two or more staves, it is necessary to
vertical align the end points. If the relation between the duration
of two (or more) glissandi is multiple of two, it is still possible to
vertical align the glissando endpoints adapting the afterGraceFraction.
%% CODE FOR EXAMPLE No. 2 %%
\new Staff {
\set Score.proportionalNotationDuration =
#(ly:make-moment 1 16)
\override Glissando #'thickness = #2.5
#(define afterGraceFraction (cons 15 16))
r2 r4 \afterGrace d''4 \glissando a'8
}
\new Staff {
\override Glissando #'thickness = #2.5
#(define afterGraceFraction (cons 31 32))
r2 \afterGrace a'2 \glissando e'8
}
%% %% %% %%
But if one Staff has a TUPLET, I cannot find a way to vertical align
with precision:
%% CODE FOR EXAMPLE No. 3 %%
\new Staff {
\set Score.proportionalNotationDuration =
#(ly:make-moment 1 16)
\override Glissando #'thickness = #2.5
#(define afterGraceFraction (cons 3 4))
r2
\times 2/3 {
r4 \afterGrace d''2 \glissando a'8
}
}
\new Staff {
\override Glissando #'thickness = #2.5
#(define afterGraceFraction (cons 5 6))
r2 \afterGrace a'2 \glissando e'8
}
%% %% %% %%
Sorry for my very verbose and long email, I thought it could be better
to provide all the steps I followed to come to the last point.
Thank in advance for any suggestions, and thank every developer for
this WONDERFUL SOFTWARE! Before becoming composer, I worked long time
as (handwriting) copyist for a well known publisher where I developed
an extreme sensibility for score cleanness and beauty.
Even if I consider myself a beginner, only Lilypond gives me again the
sensation to work with music notation as I did when I made handwritten
partitions. I cannot dedicate so much time to learn the programm
faster, but I hope I can give back to the community what I got in the
last couple of years, when I will feel more advanced.
Regards,
TG
attachment: 1_glissandoToAfterGrace-oneStaff.pngattachment: 2_glissandoToAfterGrace-multipleStaves.pngattachment: 3_glissandoToAfterGrace-multipleStaves-tuplets.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Incremental compiling
On Thu, Aug 9, 2012 at 5:26 PM, Vaughan McAlley vaug...@mcalley.net.auwrote: Following one of the tangents from the “Sibelius Software UK office shuts down thread”, here’s a potential algorithm for incremental compiling. It’s only a suggestion: sorry if it’s flawed or you don’t like it! The new ly:one-line-breaking page-breaking algorithm (in 2.15) basically skips the whole computationally intensive part of line and page breaking. Before getting too excited about aux files, you might like to try timing your scores with ly:one-line-breaking; it will give you some idea of how big the maximum possible speed-up would be. Cheers, Joe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Incremental compiling
On 09/08/12 08:35, David Kastrup wrote: No, it doesn't. As opposed to TeX which makes its _vertical_ break decisions sequentially and independently, LilyPond uses global optimization. One can still save the local decision tree, but it may take a number of pages before it locally collapses to a single choice. Vaughan was suggesting what _could be done_ rather than what _is_ done. Does Lilypond currently do _any_ separation of the work into different jobs? I ask because it seems likely that anywhere there's a known page break, you can carry out the engraving independently. So e.g. if I have a 3-movement work and it's set that each movement will start on a new page, Lilypond could in principle engrave each of those movements in a separate job. That could be in a separate thread, or Lilypond could just do each movement sequentially -- the point is that optimizing the layout for each movement does not need to depend on the others. Currently I could do that manually by having each movement as a separate LP project and building them separately, but it could be useful to have Lilypond detect those opportunities automatically. Regarding global optimization, this sounds like it might become unmanageable for scores more than a certain size. How does memory usage scale with work size (roughly)? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Incremental compiling
Joe Neeman joenee...@gmail.com writes: On Thu, Aug 9, 2012 at 5:26 PM, Vaughan McAlley vaug...@mcalley.net.au wrote: Following one of the tangents from the “Sibelius Software UK office shuts down thread”, here’s a potential algorithm for incremental compiling. It’s only a suggestion: sorry if it’s flawed or you don’t like it! The new ly:one-line-breaking page-breaking algorithm (in 2.15) basically skips the whole computationally intensive part of line and page breaking. Before getting too excited about aux files, you might like to try timing your scores with ly:one-line-breaking; it will give you some idea of how big the maximum possible speed-up would be. I think people are more worried about the latency of partial compilations than savings for complete compilations. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Import - convert
Will this software import MidiSoft Desktop Sheetmusic files? .mmm or Finale? Thanks, Jeff ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
