Re: "natural width" of a measure

[Urs Liska]

Am 14. April 2017 16:04:31 MESZ schrieb David Nalesnik <address@hidden>:
>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.

I'll have a look into that, but it's of course only half of the equation.

>
>>
>> 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.)

That was the first I used as notation interface, back with Finale 2001.
That would be an option as well, with just one system in the window. For a main 
interface I think thus provides too little context to know where you are. But 
what I *did* think about is a kind of instant preview widget jusg showing, say, 
the current "cursor" +/- one measure.

>
>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! 

As I'm currently starving on an OS without Guile 1 I can't run self-compiled 
Lilys. And with the binary releases I've never been that quick to update.

Urs


> 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