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: Urs Liska
Subject: Re: "natural width" of a measure
Date: Fri, 14 Apr 2017 08:38:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


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.

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.

Urs

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

>
> David

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org




reply via email to

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