Re: "natural width" of a measure

[Peter Crighton]

2017-04-11 22:34 GMT+02:00 David Nalesnik :

> Here's how you can determine the widths of measures.  Note that I've
> put everything on one line, so that the \once \override of the
> NoteHead gives access to every column in the score.  You can adjust
> what alignment objects are used to gauge width by changing the symbol
> in ly:paper-column::break-align-width (available as of 2.19.59).
> Right now, it's BreakAlignment objects to give you an extent
> considering all prefatory materials.  staff-bar would give extents of
> the bar lines.
>
> \version "2.19.59"
>
> \paper {
>   page-breaking = #ly:one-line-breaking
> }
>
> #(define (display-measure-widths grob)
>(let* ((sys (ly:grob-system grob))
>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>   (nmpcs
>(filter
> (lambda (elt)
>   (and (grob::has-interface elt 'paper-column-interface)
>(eq? #t (ly:grob-property elt 'non-musical
> cols))
>   (widths
>(map
> (lambda (c) (ly:paper-column::break-align-width c
> '(break-alignment)))
> nmpcs))
>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>   )
>  (pretty-print widths)))
> {
>
>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>   \repeat unfold 4 { c''8. c''16}
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> Hope this helps with something!
>
> David


Hello David et al.,

it surely has the potential of helping me with my current project. My
Scheme skills are still quite rudimentary, though, so I’m stuck for now.
Below you can find a stripped-down version of my chord chart template. I
need to offset all the notes and chords, apart from the first in a bar, to
the left; the exact offset values I want to calculate based on the length
of a measure. In the end, the distances between the notes should be the
same as the distance from the last note of a measure to the next bar line.
I think if I know the length of a measure and the position of each note, I
can work out a formula for that.

So, my questions are:
How can I display the positions (or extents) of notes, similar to what you
did with the extents of bar lines?
How can I access the x and y values of your function outside of that
function?
Both seem to me not that difficult, but I couldn’t find the solution for
now …


\version "2.19.47"

#(define (display-measure-widths grob)
   (let* ((sys (ly:grob-system grob))
  (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
  (nmpcs
   (filter
(lambda (elt)
  (and (grob::has-interface elt 'paper-column-interface)
   (eq? #t (ly:grob-property elt 'non-musical
cols))
  (widths
   (map
(lambda (c) (ly:generic-bound-extent c sys))
nmpcs))
  (widths (sort widths (lambda (x y) (< (car x) (car y)
  )
 (pretty-print widths)))

<<
  \new Voice {
\once \override NoteHead.after-line-breaking = #display-measure-widths
\repeat unfold 4 {
  4 4 4 4
}
  }

  \new ChordNames \chordmode {
\repeat unfold 4 {
  c2 c
}
  }
>>

\layout {
  \context {
\ChordNames
\consists "Bar_engraver"
\consists "Time_signature_engraver"
\numericTimeSignature

\override ChordName.Y-extent = ##f
\override ChordName.Y-offset = #-0.9
\override ChordName.X-offset = #1

\override BarLine.bar-extent = #'(-2 . 2)
  }

  \context {
\Staff
\remove "Time_signature_engraver"

\override Clef.stencil = #point-stencil
\hide BarLine
\override StaffSymbol.line-count = #0

\override NoteColumn.X-offset = #1
  }

  \context {
\Voice
\consists "Pitch_squash_engraver"
\improvisationOn
\stemUp
fontSize = #-4
  }

  \context {
\Score
\override BarNumber.stencil = #point-stencil

\override Clef.space-alist.first-note = #'(fixed-space . 0)
\override Clef.space-alist.time-signature = #'(extra-space . -2)

proportionalNotationDuration = #(ly:make-moment 1/2)
\override SpacingSpanner.uniform-stretching = ##t
\override SpacingSpanner.strict-note-spacing = ##t

\override NonMusicalPaperColumn.padding = #0
  }
}

\paper {
  indent = 0
  ragged-right = ##f
}


Thanks,
Peter

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

Am 14. April 2017 16:04:31 MESZ schrieb David Nalesnik 
<david.nales...@gmail.com>:
>On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote:
>>
>>
>> Am 13.04.2017 um 16:48 schrieb David Nalesnik:
>>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org>
>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 

Re: "natural width" of a measure

[David Nalesnik]

On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote:
>
>
> Am 13.04.2017 um 16:48 schrieb David Nalesnik:
>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> 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

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

Am 13.04.2017 um 16:48 schrieb David Nalesnik:
> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> 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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska  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?

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

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

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.
>
>
> Does ragged-right = ##t not do what you want (at least in terms of
> displaying the natural measure widths)?

Well, it *would*. But it would require *two* compilations, one iwth
ragged-right to determine the widths and one without ragged-right to do
the actual engraving.

So, no, thanks, but it doesn't really help.

Best
Urs

>
> Best,
> Abraham 
>
> ------------
> View this message in context: Re: "natural width" of a measure
> <http://lilypond.1069038.n5.nabble.com/natural-width-of-a-measure-tp202182p202185.html>
> Sent from the User mailing list archive
> <http://lilypond.1069038.n5.nabble.com/User-f3.html> at Nabble.com.
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

Hi David,


Am 11.04.2017 um 22:42 schrieb David Nalesnik:
> On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
> <david.nales...@gmail.com> wrote:
>> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska <u...@openlilylib.org> 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 spacing depends on the sorts of durations present -- the most
>> common duration, the shortest duration.

I think I have expressed myself poorly.
I mean that after a first full engraving I would know the natural width
of a measure (as if it were typeset ragged-right). When now something
(e.g. additional notes) forces the line breaking to be changed I can
take the - known - natural widths of the following measures and
calculate which measures would fit into the next system.

>>
>> Do you mean to typeset each measure as if it's in isolation, without
>> stretching based on surrounding measures?
>>
>> For example,
>>
>> \version "2.19.59"
>>
>> \layout { ragged-right = ##t }
>>
>> {
>>   \repeat unfold 16 { c''16 }
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }

No, I just want to know how much space a measure would need if it were
ragged-right but still have the actual engraving stretched to justified
lines.

>>
>> %%
>>
>> Alternately, you could create a \newSpacingSection every measure,
>> though this gives different values.  Don't know why.
>>
>> 
>>
>> Here's how you can determine the widths of measures.  Note that I've
>> put everything on one line, so that the \once \override of the
>> NoteHead gives access to every column in the score.  You can adjust
>> what alignment objects are used to gauge width by changing the symbol
>> in ly:paper-column::break-align-width (available as of 2.19.59).
>> Right now, it's BreakAlignment objects to give you an extent
>> considering all prefatory materials.  staff-bar would give extents of
>> the bar lines.
>>
>> \version "2.19.59"
>>
>> \paper {
>>   page-breaking = #ly:one-line-breaking
>> }
>>
>> #(define (display-measure-widths grob)
>>(let* ((sys (ly:grob-system grob))
>>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>>   (nmpcs
>>(filter
>> (lambda (elt)
>>   (and (grob::has-interface elt 'paper-column-interface)
>>(eq? #t (ly:grob-property elt 'non-musical
>> cols))
>>   (widths
>>(map
>> (lambda (c) (ly:paper-column::break-align-width c
>> '(break-alignment)))
>> nmpcs))
>>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>>   )
>>  (pretty-print widths)))
>> {
>>
>>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>>   \repeat unfold 4 { c''8. c''16}
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }
>>
>> Hope this helps with something!
>>

I'll have to look into this tomorrow. RIght now it's too late to install
another LilyPond ...

> Oh, I should have mentioned that the function is showing the extents
> of objects held by the columns organizing barlines, clefs, key
> signatures, etc --  not measure lengths.  Finding the measures will
> involve an extra fun step.

Looking forward to that ;-)

Best
Urs

>
> David

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
 wrote:
> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska  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 spacing depends on the sorts of durations present -- the most
> common duration, the shortest duration.
>
> Do you mean to typeset each measure as if it's in isolation, without
> stretching based on surrounding measures?
>
> For example,
>
> \version "2.19.59"
>
> \layout { ragged-right = ##t }
>
> {
>   \repeat unfold 16 { c''16 }
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> %%
>
> Alternately, you could create a \newSpacingSection every measure,
> though this gives different values.  Don't know why.
>
> 
>
> Here's how you can determine the widths of measures.  Note that I've
> put everything on one line, so that the \once \override of the
> NoteHead gives access to every column in the score.  You can adjust
> what alignment objects are used to gauge width by changing the symbol
> in ly:paper-column::break-align-width (available as of 2.19.59).
> Right now, it's BreakAlignment objects to give you an extent
> considering all prefatory materials.  staff-bar would give extents of
> the bar lines.
>
> \version "2.19.59"
>
> \paper {
>   page-breaking = #ly:one-line-breaking
> }
>
> #(define (display-measure-widths grob)
>(let* ((sys (ly:grob-system grob))
>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>   (nmpcs
>(filter
> (lambda (elt)
>   (and (grob::has-interface elt 'paper-column-interface)
>(eq? #t (ly:grob-property elt 'non-musical
> cols))
>   (widths
>(map
> (lambda (c) (ly:paper-column::break-align-width c
> '(break-alignment)))
> nmpcs))
>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>   )
>  (pretty-print widths)))
> {
>
>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>   \repeat unfold 4 { c''8. c''16}
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> Hope this helps with something!
>

Oh, I should have mentioned that the function is showing the extents
of objects held by the columns organizing barlines, clefs, key
signatures, etc --  not measure lengths.  Finding the measures will
involve an extra fun step.

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska  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 spacing depends on the sorts of durations present -- the most
common duration, the shortest duration.

Do you mean to typeset each measure as if it's in isolation, without
stretching based on surrounding measures?

For example,

\version "2.19.59"

\layout { ragged-right = ##t }

{
  \repeat unfold 16 { c''16 }
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

%%

Alternately, you could create a \newSpacingSection every measure,
though this gives different values.  Don't know why.



Here's how you can determine the widths of measures.  Note that I've
put everything on one line, so that the \once \override of the
NoteHead gives access to every column in the score.  You can adjust
what alignment objects are used to gauge width by changing the symbol
in ly:paper-column::break-align-width (available as of 2.19.59).
Right now, it's BreakAlignment objects to give you an extent
considering all prefatory materials.  staff-bar would give extents of
the bar lines.

\version "2.19.59"

\paper {
  page-breaking = #ly:one-line-breaking
}

#(define (display-measure-widths grob)
   (let* ((sys (ly:grob-system grob))
  (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
  (nmpcs
   (filter
(lambda (elt)
  (and (grob::has-interface elt 'paper-column-interface)
   (eq? #t (ly:grob-property elt 'non-musical
cols))
  (widths
   (map
(lambda (c) (ly:paper-column::break-align-width c
'(break-alignment)))
nmpcs))
  (widths (sort widths (lambda (x y) (< (car x) (car y)
  )
 (pretty-print widths)))
{

  \once \override NoteHead.after-line-breaking = #display-measure-widths
  \repeat unfold 4 { c''8. c''16}
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

Hope this helps with something!

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[tisimst]

On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n202184...@n5.nabble.com> 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.
>

Does ragged-right = ##t not do what you want (at least in terms of
displaying the natural measure widths)?

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/natural-width-of-a-measure-tp202182p202185.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

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.

Urs


>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[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?

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

"natural width" of a measure

[Urs Liska]

Hi,

is there any chance to retrieve the "natural width" of a measure after
typesetting but before the line is stretched to the full line width?

This is a rather long-term question, but it would be terrific if - upon
a compilation - I could retrieve a list of initial widths of each
measure. From this I hope to be able to determine how many concrete
measures fit in a line, so if for example adding some content requires
the current line to be broken earlier I could determine if the next line
would still fit or if that changed break has to continue for subsequent
systems.

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

Thanks for any opinions, info or pointers
Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user