Ties across variables

[James Harkins]

I've run into this limitation a few times -- enough that it's now
worth asking about.

~~
notesA = \relative c'' { c d e f ~ }
notesB = \relative c'' { f e d c }
\new Staff { \notesA \notesB }
~~

This doesn't render the tie. I'm sure there's a good reason why the
tie can't carry over from one variable into an immediately following
variable, but it's not always easy to work around.

Case in point: I want to use a \cadenzaToMusic function (received from
this list, thanks!) to avoid bar check problems after a cadenza
passage. This requires the cadenza material, and only the cadenza
material, to exist in its own separate variable. But the first note of
the cadenza is tied from the previous bar. If I put that first note in
the cadenza variable, I get no tie. If I put it in the variable with
the preceding music, it complicates synchronizing with other staves.

The best workaround I can imagine is to end the preceding variable
with a hidden note that allows the tie to render, and overlap that
with the cadenza variable. That's somewhat shy of elegance.

Example pasted below.

Is it possible to avoid the multi-voice workaround and still get the tie?

Thanks,
hjh


\version "2.16.1"

cadenzaToMusic =
#(define-music-function (parser location cadenzaMusic music)
  (ly:music? ly:music?)
"Adjust the length of `music and the measureLength, to fit the length of
`cadenzaMusic"
(let* ((clen (ly:music-length cadenzaMusic))
   (mlen (ly:music-length music))
   (factor (ly:moment-div clen mlen))
   (compressed (ly:music-compress music factor)))
  ;; (format #t "factor : ~a\n" factor)
  #{
\set Timing.measureLength = $clen
$compressed
\unset Timing.measureLength
  #}))

preVar = \relative c'' { c4 d e f ~ }
cadenzaVar = \relative c'' { f e d e f g a }
postVar = \relative c'' { c2 e4. d8 c1 }

\markup { "missing tie" }

\score {
  <<
\new Staff {
  \preVar
  \cadenzaOn
  \cadenzaVar
  \cadenzaOff
  \bar "|"
  \postVar
}
\new Staff \relative c {
  \clef bass
  c2 a2
  \cadenzaToMusic \cadenzaVar { g1\fermata }
  r2 g2 c1
}
  >>
}

\markup { "plausible, but inelegant, workaround" }

preVarWorkaround = \relative c'' { c4 d e f ~ \hideNotes f4 \unHideNotes }

\score {
  <<
\new Staff {
  <<
\new Voice { \oneVoice \preVarWorkaround }
\new Voice {
  s1 \oneVoice
  \cadenzaOn
  \cadenzaVar
  \cadenzaOff
}
  >>
  \bar "|"
  \postVar
}
\new Staff \relative c {
  \clef bass
  c2 a2
  \cadenzaToMusic \cadenzaVar { g1\fermata }
  r2 g2 c1
}
  >>
}

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

Re: Ties across variables

[Eluze]

James Harkins-2 wrote
> I've run into this limitation a few times -- enough that it's now
> worth asking about.
> 
> ~~
> notesA = \relative c'' { c d e f ~ }
> notesB = \relative c'' { f e d c }
> \new Staff { \notesA \notesB }
> ~~
> 
> This doesn't render the tie. I'm sure there's a good reason why the
> tie can't carry over from one variable into an immediately following
> variable, but it's not always easy to work around.

just put them in a single voice:

\new Staff \new Voice {\notesA \notesB }

hth
Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Ties-across-variables-tp143252p143253.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: ANN: Frescobaldi 2.0.9

[luis jure]

on 2013-03-23 at 07:24 Wilbert Berendsen wrote:

> Hi all,
> 
> Frescobaldi 2.0.9 has been released in the wild.

yay! right in time for my project... i was virtually waiting by the
computer for this new release, since i was badly hit by the problem with
PyQt-4.9.6. i can confirm that 2.0.9 compiled without problem here on
gentoo linux, and seems to be running fine with sip-4.14.3/PyQt-4.9.6. all
the new features and improvements are also welcome, of course.

thank you very much for this great software and the timely release.

best,

lj

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

Re: barline at end of staff

[Arno Rog]

Arno Rog  gmail.com> writes:

> 
Below a MWE of what I am trying to achieve (mind the wordwrap)
I hope someone has a solution to automatically place it at the end
of the staff, irrespective of the width of the staff.

I'd like to have the last barline exactly at the end of the last staff 
without having to trial and error with the extra offset paramater.

voice =  \relative c' {
  \clef violin
  \key g \major
  \time 4/4
  g' g a a \bar "|" b b c2   \bar "" \break
  b4 g a fis \bar "|" g2 fis2 \bar "|" g1
  \override Staff.BarLine #'extra-offset = #'(30 . 0)
  \bar "|."
}


\score {
  \context Score <<
\context Staff <<
  \override Staff.StaffSymbol #'width = #'80
  \override Staff.TimeSignature #'space-alist #'first-note =
 #'(extra-space . 9.5)
  \override Staff.KeySignature #'space-alist #'staff-bar =
 #'(extra-space . 12)

  \new Voice =  "voice" \voice
>>
  >>
  \layout {
indent = 0.0\mm
ragged-right = ##t
  }
}






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

Re: barline at end of staff

[David Nalesnik]

Hi Arno,

On Sat, Mar 23, 2013 at 8:59 AM, Arno Rog  wrote:

> Arno Rog  gmail.com> writes:
>
> >
> Below a MWE of what I am trying to achieve (mind the wordwrap)
> I hope someone has a solution to automatically place it at the end
> of the staff, irrespective of the width of the staff.
>
> I'd like to have the last barline exactly at the end of the last staff
> without having to trial and error with the extra offset paramater.
>

The following override still uses 'extra-offset, but the values are set
automatically:

 \override Staff.BarLine #'extra-offset = #(lambda (grob)
(let* ((refp (ly:grob-system grob))
   (blot (ly:output-def-lookup (ly:grob-layout grob)
'blot-diameter))
   (staff (ly:grob-object grob 'staff-symbol))
   (staff-X (ly:grob-extent staff staff X))
   (bar-extent-X (ly:grob-extent grob grob X))
   (current-X (ly:grob-relative-coordinate grob refp X)))
  (cons (- (cdr staff-X) current-X (interval-length bar-extent-X) (-
blot))
0)))

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

Re: how offsets and alignment works: an explanation

[Phil Holmes]

- Original Message - 
From: "Janek Warchoł" 

To: "LilyPond Users" 
Sent: Saturday, March 23, 2013 2:05 PM
Subject: how offsets and alignment works: an explanation



Hi,

here's an explanation of what's happening when we're using XY-offset,
self-alignment etc.  I hope that it'll help users get a better
understanding of LilyPond internals; i also think it would be a good
material for documentation, but i'm not sure where should it be placed
- it seems to fit both in Learning as well as Extending, and maybe
even CG...


[snip]

I think this is useful material.  I would put it in the CG: a new section in 
Programming work: Tutorial on grob alignment.  If you do this and are 
certain make doc runs without a problem, then pushing directly to staging 
would be OK as far as I'm concerned.  There are a few nitpicks with the 
English, but it would be just as easy for a native English speaker to fix 
those once it's in the CG as it would to go through review.


--
Phil Holmes 



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

Re: barline at end of staff

[Arno Rog]

Hi David,

It sure does!!
With Lilypond 2.16.1 it is almost(!) at the outer right side of the staff,
there is still a little bit of staff visible after the final barline.

Please ignore my ignorance but can I add a value 0.5 or 1.0 somewhere in
your code to nudge it a little to the right?




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

Re: how offsets and alignment works: an explanation

[Marc Hohl]

Am 23.03.2013 16:07, schrieb Phil Holmes:

- Original Message - From: "Janek Warchoł"

To: "LilyPond Users" 
Sent: Saturday, March 23, 2013 2:05 PM
Subject: how offsets and alignment works: an explanation



Hi,

here's an explanation of what's happening when we're using XY-offset,
self-alignment etc.  I hope that it'll help users get a better
understanding of LilyPond internals; i also think it would be a good
material for documentation, but i'm not sure where should it be placed
- it seems to fit both in Learning as well as Extending, and maybe
even CG...


[snip]

I think this is useful material.


+1

I would put it in the CG: a new section in Programming work: Tutorial on grob 
alignment.


+1


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

Re: how offsets and alignment works: an explanation

[Noeck]

> here's an explanation of what's happening when we're using XY-offset,
> self-alignment etc.  I hope that it'll help users get a better
> understanding of LilyPond internals; i also think it would be a good
> material for documentation, 

Hi Janek,

I loved to read this long mail. I would like to see the first half of it
in the notation reference. Things like the reference point, X- and
Y-offsets and X- and Y-extents should be explained, because users need
this knowledge for any shifts.

As far as I can see this is not explained in the NR, but this section
the user is expected to know it already:
http://lilypond.org/doc/v2.16/Documentation/notation/aligning-objects

I would be interested in the reference point for various additional
objects, e.g. dynamics, as an extension to your "repoint example.png". I
did not know for example, that it is on the left for note heads.

Scheme functions like ly:self-alignment-interface::x-aligned-on-self, I
would consider for the extension manual.

Thanks a lot for this!
Joram

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

Re: barline at end of staff

[David Nalesnik]

Hi Arno,

On Sat, Mar 23, 2013 at 10:29 AM, Arno Rog  wrote:

> Hi David,
>
> It sure does!!
> With Lilypond 2.16.1 it is almost(!) at the outer right side of the staff,
> there is still a little bit of staff visible after the final barline.
>

I just tried this with 2.16.1, and there is quite a noticeable difference
in alignments.  (I was using 2.17.14 when I wrote the snippet.)

>
> Please ignore my ignorance but can I add a value 0.5 or 1.0 somewhere in
> your code to nudge it a little to the right?


You could do this, but this would be covering over a problem with the
function itself.  This rewrite seems to produce good alignment with 2.16.1:

\override Staff.BarLine #'extra-offset = #(lambda (grob)
(let* ((refp (ly:grob-system grob))
   (staff (ly:grob-object grob 'staff-symbol))
   (staff-extent-X (ly:grob-extent staff refp X))
   (bar-extent-X (ly:grob-extent grob refp X))
   (blot (ly:output-def-lookup (ly:grob-layout grob)
'blot-diameter)))
  (cons (- (cdr staff-extent-X) (cdr bar-extent-X) (* -0.5 blot))
0)))

This works with the ending barline you want to use, but if you try it with
an ordinary barline, you'll see the bar very slightly to the left of where
it ought to be.  I will drive myself nuts trying to figure out the right
combination of blot-diameter, etc., so I'll leave it with this.  If anyone
reading this knows the right calculations to generalize this, please let me
know!

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

Re: barline at end of staff

[Wilbert Berendsen]

Op 16-03-13 17:35, Arno Rog schreef:

L.S.

I'm trying to figure out a way to place the last bar line exactly at the end of
the staff in the score of the Dutch anthem at 
http://lsr.dsi.unimi.it/LSR/Snippet?
id=648

Now it's done manually: \override Staff.BarLine #'extra-offset = #'(23 . 0)
\bar "|."
Can this be automatically (and correctly)?

Arno Rog


I used to use alignGrob for this. (See the LSR). But later I wrote this 
based on that:


endbar = {
  \overrideProperty #"Staff.BarLine" #'after-line-breaking
  #(lambda (grob)
 (let* ((sys (ly:grob-system grob))
(staff (ly:grob-object grob 'staff-symbol))
(half-thickness (/ (ly:staff-symbol-line-thickness staff) 2))
(cur-x (cdr (ly:grob-extent grob sys X)))
(new-x (cdr (ly:grob-extent staff sys X)))
(xoff (+ half-thickness (- new-x cur-x
 (ly:grob-set-property! grob 'extra-offset (cons xoff 0
}

--
Wilbert Berendsen
http://www.wilbertberendsen.nl/


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

Frescobaldi installation on Mac OS X (was: Re: Frescobaldi install)

[Wilbert Berendsen]

There is a recent, confirmed PyQt4 bug that caused very large delays in 
Frescobaldi, but 2.0.9 will run fine regardless, even with PyQt-4.9.6 or 
4.10, allbeit slightly slower.


I'd very happy if someone with an Apple machine could create a good, 
easily installable Frescobaldi package (maybe with included Qt4 and 
popplerqt4 like the Windows installer, or with clear instructions about 
how to get the dependencies), I'll put it on the download page.


Wilbert

--
Wilbert Berendsen
http://www.wilbertberendsen.nl/


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

Re: how offsets and alignment works: an explanation

[Trevor Daniels]

Hi Janek

This is explained very concisely and without examples in the NR, see
http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects

For a reference manual I think is is adequate, especially given the length 
of the NR already.

So the best place for this is probably the CG, as Phil suggests, with links
into it from the NR.

Trevor
 
- Original Message - 
From: "Janek Warchoł" 
To: "LilyPond Users" 
Sent: Saturday, March 23, 2013 2:05 PM
Subject: how offsets and alignment works: an explanation


> Hi,
> 
> here's an explanation of what's happening when we're using XY-offset,
> self-alignment etc.  I hope that it'll help users get a better
> understanding of LilyPond internals; i also think it would be a good
> material for documentation, but i'm not sure where should it be placed
> - it seems to fit both in Learning as well as Extending, and maybe
> even CG...
> 
> Let's start at the very beginning:
> LilyPond needs to know where each and every grob should be placed.
> This placement information is stored using relative coordinates:
> position of a grob is defined relative to the position of its parent
> (if we had used absolute coordinates - e.g. distances from the edges
> of the page - it would be hard to maintain spatial relationships
> between grobs).
> 
> Every grob knows which grob is its parent in respective axis.  For
> example, a Flag knows that its X-parent is a particular Stem.
> 
> Relative coordinates that describe grob's placement are stored in grob
> properties called X-offset and Y-offset.  They are measured in
> staffspaces.  X-offset is the horizontal displacement between grob's
> reference point and the reference point of grob's X-parent (similarly
> with Y-offset).
> 
> What is a reference point?  It's a special point that defines the
> grob's position.  Think about geometry: if you have to define where a
> figure is placed on a plane, you'll usually say something like "the
> lower left corner of this square has coordinates (0, 2)" "or "the
> center of this circle is at (-1, 3)". "Lower left corner" and "center"
> would be the reference points for square and circle.
> 
> This illustration shows where refpoints of particular grobs are located:
> 
> {
>  \override NoteHead #'style = #'altdefault
>  g'2-> c''\fermata | as'1^"Yogi" |
>  b'\breve _"Larry" | \mark "Twinkle" e''8 s4.
> }
> -> see attached "refpoint examples.png"
> 
> By overriding X-offset value, we can move grobs relative to their parents:
> 
> {
>  \override NoteHead #'style = #'altdefault
>  \override Script #'X-offset = #2
>  \override TextScript #'X-offset = #1.5
>  \override Stem #'X-offset = #2
>  \override Score.RehearsalMark #'X-offset = #-2
>  g'2-> c''\fermata | as'1^"Yogi" |
>  b'\breve _"Larry" | \mark "Twinkle" e''8 s4.
> }
> -> see attached "offsets.png"
> 
> (notice that the Flag moved together with its Stem)
> 
> Now, let's explain another pair of properties: X-extent and Y-extent.
> Each of them is a pair of numbers (an Interval), and they store grob's
> dimensions relative to its reference point.  For example X-extent
> equal to (-1 . 4) means that the left edge of the grob is 1 staffspace
> to the left of its reference point, and right edge is 4 staffspace to
> the right from reference point, for a total width of 4 - (-1) = 4 + 1
> = 5 staffspaces.
> Both numbers in an extent may be positive, for example (2 . 3) is a
> valid extent: it means that the whole grob is on the right of its
> refpoint, and the width of the grob is 3 - 2 = 1 staffspace.
> Similarly, both numbers can be negative; these situations are quite
> unusual but won't give LilyPond headaches.
> The most common situation (at least for X-extent) is that the first
> number is 0, which means that the reference point is on the left edge
> of the grob.
> 
> Now, suppose that we want to position a RehearsalMark so that its
> right edge is aligned with a Barline.  With X-offset = 0 (i.e. its
> reference point aligned on parent, which is equal to Barline in this
> situation) RehearsalMark would be placed like this:
> 
> {
>  \override Score.RehearsalMark #'X-offset = #0
>  b4 b b b \mark "Twinkle" b b b b
> }
> -> see image (1) in attached "images.png"
> 
> So, we need to shift it.  Remember what the second number in X-extent
> means?  It's the position of grob's right edge relative to its
> refpoint.  If we subtract this value from 0, we'll get the X-offset we
> want:
> 
> {
>  \override Score.RehearsalMark #'X-offset = #-10.4
>  b4 b b b \mark "Twinkle" b b b b
> }
> (2)
> 
> What if we wanted to center some grob on the refpoint on its parent?
> That's simple: calculate the displacement between grob's refpoint and
> /center/ of it's extent.  Some examples:
> 1) X-extent = (-2 . 2) -> X-offset = 0 - 0 = 0
> 2) X-extent = (0 . 4) -> X-offset = 0 - (0 + 0.5 * 4) = -2
> 3) X-extent = (-2 . 4) -> X-offset = 0 - ((0.5 * -2) + (0.5 * 4)) = 0
> - (-1 + 2) = -1
> 
> There is a special C++ procedure x_aligned_on_self that can do 

Re: Fingering not aligned in 2.17, ok in 2.16

[Jan Nieuwenhuizen]

Nick Payne writes:

>> Do you consider this a bug?  Actually, I like the new behaviour
>> better.  What does the literature say?
>
> The great majority of commercial guitar scores I possess align the
> fingering vertically on chords, as 2.16 does.

Which means that there is no strict agreement?  The great majority
have been wrong before.

What about the most beautiful scores amongst your collection, what do
they do?

Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

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

Re: barline at end of staff

[David Nalesnik]

Wilbert,

On Sat, Mar 23, 2013 at 9:26 AM, Wilbert Berendsen  wrote:

> Op 16-03-13 17:35, Arno Rog schreef:
>
>  L.S.
>>
>> I'm trying to figure out a way to place the last bar line exactly at the
>> end of
>> the staff in the score of the Dutch anthem at
>> http://lsr.dsi.unimi.it/LSR/**Snippet
>> ?
>> id=648
>>
>> Now it's done manually: \override Staff.BarLine #'extra-offset = #'(23 .
>> 0)
>> \bar "|."
>> Can this be automatically (and correctly)?
>>
>> Arno Rog
>>
>>
>>  I used to use alignGrob for this. (See the LSR). But later I wrote this
> based on that:
>
> endbar = {
>   \overrideProperty #"Staff.BarLine" #'after-line-breaking
>   #(lambda (grob)
>  (let* ((sys (ly:grob-system grob))
>
> (staff (ly:grob-object grob 'staff-symbol))
> (half-thickness (/ (ly:staff-symbol-line-**thickness staff)
> 2))
> (cur-x (cdr (ly:grob-extent grob sys X)))
> (new-x (cdr (ly:grob-extent staff sys X)))
> (xoff (+ half-thickness (- new-x cur-x
>  (ly:grob-set-property! grob 'extra-offset (cons xoff 0
> }


Aha--I see.  Instead of 'blot-diameter, I should have incorporated the
thickness of the staff lines.

Just for the record, with that substitution, I'd get:

   \override Staff.BarLine #'extra-offset = #(lambda (grob)
(let* ((refp (ly:grob-system grob))
   (staff (ly:grob-object grob 'staff-symbol))
   (staff-extent-X (ly:grob-extent staff refp X))
   (bar-extent-X (ly:grob-extent grob refp X))
   (half-thickness (/ (ly:staff-symbol-line-thickness staff) 2)))
  (cons (- (cdr staff-extent-X) (cdr bar-extent-X) (- half-thickness))
0)))


...which is basically the same as your function

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

Re: User comments on R shorthand

[Olivier Biot]

On Wed, Mar 20, 2013 at 3:54 PM, James Harkins  wrote:

> My opinion (as a somewhat-more-than-casual Lilypond user, and as a
> contributor to another music software package [SuperCollider]): Any
> change in syntax that will break prior usage should be considered
> very, very carefully to be sure the gains are worth it.
>
> The proposal is:
>
> - Old: R2  ==  a full measure rest in 2/4 time
> - New: R2  ==  *two* full measure rests in any time signature
>
> That breaks backward compatibility.
>

Apart from breaking backward functionality, it does so dramatically.


> I do agree with Kieren that it's annoying to have to enter durations
> for full measure rests, when the duration of the measure is known
> elsewhere. So I think some change, if possible, would be nice to have.
>

I agree, but it is difficult since the measure size can change, and as I
understand it the full-measure rest is treated the same way as any note or
rest or space event.

In my humble opinion a full-measure rest should be interpreted as a
full-measure rest, otherwise I could simply write it as a "metered rest"
and compress the rests with some magic. today this is not the case, it's a
special case of a "metered rest" where 'only' the rendering of the rest
will differ.

I think Joram's suggestion, R*n, makes a lot more sense. It's related
> to the current syntax, just more convenient, and it doesn't break
> existing uses since the parser can distinguish among all of the
> following unambiguously:
>
> R2 (a full measure rest in 2/4 time)
> R2*2 (two full measure rests in 2/4 time)
> R*2 (two full measure rests in any meter)
>

Since a full-measure rest is a different thing, why not make it look
differently?

I'm not in favor of using "R" for a full-measure rest since its behavior
differs from notes and rests.

Why not write \Rest{2} instead of R*2 or R2*2 for two 2/4 time full measure
rests?

The fact that Kieren's original proposal would change the meaning of
> the number immediately after R raises a red flag for me -- breaking
> compatibility, confusing current users once they are forced to adapt
> to the new syntax -- and the only gain over the second proposal is to
> lose a * after R. That falls far short of the threshold to justify
> breaking existing syntax, IMO.
>
> I'm strongly against Kieren's original idea. I'm cautiously in favor
> of Joram's alternative.
>

Time signatures are set differently than music expressions.

I think full-measure rests should be treated differently as well, to avoid
the confusion that will definitely appear when combining music expressions
and time signature changes.

Best regards,

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

Re: how offsets and alignment works: an explanation

[Urs Liska]

Hi Janek,

thanks for these explanations.
If the feedback doesn't give you a sufficiently clear idea where to put 
the material, you know what I'd suggest? ;-)


Best
Urs

Am 23.03.2013 15:05, schrieb Janek Warcho?:

Hi,

here's an explanation of what's happening when we're using XY-offset,
self-alignment etc.  I hope that it'll help users get a better
understanding of LilyPond internals; i also think it would be a good
material for documentation, but i'm not sure where should it be placed
- it seems to fit both in Learning as well as Extending, and maybe
even CG...

Let's start at the very beginning:
LilyPond needs to know where each and every grob should be placed.
This placement information is stored using relative coordinates:
position of a grob is defined relative to the position of its parent
(if we had used absolute coordinates - e.g. distances from the edges
of the page - it would be hard to maintain spatial relationships
between grobs).

Every grob knows which grob is its parent in respective axis.  For
example, a Flag knows that its X-parent is a particular Stem.

Relative coordinates that describe grob's placement are stored in grob
properties called X-offset and Y-offset.  They are measured in
staffspaces.  X-offset is the horizontal displacement between grob's
reference point and the reference point of grob's X-parent (similarly
with Y-offset).

What is a reference point?  It's a special point that defines the
grob's position.  Think about geometry: if you have to define where a
figure is placed on a plane, you'll usually say something like "the
lower left corner of this square has coordinates (0, 2)" "or "the
center of this circle is at (-1, 3)". "Lower left corner" and "center"
would be the reference points for square and circle.

This illustration shows where refpoints of particular grobs are located:

{
   \override NoteHead #'style = #'altdefault
   g'2-> c''\fermata | as'1^"Yogi" |
   b'\breve _"Larry" | \mark "Twinkle" e''8 s4.
}
-> see attached "refpoint examples.png"

By overriding X-offset value, we can move grobs relative to their parents:

{
   \override NoteHead #'style = #'altdefault
   \override Script #'X-offset = #2
   \override TextScript #'X-offset = #1.5
   \override Stem #'X-offset = #2
   \override Score.RehearsalMark #'X-offset = #-2
   g'2-> c''\fermata | as'1^"Yogi" |
   b'\breve _"Larry" | \mark "Twinkle" e''8 s4.
}
-> see attached "offsets.png"

(notice that the Flag moved together with its Stem)

Now, let's explain another pair of properties: X-extent and Y-extent.
Each of them is a pair of numbers (an Interval), and they store grob's
dimensions relative to its reference point.  For example X-extent
equal to (-1 . 4) means that the left edge of the grob is 1 staffspace
to the left of its reference point, and right edge is 4 staffspace to
the right from reference point, for a total width of 4 - (-1) = 4 + 1
= 5 staffspaces.
Both numbers in an extent may be positive, for example (2 . 3) is a
valid extent: it means that the whole grob is on the right of its
refpoint, and the width of the grob is 3 - 2 = 1 staffspace.
Similarly, both numbers can be negative; these situations are quite
unusual but won't give LilyPond headaches.
The most common situation (at least for X-extent) is that the first
number is 0, which means that the reference point is on the left edge
of the grob.

Now, suppose that we want to position a RehearsalMark so that its
right edge is aligned with a Barline.  With X-offset = 0 (i.e. its
reference point aligned on parent, which is equal to Barline in this
situation) RehearsalMark would be placed like this:

{
   \override Score.RehearsalMark #'X-offset = #0
   b4 b b b \mark "Twinkle" b b b b
}
-> see image (1) in attached "images.png"

So, we need to shift it.  Remember what the second number in X-extent
means?  It's the position of grob's right edge relative to its
refpoint.  If we subtract this value from 0, we'll get the X-offset we
want:

{
   \override Score.RehearsalMark #'X-offset = #-10.4
   b4 b b b \mark "Twinkle" b b b b
}
(2)

What if we wanted to center some grob on the refpoint on its parent?
That's simple: calculate the displacement between grob's refpoint and
/center/ of it's extent.  Some examples:
1) X-extent = (-2 . 2) -> X-offset = 0 - 0 = 0
2) X-extent = (0 . 4) -> X-offset = 0 - (0 + 0.5 * 4) = -2
3) X-extent = (-2 . 4) -> X-offset = 0 - ((0.5 * -2) + (0.5 * 4)) = 0
- (-1 + 2) = -1

There is a special C++ procedure x_aligned_on_self that can do these
calculations for us; it's defined in Self_alignment_interface class.
To use it, we say:

\override GrobName #'X-offset = #ly:self-alignment-interface::x-aligned-on-self

And it means "when you need to know a GrobName's X-offset, run
x_aligned_on_self procedure form Self_alignment_interface C++ class on
this RehearsalMark and take the value that the procedure returned".

Then we need to specify what alignment we want:

\override GrobName #'self-alignment-X = #RIGHT

will tell the pr

Re: ANN: Frescobaldi 2.0.9

[SoundsFromSound]

Thank you so very much!!!  Your program is a JOY to work with.
LilyPond and Frescobaldi are an unbeatable combination.

Ben


Wilbert Berendsen-6 wrote
> Hi all,
> 
> Frescobaldi 2.0.9 has been released in the wild.
> 
> Due to GitHub removing the file upload section, the tarball is on
> Googlecode: http://code.google.com/p/lilykde/downloads/list
> 
> Changes in 2.0.9:
> 
> * Translations:
>   - updated: nl, de, uk
> * New features:
>   - Frescobaldi now detects when other applications modify or delete open
> files
> and displays the changes in a dialog, where the user can reload or
> save the
> affected documents. The file-watching is turned on by default, but can
> be
> disabled. (wish: issue #103)
>   - File->Reload and Reload All: reload the current document or all
> documents
> from disk. This action can be undone with Ctrl-Z.
>   - Frescobaldi now can be configured to open the generated PDF files when
> opening a LilyPond document, even if they are not up-to-date. It then
> shows
> a red background in the document chooser. See
> Preferences->Tools->Music View
>   - Music->Reload: switches the Music View to the current source document
> and
> re-checks for updated PDF documents. If there are no updated PDFs it
> even
> tries to load non up-to-date PDFs (regardless of the setting above)
>   - New --list-sessions commandline option to list the named sessions
>   - New actions View->Matching Pair and Select Matching Pair to jump to or
> select the range of matching parentheses, braces etc (wish: issue
> #105)
>   - Quick Insert: \melisma, \melismaEnd spanner button (idea: issue #88)
> * Improvements:
>   - Custom defined markup commands are also auto-completed
>   - Better default font on Windows
>   - Action "Always Engrave this document" also available in document
> context
> menu (in documents list and in tabbar)
>   - Don't check included files multiple times for defined commands etc.
>   - Highlighting matching characters, such as slur, brace, << >>, etc does
> not
> take a long time anymore when editing or moving through a long
> document
>   - string numbers are highlighted (and understood) correctly outside
> chords
> (LilyPond 2.16 syntax change)
>   - Export colored HTML now uses CSS classes, makes it easy to change the
> high-
> lighting in the HTML later (idea: issue #89)
> * Bug fixes:
>   - Fix hyphenation of words with accents (reported by Andreas Edlund)
>   - Fix Save As... on Mac OS X (issue #104)
>   - Fix startup failure on Mac OS X (issue #77)
>   - Fix QPyNullVariant error messages with some PyQt versions
>   - Workaround two PyQt bugs:
> * fix score wizard AttributeError message when using
> sip-4.14.3/PyQt-4.9.6
> * fix large delays in editor when using sip-4.14.3/PyQt-4.9.6 (issue
> #100)
>   - music highlighting of a note after \unset someVariable is now correct
>   - fix Python error message when a document (marked as Always engraved)
> is
> engraved which didn't have yet the PDF displayed
> 
> Thanks go to many users for their bug reports, feature requests and good
> ideas!
> Enjoy!
> Wilbert
> 
> -- 
> Wilbert Berendsen
> (http://www.wilbertberendsen.nl)
> 
> 
> ___
> lilypond-user mailing list

> lilypond-user@

> https://lists.gnu.org/mailman/listinfo/lilypond-user





-
composer | sound designer
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/ANN-Frescobaldi-2-0-9-tp143251p143279.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: how offsets and alignment works: an explanation

[Noeck]

> This is explained very concisely and without examples in the NR, see
> http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects

I disagree. As an average user, I feel quite lost in this section
especially with the "two-dimensional" extents.

Some images and the explanation from Janek, what and where a reference
point is and how extents are defined, would help a lot here. A look at
that image tells you almost all you need to know about shifts and
reference points.

The CG is too far away from the normal user. I would only put the part
on scheme functions there.

»An image tells you more than a thousand words« is a German saying which
applies very well to this section, IMHO. But I think that lacks at many
places in the docs: images. They are very text-centred and sometimes an
image would be much quicke to understand than pages of text. This
particularly applies to spacing and positioning issues.

Cheers,
Joram

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

Re: how offsets and alignment works: an explanation

[Trevor Daniels]

Noeck wrote Saturday, March 23, 2013 5:55 PM
>
>> This is explained very concisely and without examples in the NR, see
>> http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects
> 
> I disagree. As an average user, I feel quite lost in this section
> especially with the "two-dimensional" extents.

The Notation Reference is a _reference_ document.  It is intended to
remind users of information which they already understand.  Explanations
belong either in the Learning Manual, the Extensions Manual or the
Contributor's Guide.  We need to be quite strict about this, other the
NR will become far too long.  The pdf version is already 800 pages
long and takes several minutes to download.  That is why we moved 
material into the other manuals.
  
> The CG is too far away from the normal user. I would only put the part
> on scheme functions there.

I'm quite happy to see extensive links to the CG.  These will take you to the
appropriate section just as easily as if they are in the same manual.
 
> »An image tells you more than a thousand words« is a German saying which
> applies very well to this section, IMHO. But I think that lacks at many
> places in the docs: images. They are very text-centred and sometimes an
> image would be much quicke to understand than pages of text. This
> particularly applies to spacing and positioning issues.

That's because we have several blind users.  Images are useless for them.

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

Re: how offsets and alignment works: an explanation

[Noeck]

Am 23.03.2013 19:13, schrieb Trevor Daniels:
> 
> Noeck wrote Saturday, March 23, 2013 5:55 PM
>>
>>> This is explained very concisely and without examples in the NR, see
>>> http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects
>>
>> I disagree. As an average user, I feel quite lost in this section
>> especially with the "two-dimensional" extents.
> 
> The Notation Reference is a _reference_ document.  It is intended to
> remind users of information which they already understand.  Explanations
> belong either in the Learning Manual, the Extensions Manual or the
> Contributor's Guide. 

Ok, I see. Then the Learning Manual should be extended by some basic
explanations about these things.

>> »An image tells you more than a thousand words« …
> That's because we have several blind users.  Images are useless for them.

I know. And I agree, that blind users should be able to fully understand
the docs. But I think that should not prevent us from having overview
images which are helpful for the non-blind users in addition.

Joram

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

Re: Fingering not aligned in 2.17, ok in 2.16

[Thomas Scharkowski]

 Original-Nachricht 


Nick Payne writes:


Do you consider this a bug?  Actually, I like the new behaviour
better.  What does the literature say?


The great majority of commercial guitar scores I possess align the
fingering vertically on chords, as 2.16 does.


Which means that there is no strict agreement?  The great majority
have been wrong before.

What about the most beautiful scores amongst your collection, what do
they do?

Jan


Most of the newer commercial guitar score are poorly typeset imho.
Compare the old Schott edition (hand engraved) of Ponce's "Thème varié 
et finale" and the new one which was made using Finale.


On topic: I like the new behaviour better.
there is a nice example where sometimes the fingerings are aligned and 
sometimes not, for better readability:

Goffredo Petrassi: Nunc (1971), Edizioni Suvini Zerboni (c) 1972

Thomas

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

Re: How to get a book twice with different page-footers?

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> I'm trying to parse a book twice with different footers.
> The function below
> (thanks to Jan-Peter and Urs
> http://lilypond.1069038.n5.nabble.com/Compile-twice-with-different-includes-td140953.html
> )
> below works quite nice so long as very simple footers are used.
> As soon as I try something more elaborated, like \on-the-fly
> #not-first-page , an error occurs.
> Well, that's no surprise.
>
> Though, how to do it?

# gives you lexical closure.  So you might need \on-the-fly
\not-first-page  when the point of entry is not inside of a header
block.

-- 
David Kastrup


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

Re: ANN: Frescobaldi 2.0.9

[SoundsFromSound]

Also just a heads up for my fellow Ubuntu friends:

This v2.0.9 update fixes that annoying Insert menu bug where the whole menu
duplicated itself everytime you clicked to expand it.  :)  It was due to
Unity I believe, but either way it's fixed so this program is rockin' now!

Thanks again Wilbert,

Ben



Wilbert Berendsen-6 wrote
> Hi all,
> 
> Frescobaldi 2.0.9 has been released in the wild.
> 
> Due to GitHub removing the file upload section, the tarball is on
> Googlecode: http://code.google.com/p/lilykde/downloads/list
> 
> Changes in 2.0.9:
> 
> * Translations:
>   - updated: nl, de, uk
> * New features:
>   - Frescobaldi now detects when other applications modify or delete open
> files
> and displays the changes in a dialog, where the user can reload or
> save the
> affected documents. The file-watching is turned on by default, but can
> be
> disabled. (wish: issue #103)
>   - File->Reload and Reload All: reload the current document or all
> documents
> from disk. This action can be undone with Ctrl-Z.
>   - Frescobaldi now can be configured to open the generated PDF files when
> opening a LilyPond document, even if they are not up-to-date. It then
> shows
> a red background in the document chooser. See
> Preferences->Tools->Music View
>   - Music->Reload: switches the Music View to the current source document
> and
> re-checks for updated PDF documents. If there are no updated PDFs it
> even
> tries to load non up-to-date PDFs (regardless of the setting above)
>   - New --list-sessions commandline option to list the named sessions
>   - New actions View->Matching Pair and Select Matching Pair to jump to or
> select the range of matching parentheses, braces etc (wish: issue
> #105)
>   - Quick Insert: \melisma, \melismaEnd spanner button (idea: issue #88)
> * Improvements:
>   - Custom defined markup commands are also auto-completed
>   - Better default font on Windows
>   - Action "Always Engrave this document" also available in document
> context
> menu (in documents list and in tabbar)
>   - Don't check included files multiple times for defined commands etc.
>   - Highlighting matching characters, such as slur, brace, << >>, etc does
> not
> take a long time anymore when editing or moving through a long
> document
>   - string numbers are highlighted (and understood) correctly outside
> chords
> (LilyPond 2.16 syntax change)
>   - Export colored HTML now uses CSS classes, makes it easy to change the
> high-
> lighting in the HTML later (idea: issue #89)
> * Bug fixes:
>   - Fix hyphenation of words with accents (reported by Andreas Edlund)
>   - Fix Save As... on Mac OS X (issue #104)
>   - Fix startup failure on Mac OS X (issue #77)
>   - Fix QPyNullVariant error messages with some PyQt versions
>   - Workaround two PyQt bugs:
> * fix score wizard AttributeError message when using
> sip-4.14.3/PyQt-4.9.6
> * fix large delays in editor when using sip-4.14.3/PyQt-4.9.6 (issue
> #100)
>   - music highlighting of a note after \unset someVariable is now correct
>   - fix Python error message when a document (marked as Always engraved)
> is
> engraved which didn't have yet the PDF displayed
> 
> Thanks go to many users for their bug reports, feature requests and good
> ideas!
> Enjoy!
> Wilbert
> 
> -- 
> Wilbert Berendsen
> (http://www.wilbertberendsen.nl)
> 
> 
> ___
> lilypond-user mailing list

> lilypond-user@

> https://lists.gnu.org/mailman/listinfo/lilypond-user





-
composer | sound designer
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/ANN-Frescobaldi-2-0-9-tp143251p143286.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

Removing time change from previous line

[Alberto Simões]

Hello

Is there any way to remove the time signature that is shown in a 
previous line, when the time is changing?


Not sure if I made myself clear: when issuing a \time command, if it 
occurs at the end of the staff line, it is repeated at the end of the 
current staff, and in the beginning of the next. I would like to remove 
the one from the previous line.


In fact, not only the time, but also the key signature >:)

Thank you,
Alberto

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

Re: Removing time change from previous line

[Noeck]

Hi Alberto,

this line should help you (2.16):
\override Staff.TimeSignature #'break-visibility = ##'end-of-line-invisible

or in version 2.17:
\override Staff.TimeSignature.break-visibility = ##'end-of-line-invisible

This is explained here:
http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.de.html#using-break_002dvisibility

HTH
Joram


PS: Why so many problems with ##' ? Can this "end-of-line-invisible"
variable not just know itself whether it is a vector or what it is?
I know we need that # to tell the parser that we need to switch to
Scheme, but the rest is hard to remember (I always need an internet
connection for that and have to search the docs).

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

Re: Removing time change from previous line

[David Kastrup]

Noeck  writes:

> Hi Alberto,
>
> this line should help you (2.16):
> \override Staff.TimeSignature #'break-visibility = ##'end-of-line-invisible
>
> or in version 2.17:
> \override Staff.TimeSignature.break-visibility = ##'end-of-line-invisible
>
> This is explained here:
> http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.de.html#using-break_002dvisibility
>
> HTH
> Joram
>
>
> PS: Why so many problems with ##' ? Can this "end-of-line-invisible"
> variable not just know itself whether it is a vector or what it is?
> I know we need that # to tell the parser that we need to switch to
> Scheme, but the rest is hard to remember (I always need an internet
> connection for that and have to search the docs).

The rest appears to be nonsense.  I'd expect #end-of-line-invisible to
work just fine.

-- 
David Kastrup


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

Re: how offsets and alignment works: an explanation

[Nick Payne]

On 24/03/13 03:56, Trevor Daniels wrote:

Hi Janek

This is explained very concisely and without examples in the NR, see
http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects


BTW, the text in that section ("an accidental can be repositioned 
vertically by setting Y-offset but any changes to X-offset have no 
effect.") reminds me that there is something odd with accidentals and 
setting Y-offset. A while ago I was having to nudge an acccidental 
vertically to avoid a collision with a note in another voice in single 
staff polyphony, and when I accidentally set a large value for Y-offset, 
I found that the accidental also moved in the X direction. Have a look 
at the output from the following. As the Y-offset gets larger, the 
change in positioning in the X direction gets larger as well. There's 
also something strange happening with the ledger lines, which are 
getting shorter as well.


\version "2.17.14"

\relative f'' {
  ais2 s
  \override Accidental.Y-offset = #0.5 ais s
  \override Accidental.Y-offset = #1.5 ais s
  \override Accidental.Y-offset = #2.5 ais s
}

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

Time change breaks the layout

[Noeck]

Hi,

while testing some snippets, I encountered a strange behaviour in the
following code:

\version "2.16.0" % "2.17.14" as well
{
  a1 \break
  \time 3/4  % fine without time change
  a1 \break
  %\time 6/8 % "6/8" is also at an ugly position
  %a2.
}

The barline is not at the end of the second line but well before. The
\time 6/8, that can be commented in, is also much too far from the
preceding bar line. I agree that this is spaced-out extremely wide but
LilyPond could do much better, nonetheless.
Is this a bug?

Cheers,
Joram

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

Re: Removing time change from previous line

[Noeck]

> The rest appears to be nonsense.  I'd expect #end-of-line-invisible to
> work just fine.

Oh, thanks! That reassures me.
(I must have had some other problem before with this.)

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

Re: Removing time change from previous line

[David Nalesnik]

On Sat, Mar 23, 2013 at 5:32 PM, Noeck  wrote:

> Hi Alberto,
>
> this line should help you (2.16):
> \override Staff.TimeSignature #'break-visibility = ##'end-of-line-invisible
>
> or in version 2.17:
> \override Staff.TimeSignature.break-visibility = ##'end-of-line-invisible
>
> This is explained here:
>
> http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.de.html#using-break_002dvisibility
>
> HTH
> Joram
>

Yes, this will work with the time signature.  However, for some reason,
overriding 'break-visibility of KeySignature doesn't have any effect on the
cautionary key signature.  Not sure if I'm misunderstanding something:

 \new Staff {
  \override Staff.TimeSignature #'break-visibility = #end-of-line-invisible
  % why doesn't the following line work?
  \override Staff.KeySignature #'break-visibility = #end-of-line-invisible
  % this does:
  \set Staff.explicitKeySignatureVisibility = #end-of-line-invisible
  c1
  \break
  \time 3/4
  \key cis \major
  cis2.
}

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

Re: Removing time change from previous line

[Noeck]

>   % why doesn't the following line work?
>   \override Staff.KeySignature #'break-visibility = #end-of-line-invisible
>   % this does:
>   \set Staff.explicitKeySignatureVisibility = #end-of-line-invisible

It is explained here:
http://lilypond.org/doc/v2.14/Documentation/notation/visibility-of-objects.de.html#special-considerations

The first line is only for non-changing time signatures, the second only
for the changing ones.

(If you were asking for a deeper reason, that's out of my scope.)

Joram

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

Re: Time change breaks the layout

[Noeck]

Sorry for the noise. It the second note should be a2. - then it works as
expected.

Joram

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

Re: Removing time change from previous line

[David Nalesnik]

On Sat, Mar 23, 2013 at 6:11 PM, Noeck  wrote:

> >   % why doesn't the following line work?
> >   \override Staff.KeySignature #'break-visibility =
> #end-of-line-invisible
> >   % this does:
> >   \set Staff.explicitKeySignatureVisibility = #end-of-line-invisible
>
> It is explained here:
>
> http://lilypond.org/doc/v2.14/Documentation/notation/visibility-of-objects.de.html#special-considerations
>
> The first line is only for non-changing time signatures, the second only
> for the changing ones.
>
> (If you were asking for a deeper reason, that's out of my scope.)
>


No--no deeper reason!

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

Re: \relative proposal: putting absolute pitches anywhere within \relative block using @-sign

[Anthonys Lists]

On 13/03/2013 19:24, nothingwaver...@gmail.com wrote:

Here's the idea.

1. Define absolute octave syntax with the @-sign (let it be a mnemonic for 
_A_bsolute) to be the syntax for temporarily specifying an ABSOLUTE PITCH 
within a \relative block, such that the next pitch, if it doesn't use the 
@-sign also, is relative to the absolute pitch.

2. Keep \relative X { ... } working the same way as it is (DON'T make 
convert-ly change it around).


What do people think?


Okay, this may be covered by other new facilities, but I remember I had 
exactly the problem this is intended to solve. I wanted to use a 
fragment inside a relative block, but the stuff around it messed up the 
relative octave, so I wanted to be able to specify an explicit octave 
for the first note of the fragment. (Han-Wen kindly wrote me a little 
function, which may have become \reset-absolute-octave, I've never used 
that so I'm not sure about that.)


Cheers,
Wol

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

Re: how offsets and alignment works: an explanation

[Thomas Morley]

2013/3/23 Janek Warchoł :
> Hi,
>
> here's an explanation of what's happening when we're using XY-offset,
> self-alignment etc.  I hope that it'll help users get a better
> understanding of LilyPond internals; i also think it would be a good
> material for documentation, but i'm not sure where should it be placed
> - it seems to fit both in Learning as well as Extending, and maybe
> even CG...
>
> Let's start at the very beginning:
> LilyPond needs to know where each and every grob should be placed.
> This placement information is stored using relative coordinates:
> position of a grob is defined relative to the position of its parent

[...]

> What is a reference point?

[...]

> There is a special C++ procedure x_aligned_on_self

[...]

> we have to use a different
> procedure: aligned_on_x_parent.

[...]

Hi Janek,

this is great!!
I've never read a better explanation of x_aligned_on_self and
aligned_on_x_parent.
Even better than
http://www.lilypond.org/doc/v2.17/Documentation/notation/aligning-objects
Well, it's _usage_ is explained quite well in the manuals.
Though, I very often need a deeper understanding _how_ something
works. If it's written in scheme, I study the code. But I've no clue
about C++. I'm able to distinguish C++ code and comments, and that's
(nearly) all. So very often I've to drop the ball.
Rewriting and modifying some C++ code in scheme to use with local
custom-functions/definitions is impossible, if I can't understand the
original.

I'd wish more/all procedures in C++ were explained this way.

Some other remarks:
a)
There are some opinions not to add it to the LM or the NR and I fully
agree with them.
But I strongly object to put it in the CG for one reason: The CG is
_never_ translated!
The Extending Manual seems to be appropiate (or the CG should be
translated as well).
b)
I'd suggest to add a remark (+ example?) about y_aligned_on_self

Thanks,
  Harm

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

RE: \relative proposal: putting absolute pitches anywhere within \relative block using @-sign

[Curt McDowell]

> On 13/03/2013 19:24, nothingwaver...@gmail.com wrote:
>> 1. Define absolute octave syntax with the @-sign (let it be a mnemonic
for _A_bsolute)
>> to be the syntax for temporarily specifying an ABSOLUTE PITCH within a
\relative block,
>> such that the next pitch, if it doesn't use the @-sign also, is relative
to the absolute pitch.
>
> Okay, this may be covered by other new facilities, but I remember I had
exactly the problem
> this is intended to solve. I wanted to use a fragment inside a relative
block, but the stuff
> around it messed up the relative octave, so I wanted to be able to specify
an explicit octave
> for the first note of the fragment. (Han-Wen kindly wrote me a little
function, which may have
> become \reset-absolute-octave, I've never used that so I'm not sure about
that.)

Hi,

The precious '@' symbol should be used for some major new functionality
rather than
to patch up one detail case.

The problem you mention seems to be covered by nesting one \relative X { ...
} inside
another. It appears the treatment of X is still absolute when nested.

Regards,
Curt



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

Re: Fingering not aligned in 2.17, ok in 2.16

[Nick Payne]

On 24/03/13 04:07, Jan Nieuwenhuizen wrote:

Nick Payne writes:


Do you consider this a bug?  Actually, I like the new behaviour
better.  What does the literature say?

The great majority of commercial guitar scores I possess align the
fingering vertically on chords, as 2.16 does.

Which means that there is no strict agreement?  The great majority
have been wrong before.

What about the most beautiful scores amongst your collection, what do
they do?
I think the best look is achieved by either having the chord fingering 
aligned vertically, or having it so that it is spaced a consistent 
amount away from from the note or accidental - i.e. if fingering doesn't 
need to avoid an accidental elsewhere in the chord, it should sit where 
it would normally sit next to the notehead if the accidental wasn't 
there. The second option can be achieved in Lilypond by tweaking 
fingerings that don't need to avoid an accidental with a large negative 
script priority:


\relative f'' {
  \set fingeringOrientations = #'(left)
  4
  4
}
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Frescobaldi installation on Mac OS X (was: Re: Frescobaldi install)

[SoundsFromSound]

Oh, wow - I had no idea about that bug.  Honestly, in my experience,
Frescobaldi has always been near-instant loading and wicked fast in usage -
but thanks for the heads up! :)

Ben


Wilbert Berendsen-4 wrote
> There is a recent, confirmed PyQt4 bug that caused very large delays in 
> Frescobaldi, but 2.0.9 will run fine regardless, even with PyQt-4.9.6 or 
> 4.10, allbeit slightly slower.
> 
> I'd very happy if someone with an Apple machine could create a good, 
> easily installable Frescobaldi package (maybe with included Qt4 and 
> popplerqt4 like the Windows installer, or with clear instructions about 
> how to get the dependencies), I'll put it on the download page.
> 
> Wilbert
> 
> -- 
> Wilbert Berendsen
> http://www.wilbertberendsen.nl/
> 
> 
> ___
> lilypond-user mailing list

> lilypond-user@

> https://lists.gnu.org/mailman/listinfo/lilypond-user





-
composer | sound designer
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Frescobaldi-install-was-final-score-tp142376p143303.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