Re: Tuplet bracket

[Malte Meyn]

Am 14.04.2017 um 06:45 schrieb Andrew Bernard:
> Hi Michiel,
> 
> Use shorten-pait to taste.
> 
>   %\once \override TupletBracket.positions = #'(3.1 . 3.4)
>   \once \override TupletBracket.shorten-pair = #'(0 . 0.5)

Shouldn’t this be #'(0.2 . 0) or similar but not #'(0 . 0.5) if you want
to shorten it at the left edge?

Alternatively, instead of shortening the tuplet bracket, you could move
the notes by inserting

\once \override Score.NoteColumn.X-offset = 0.6

(try different values) at this place.

>   \tuplet 3/2 {
> r32 \clef treble
> \once \override Slur.positions = #'(-1 . 1)
> f'^(-[ f')]
>   }
>   %\once \override TupletBracket.positions = #'(3.4 . 3.4)
>   \tuplet 3/2 { r32 r \clef bass \stemNeutral  }
> 
> Andrew

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

Re: Tuplet bracket

[Andrew Bernard]

Hi Malte,

Sure, depends which side you want to adjust of course, I am merely
indicating a possible technique.

Michiel, speaking as a player myself, your example score seems fairly
cramped and lacking what I call 'air', making it a bit hard to read. And
there is definitely something wrong with the second line - the break is in
the wrong spot. Looking at my Henle Verlag edition, they get more space on
the first line by not having so many 32's on the end. Also of possible
interest is that they use triplets with curved brackets not rectangular,
which seems to make the cramping less severe. There was discussion about
how to do these on the list fairly recently.

I am not suggesting you have to copy Henle, but it is very
readable/playable edition in my opinion.

Andrew


On 14 April 2017 at 17:55, Malte Meyn  wrote:

>
>
> Am 14.04.2017 um 06:45 schrieb Andrew Bernard:
> > Hi Michiel,
> >
> > Use shorten-pait to taste.
> >
> >   %\once \override TupletBracket.positions = #'(3.1 . 3.4)
> >   \once \override TupletBracket.shorten-pair = #'(0 . 0.5)
>
> Shouldn’t this be #'(0.2 . 0) or similar but not #'(0 . 0.5) if you want
> to shorten it at the left edge?
>
> Alternatively, instead of shortening the tuplet bracket, you could move
> the notes by inserting
>
> \once \override Score.NoteColumn.X-offset = 0.6
>
> (try different values) at this place.
>
> >   \tuplet 3/2 {
> > r32 \clef treble
> > \once \override Slur.positions = #'(-1 . 1)
> > f'^(-[ f')]
> >   }
> >   %\once \override TupletBracket.positions = #'(3.4 . 3.4)
> >   \tuplet 3/2 { r32 r \clef bass \stemNeutral  }
> >
> > Andrew
>
> ___
> 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

Re: Tuplet bracket

[Michiel Sikma]

Thanks so much to both! I ended up using X-offset, and it works like a
charm.

You're absolutely correct, Andrew. The score isn't particularly nice right
now. The break is actually my bad, I'm pretty sure I failed to copy over
something from my include files - since the bin had to be a self-contained
file. So I noticed that there was something funny going on with the break
in that version. The pedaling is also just a sketch too.

Still lots of things to do, but I'll try to make it look better. Maybe when
I'm a bit further along I'll ask for some more feedback! Henle does have
the nicest scores, so I was planning to buy their edition later to see.

Regards,
Michiel

On Fri, Apr 14, 2017 at 5:08 PM, Andrew Bernard 
wrote:

> Hi Malte,
>
> Sure, depends which side you want to adjust of course, I am merely
> indicating a possible technique.
>
> Michiel, speaking as a player myself, your example score seems fairly
> cramped and lacking what I call 'air', making it a bit hard to read. And
> there is definitely something wrong with the second line - the break is in
> the wrong spot. Looking at my Henle Verlag edition, they get more space on
> the first line by not having so many 32's on the end. Also of possible
> interest is that they use triplets with curved brackets not rectangular,
> which seems to make the cramping less severe. There was discussion about
> how to do these on the list fairly recently.
>
> I am not suggesting you have to copy Henle, but it is very
> readable/playable edition in my opinion.
>
> Andrew
>
>
> On 14 April 2017 at 17:55, Malte Meyn  wrote:
>
>>
>>
>> Am 14.04.2017 um 06:45 schrieb Andrew Bernard:
>> > Hi Michiel,
>> >
>> > Use shorten-pait to taste.
>> >
>> >   %\once \override TupletBracket.positions = #'(3.1 . 3.4)
>> >   \once \override TupletBracket.shorten-pair = #'(0 . 0.5)
>>
>> Shouldn’t this be #'(0.2 . 0) or similar but not #'(0 . 0.5) if you want
>> to shorten it at the left edge?
>>
>> Alternatively, instead of shortening the tuplet bracket, you could move
>> the notes by inserting
>>
>> \once \override Score.NoteColumn.X-offset = 0.6
>>
>> (try different values) at this place.
>>
>> >   \tuplet 3/2 {
>> > r32 \clef treble
>> > \once \override Slur.positions = #'(-1 . 1)
>> > f'^(-[ f')]
>> >   }
>> >   %\once \override TupletBracket.positions = #'(3.4 . 3.4)
>> >   \tuplet 3/2 { r32 r \clef bass \stemNeutral  }
>> >
>> > Andrew
>>
>> ___
>> 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
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond errors on a guitar minor sixth chord

[Thomas Morley]

2017-04-14 5:18 GMT+02:00 Stan Mulder :
>
> Thomas,
>
> Here's your example, but with fretboards added. The error is there. 
> Apparently it has to do with fretboards. Also, I am running 2.19.59:
>
> \version "2.19.56"
> \language "english"
> \include "predefined-guitar-fretboards.ly"
>
> m = \chordmode {
>   \override FretBoard.fret-diagram-details.dot-radius = #0.4
>   \override FretBoard.fret-diagram-details.number-type = #'arabic
>   b-flat4 bf/f g4:dim/e e-flat:m6
> }
> <<
> \new ChordNames \m
> \new FretBoards \m
> \new Staff { \accidentalStyle forget \m }
> >>
>
> Error:
[...]

Hi Stan,

please always reply to all, unless real private topics are discussed.

I now get the _warning_ myself.
So this is a good show-case about minimals. Obviously your
code-example should have pointed to FretBoards:

\version "2.19.59"

\language "english"
\include "predefined-guitar-fretboards.ly"

\new FretBoards \chordmode { e-flat:m6 }

Would have done it.


That said,

Some basics:

Lilypond creates FretBoards (without predefined-guitar-fretboards.ly)
by looking at the actual chord-pitches.
Which are < ef' gf' bf' c'' > in this case. Here LilyPond thinks it's
not doable and indeed it would be very hard to do something like:
\new FretBoards { < ef'\4-4 gf'\3-2 bf'\2-3 c''\1-1 > }

If predefined-guitar-fretboards.ly is included, LilyPond looks there
whether a fret-diagram-definition for the chord is stored there.
If found it's taken otherwise lily falls back to look at the actual
chord-pitches.

In predefined-guitar-fretboards.ly are definitions stored for all
chords of type:
major, minor, 7, m7, dim, aug, maj7, dim7, 9

Thus Lilypond does not find m6-chords, falls back to the pitches,
can't find a sensible fret-diagram, prints what's possible and finally
emitts the warning about the missing part(s).



Sollution(s):

(1)
Define it yourself, search the NR for 'storePredefinedDiagram'. Leading to:

\version "2.19.56"

\language "english"

\storePredefinedDiagram #default-fret-table \chordmode {e-flat:m6}
#guitar-tuning
#"x;x;1-1-(;3-3;1-1-);3-3;"

\include "predefined-guitar-fretboards.ly"

\new FretBoards \chordmode { e-flat:m6 }

(2)
Look at
http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00500.html
and follow the link to Philomenos
Although I have to admit I never tried it myself.

(3)
Extend predefined-guitar-fretboards.ly
That would mean to create a patch for the missing chords.

Though I'm not sure to which amount such a patch would be accepted.
Currently only the "most common" chords are stored there. Ofcourse
it's debattable which chords are "most common"...
And if we extend the file, what comes in what not?
11, 13, b5, inversions, added bass-pitches, etc etc
The Philomenos-files obviously try to cover most possible, so their
files are of huge size ...
I'd say too huge to ship them with default LilyPond.


HTH,
  Harm

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

Re: lilypond errors on a guitar minor sixth chord

[Thomas Morley]

2017-04-14 12:25 GMT+02:00 Thomas Morley :

> Sollution(s):
>
> (1)
> Define it yourself, search the NR for 'storePredefinedDiagram'. Leading to:
>
> \version "2.19.56"
>
> \language "english"
>
> \storePredefinedDiagram #default-fret-table \chordmode {e-flat:m6}
> #guitar-tuning
> #"x;x;1-1-(;3-3;1-1-);3-3;"
%% That should rather be:
#"x;x;1-1-(;3-3;1-1-);3-4;"
>
> \include "predefined-guitar-fretboards.ly"
>
> \new FretBoards \chordmode { e-flat:m6 }

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

Staff grouping

[Jérôme Plût]

Are there any other ways to tune the vertical spacing between staffs
other than the \paper block? What I want is the following: on the same
page,
 - first a score A (single-staff, no groups) with successive staffs
   extremely close together (about 2 or 3 staff lines of separation
   should be enough),
 - then another score B with successive staffs normally separated. (B
   is a StaffGroup score but that should not change anything to the
   problem).
Ideally the last A staff should also be very close to the first B
line. (In my application, B is a real score and A are blank lines for
comments etc.)

I tried putting two \paper blocks, one before A and one before B, but
it looks like the first one is then ignored. Is there any other way to
do this?

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

Re: Staff grouping

[Phil Holmes]

- Original Message - 
From: "Jérôme Plût" 

To: 
Sent: Friday, April 14, 2017 12:55 PM
Subject: Staff grouping



Are there any other ways to tune the vertical spacing between staffs
other than the \paper block? What I want is the following: on the same
page,
- first a score A (single-staff, no groups) with successive staffs
  extremely close together (about 2 or 3 staff lines of separation
  should be enough),
- then another score B with successive staffs normally separated. (B
  is a StaffGroup score but that should not change anything to the
  problem).
Ideally the last A staff should also be very close to the first B
line. (In my application, B is a real score and A are blank lines for
comments etc.)

I tried putting two \paper blocks, one before A and one before B, but
it looks like the first one is then ignored. Is there any other way to
do this?


Have a look at

http://lilypond.org/doc/v2.19/Documentation/learning/vertical-spacing

and

http://lilypond.org/doc/v2.19/Documentation/notation/flexible-vertical-spacing-within-systems

--
Phil Holmes 



___
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 Fri, Apr 14, 2017 at 1:38 AM, Urs Liska  wrote:
>
>
> Am 13.04.2017 um 16:48 schrieb 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?
>
> 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: Staff grouping

[Carl Sorensen]

On 4/14/17 5:55 AM, "Jérôme Plût"  wrote:

>Are there any other ways to tune the vertical spacing between staffs
>other than the \paper block? What I want is the following: on the same
>page,
> - first a score A (single-staff, no groups) with successive staffs
>   extremely close together (about 2 or 3 staff lines of separation
>   should be enough),
> - then another score B with successive staffs normally separated. (B
>   is a StaffGroup score but that should not change anything to the
>   problem).
>Ideally the last A staff should also be very close to the first B
>line. (In my application, B is a real score and A are blank lines for
>comments etc.)

I would not use two different scores.

I would create one score that contains all the staffs; filled in with
notes in B, and empty in A.

Instead of single staff in A, I'd have one staff in A for each staff in B.

Then each page would have as many staff lines in A as there are in B.  And
you can set the spacing between each of the staves independently. (Each
staff can have its own spacing variables).  See the link provided by Phil.

HTH,

Carl


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

Re: Multiple instruments in score and parts

[David Sumbler]

On Thu, 2017-04-13 at 14:37 +0100, David Sumbler wrote:
> On Thu, 2017-04-13 at 09:19 -0400, Kieren MacMillan wrote:
> > 
> > Hi David,
> > 
> > > 
> > > 
> > > At the moment I cannot really see how to deal with this sort of
> > > problem, other than having completely separate input for the
> > > score
> > > and
> > > the part at these points, controlled by tags.  But is there a
> > > better
> > > way - one which requires less duplication of material in the
> > > input?
> > > 
> > > Any suggestions or pointers to help with this will be gratefully
> > > received!
> > If you search for ‘divisi’ on the list — and sort in reverse
> > chronological order (which really should be the default!) — you’ll
> > find many related threads, containing lots of hints and tips on how
> > to attack this problem (e.g.,
> > ).
> > 
> > Hope this helps,
> > Kieren.
> It does - I simply hadn't thought of searching for "divisi"!  Even
> after a cursory glance at some of the stuff that that search comes up
> with, I can see that this is going to be very helpful.
> 
> Thanks
> 
> David

I have now read these threads, and in particular the one mentioned in
the quoted material above.

I downloaded and compiled the various files and I am very impressed by
what can be automated using these techniques - just the sort of thing I
was hoping for.  Thank you to those involved in developing this.

That thread is now 8 months old, and I wondered what has happened
since.  I assume that eventually some elements will be built into
LilyPond so that, for instance, the long Context definitions don't need
to be included in source files.

So where are things up to?  Is some of it yet incorporated into the
development version of LilyPond?  Is it likely to be included in the
eventual LilyPond 2.20?

What I really want to know is whether it would be worth my while
waiting a little longer before embarking on projects where these
techniques will be useful (and risking brain damage in the attempt!) -
there is no actual hurry in my case.

David

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

Re: Multiple instruments in score and parts

[Kieren MacMillan]

Hi David,

> That thread is now 8 months old, and I wondered what has happened since.

Unfortunately, not as much as one would hope…

> Is some of it yet incorporated into the development version of LilyPond?

I’d have to look more closely, but my intuition is “yes”.

> Is it likely to be included in the eventual LilyPond 2.20?

I would think so.

> What I really want to know is whether it would be worth my while
> waiting a little longer before embarking on projects where these
> techniques will be useful (and risking brain damage in the attempt!) -
> there is no actual hurry in my case.

My very next engraving project is the one which inspired many of these threads 
— and subsequent feature requests and codebase improvements — in 2012 (e.g., 
http://lists.gnu.org/archive/html/lilypond-user/2012-12/msg00425.html), and 
even before.

If you can wait, I’m going to use that project — a small choral work with lots 
of shared and divisi parts — as a test of the existing functionality, an 
inspiration for some new code and/or feature requests, and ultimately a very 
detailed tutorial on the subject.

Best,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

"Winged" repeat after double bar and line break

[Daniel Rosen]

\version "2.19.56"

\relative c'' {
  c4 c c c
  \bar "[|:"
  c4 c c c \break
  \bar ".|:-||"
  c4 c c c
}



I would like the first line in the above example to end with a double bar (\bar 
"||"), and the second line to begin with a winged begin-repeat bar (\bar 
"[|:"). How can I accomplish this?

DR

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

Re: "Winged" repeat after double bar and line break

[Thomas Morley]

2017-04-15 0:05 GMT+02:00 Daniel Rosen :
> \version "2.19.56"
>
>
>
> \relative c'' {
>
>   c4 c c c
>
>   \bar "[|:"
>
>   c4 c c c \break
>
>   \bar ".|:-||"
>
>   c4 c c c
>
> }
>
>
>
> 
>
>
>
> I would like the first line in the above example to end with a double bar
> (\bar "||"), and the second line to begin with a winged begin-repeat bar
> (\bar "[|:"). How can I accomplish this?
>
>
>
> DR

Search NR for defineBarLine, leading to:


\defineBarLine "[|:-||" #'("||" "[|:" ".|")

%% or using scheme-syntax:
%#(define-bar-line "[|:-||" "||" "[|:" ".|")

\relative c'' {
  c4 c c c
  \bar "[|:"
  c4 c c c \break
  \bar "[|:-||"
  c4 c c c
}


HTH,
  Harm

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

Re: lilypond errors on a guitar minor sixth chord

[Stan Mulder]

Thomas,

Got it. I used your first solution with the addendum. If at some point 
in the future I need more chords, I will construct a more extensive file 
for guitar chords. I did construct a fingering file for plectrum banjo a 
while back. It's got 25 chords for each of 12 keys, but I don't have any 
inversions.


Thanks for the clarification on the reply-all. I wasn't sure what to do. 
Is there some place on the web were I can see other discussions?


Stan

On 04/14/2017 06:25 AM, Thomas Morley wrote:

2017-04-14 5:18 GMT+02:00 Stan Mulder :


(1)
Define it yourself, search the NR for 'storePredefinedDiagram'. Leading to:

\version "2.19.56"

\language "english"

\storePredefinedDiagram #default-fret-table \chordmode {e-flat:m6}
 #guitar-tuning
 #"x;x;1-1-(;3-3;1-1-);3-3;"

\include "predefined-guitar-fretboards.ly"

\new FretBoards \chordmode { e-flat:m6 }



%% That should rather be:
 #"x;x;1-1-(;3-3;1-1-);3-4;"



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

Re: lilypond errors on a guitar minor sixth chord

[Malte Meyn]

Am 15.04.2017 um 02:36 schrieb Stan Mulder:
> Thanks for the clarification on the reply-all. I wasn't sure what to do.
> Is there some place on the web were I can see other discussions?

There are several archives, f. e.

http://lists.gnu.org/archive/html/lilypond-user/ (this is the mailing
lists’ own archive on gnu.org)
http://lilypond.1069038.n5.nabble.com/
http://www.mail-archive.com/lilypond-user@gnu.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]

Am 14. April 2017 16:04:31 MESZ schrieb David Nalesnik 
:
>On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska  wrote:
>>
>>
>> Am 13.04.2017 um 16:48 schrieb 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?
>>
>> 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)