lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "natural width" of a measure


From: David Nalesnik
Subject: Re: "natural width" of a measure
Date: Fri, 14 Apr 2017 09:04:31 -0500

On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <address@hidden> wrote:
>
>
> Am 13.04.2017 um 16:48 schrieb David Nalesnik:
>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <address@hidden> wrote:
>>>
>>> Am 11.04.2017 um 21:04 schrieb tisimst:
>>>
>>>
>>>
>>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>>>> So, is there any moment in the compilation process where the natural,
>>>>>> unstretched length of a measure can be calculated? It doesn't have to
>>>>>> be
>>>>>> an easily-read property and can involve calculation, but actually the x
>>>>>> position of the barlines would be an easy target - *if* there's this
>>>>>> magic moment in the compilation pipeline ;-)
>>>>> Maybe you could experiment with the ly:one-line-breaking?
>>>> I don't think so (only, of course, to investigate how much can be done
>>>> on the internal level).
>>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>>>> care at all about overall appearance or good page turns but instead
>>>> simply places as many measures in a line as fit naturally. If then a
>>>> line break changes and I know the natural width of the measures I can
>>>> determine before compilation how many measures will fit on the *next*
>>>> system.
>> But given clefs, key signatures, cautionaries, doesn't this mean that
>> you need to know the width of any measure as the first measure of the
>> line, as the last measure on a line, at a median position?
>
> Ah yes, this is true. But I guess we could do with some estimates here
> (see below).
>
>>
>> I'm not clear on the need to know how many measures will fit on
>> subsequent lines before compilation.  Is it so that you can compile by
>> system?
>>
>> (Just trying to get a handle on your goals so I can help better.)
>
> Yes, you're right. I'm not going to tackle this right now, but I have to
> think about it for writing some plans.
> I'm thinking about a "music entry mode" where I don't care at all about
> "good" line and page breaking, so music can just be engraved like Word
> "justifies" paragraphs - just fill the line and then go to the next.

Doesn't ly:minimal-breaking already do this?  It might try out
different line configurations -- I'm not entirely sure -- but looks
pretty stripped down.

>
> Given that the music is available in a measure-by-measure state and
> given that it is available in a parsed state from a LilyPond server
> (both of which I hope to achieve one day) this would mean that I can
> simply recompile the "current" system as long as the changed don't
> require a change in line breaking. Only then I'd have to recompile the
> next system as well, and then the next if the changed lines requires
> this. I could do this sequentially, so the score would also update
> incrementally without having to wait for the full compilation. But if I
> knew the natural width of each existing measure I could perform the
> calculations up front and decide which system should contain which
> measures. In that case one could even have the systems be engraved in
> parallel.
> If any of these subsequent system fails because the measures don't fit
> on it (BTW some help could be available by LilyPond's ability to squeeze
> the system a bit) the parallel engraving could be stopped and restarted
> in the incremental fashion.

OK, I understand.  This would be a great selling point..

Possibly related: have you considered the page/scroll view option from
*ahem* Finale?  (In scroll view, of course, all music is on a single
line, whereas page view presents pages roughly as they will be
engraved.)

About "natural measure widths": I'm still poking around, hoping that
you wouldn't need to run a copy of various structures through the
page/line breaking algorithms.

>
> Urs
>
> PS: Still, I haven't found the opportunity to install the latest version
> to test your suggestions.
>

Oh, I just added the latest bell-and-whistle assuming that you're
always at the forefront!  You can get the extents in other ways:

Replace

 (lambda (c) (ly:paper-column::break-align-width c '(break-alignment)))

with

(lambda (c) (ly:generic-bound-extent c sys))

or

(lambda (c) (ly:grob-extent c sys X))

HTH,
David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]