Re: Override a StaffSymbol property outside \new Staff { ... } context
On 2020-01-15 6:41 pm, Paolo Prete wrote:
Sorry Aaron, I was not precise in my question.
I need to override a property of StaffSymbol, for every staff, outside
any
music expression/block context. Probably I'm not using the right words
even
now.
But what I need is a sort of a "global" variable which is set for any
staff
without having to put it into some music expression (like \layout
{\context
{...}} , or \new Staff \with { ... } etc.).
This is why I asked if is there a Scheme solution
To my knowledge, there is nothing more "global" than the top-level
\layout. (The same goes for \header, \paper, and \midi.)
If you are insistent on using Scheme, I believe the following is
functionally equivalent:
\version "2.19.83"
% LilyPond:
% \layout { \context { \Staff \override StaffSymbol.color = #red } }
% Scheme:
#(ly:output-def-set-variable! $defaultlayout 'Staff
(ly:context-def-modify
(ly:output-def-lookup $defaultlayout 'Staff)
#{ \with { \override StaffSymbol.color = #red } #}))
<< \new Staff { b'4 } \new Staff { b'4 } >>
Note that I still use LilyPond syntax to define the context-mod (i.e.
\with block), but even that could be completely done in Scheme:
\version "2.19.83"
#(ly:output-def-set-variable! $defaultlayout 'Staff
(ly:context-def-modify
(ly:output-def-lookup $defaultlayout 'Staff)
; LilyPond:
; #{ \with { \override StaffSymbol.color = #red } #}
; Scheme:
(ly:make-context-mod
`((assign StaffSymbol ,(ly:make-grob-properties
`((color . ,red
<< \new Staff { b'4 } \new Staff { b'4 } >>
However, why jump through such Scheme hoops when LilyPond syntax is more
direct?
-- Aaron Hill
Re: Override a StaffSymbol property outside \new Staff { ... } context
On Thu, Jan 16, 2020 at 3:15 AM Aaron Hill wrote:
> On 2020-01-15 5:15 pm, Paolo Prete wrote:
> > Hello,
> >
> > is it possible to override a property of StaffSymbol outside a
> > \new Staff \with { ... }
> > context?
> >
> > I would like to obtain something like:
> >
> > %%%
> >
> > #scheme-code-for-overriding-staffsymbol-for-all-the-staves-in-the-score
> > {
> > c' c' c' c'
> > }
> >
> > %%%
>
> Without needing to mess with Scheme, you can do this using the \layout
> block providing you want to change all staves:
>
>
> \version "2.19.83"
>
> \layout {
>\context {
> \Staff
> \override StaffSymbol.color = #red
>}
> }
>
> \new Staff { b'4 }
> \new Staff { b'4 }
> \new Staff { b'4 }
>
>
> (That is a top-level \layout block, but the same can be done within a
> \score to scope the effect.)
> \name RedStaff
> \alias Staff
> \override StaffSymbol.color = #red
>}
>\inherit-acceptability RedStaff Staff
> }
>
>
Sorry Aaron, I was not precise in my question.
I need to override a property of StaffSymbol, for every staff, outside any
music expression/block context. Probably I'm not using the right words even
now.
But what I need is a sort of a "global" variable which is set for any staff
without having to put it into some music expression (like \layout {\context
{...}} , or \new Staff \with { ... } etc.).
This is why I asked if is there a Scheme solution
thanks!
Paolo
Re: Override a StaffSymbol property outside \new Staff { ... } context
On 2020-01-15 5:15 pm, Paolo Prete wrote:
Hello,
is it possible to override a property of StaffSymbol outside a
\new Staff \with { ... }
context?
I would like to obtain something like:
%%%
#scheme-code-for-overriding-staffsymbol-for-all-the-staves-in-the-score
{
c' c' c' c'
}
%%%
Without needing to mess with Scheme, you can do this using the \layout
block providing you want to change all staves:
\version "2.19.83"
\layout {
\context {
\Staff
\override StaffSymbol.color = #red
}
}
\new Staff { b'4 }
\new Staff { b'4 }
\new Staff { b'4 }
(That is a top-level \layout block, but the same can be done within a
\score to scope the effect.)
If you only need to affect specific staves but want to avoid duplicating
the overrides, put them in a variable to reference as needed:
\version "2.19.83"
redLines = \with { \override StaffSymbol.color = #red }
\new Staff { b'4 }
\new Staff \with { \redLines } { b'4 }
\new Staff \with { \redLines } { b'4 }
Lastly, you could even define your own Staff-like context and embed the
property changes within it:
\version "2.19.83"
\layout {
\context {
\Staff
\type Engraver_group
\name RedStaff
\alias Staff
\override StaffSymbol.color = #red
}
\inherit-acceptability RedStaff Staff
}
\new Staff { b'4 }
\new RedStaff { b'4 }
\new RedStaff { b'4 }
-- Aaron Hill
Override a StaffSymbol property outside \new Staff { ... } context
Hello,
is it possible to override a property of StaffSymbol outside a
\new Staff \with { ... }
context?
I would like to obtain something like:
%%%
#scheme-code-for-overriding-staffsymbol-for-all-the-staves-in-the-score
{
c' c' c' c'
}
%%%
Thanks
Re: Distance of a grob from its reference point
On Thu, Jan 16, 2020 at 1:16 AM Aaron Hill wrote: > On 2020-01-15 3:59 pm, Paolo Prete wrote > > If you are pushing things by small amounts akin to font kerning, then > collisions are unlikely and extra-offset is often the right tool for the > job. > "If you are pushing things by small amounts akin to font kerning, then collisions are unlikely and extra-offset is often the right tool for the job." I don't agree and I can show you many examples that demonstrate the opposite conclusion. And if you use \override Y-offset you preserve the avoid-collision algo without having the discussed issues. Best, P >
Re: Distance of a grob from its reference point
On Thu, Jan 16, 2020 at 1:31 AM Carl Sorensen wrote: > > > It may be desirable, but it’s not **necessary** to add a warning. At > this point, I don’t think we have the infrastructure to add the warning. > I did not know that. I thought that such a modification was a one-line change.
Re: Distance of a grob from its reference point
Paolo, Please don’t top-post on this list. Users are expected to interleave their responses. Please see how other users do it. From: Paolo Prete Date: Wednesday, January 15, 2020 at 5:15 PM To: Carl Sorensen Cc: Lilypond-User Mailing List Subject: Re: Distance of a grob from its reference point Yes, but, it's necessary too to add a *warning* on the Lilypond output. This is much more clear for the user than the documentation. It may be desirable, but it’s not *necessary* to add a warning. At this point, I don’t think we have the infrastructure to add the warning. Your use case is not the standard LilyPond use case. I’m not much motivated to spend a lot of time making the changes necessary to add a warning. If you’d like to propose a patch, I wouldn’t expect it to be rejected as long as it met LilyPond coding standards. Thanks, Carl
Re: Distance of a grob from its reference point
On 2020-01-15 3:59 pm, Paolo Prete wrote: Hi Aaron. It's not Y-offset that has not to be used. It's the combination \offset + Y-offset. \override SomeGrob.Y-offset can be used (with a ruler, in an uncomfortably way) \offset Y-offset is nonsense. See my reply to Carl, and his reply to me. I think the conclusion in that thread is wrong, in that the issue is not related to unpure-pure containers. \offset Y-offset works perfectly fine. See *my* example that demonstrates this. The problem is that there is more going on than just Y-offset to determine where a bracket lives. Neutering \offset is not the solution. What we really need is a clear picture of what *does* impact layout. Someone adjusting Y-offset by too small an amount would be justified thinking it is broken, but that is because there is some other factor at play. Once they know they need a larger offset to effect a change, then there is no mystery or nonsense. If you are pushing things by small amounts akin to font kerning, then collisions are unlikely and extra-offset is often the right tool for the job. If you need to move things by greater distances, then it is important to tweak all of the various spacing properties to ensure that collisions are avoided sufficiently well. My example shows how using outside-staff-padding can be a more effective tool than adjusting Y-offset. But in practice, you might need to do a combination of both. -- Aaron Hill
Re: Distance of a grob from its reference point
Yes, but, it's necessary too to add a *warning* on the Lilypond output. This is much more clear for the user than the documentation. On Thu, Jan 16, 2020 at 1:12 AM Carl Sorensen wrote: > > > > > *From: *Paolo Prete > *Date: *Wednesday, January 15, 2020 at 4:45 PM > *To: *Carl Sorensen > *Cc: *Lilypond-User Mailing List > *Subject: *Re: Distance of a grob from its reference point > > > > Thanks to you Carl. > > > > Now, given that it's nonsense to offset an unknown value, I would remove > this property from the offset command of Lilypond. > > Or at least, if that remove is not easily doable in the internal API, > raise a *heavy* warning that you are using a random/deprecable command. > > Please do not see that as bad criticism. I'm telling that because it could > save time to other people. > > > > \offset is, as described in the NR, applicable to any property that has a > number value, including user-defined properties. It is not created > explicitly on a property-by-property basis. > > > > I could see that it might be useful to add a known issue to the \offset > command section of the NR that might say something like > > > > “If the property being offset has a default value (as mentioned in the > Internals Reference) that is an unpure-pure-container function, the results > of the \offset command may not provide a simple numerical offset from the > results without the \offset command applied.” > > > > Thanks, > > > > Carl > > >
Re: Distance of a grob from its reference point
From: Paolo Prete Date: Wednesday, January 15, 2020 at 4:45 PM To: Carl Sorensen Cc: Lilypond-User Mailing List Subject: Re: Distance of a grob from its reference point Thanks to you Carl. Now, given that it's nonsense to offset an unknown value, I would remove this property from the offset command of Lilypond. Or at least, if that remove is not easily doable in the internal API, raise a *heavy* warning that you are using a random/deprecable command. Please do not see that as bad criticism. I'm telling that because it could save time to other people. \offset is, as described in the NR, applicable to any property that has a number value, including user-defined properties. It is not created explicitly on a property-by-property basis. I could see that it might be useful to add a known issue to the \offset command section of the NR that might say something like “If the property being offset has a default value (as mentioned in the Internals Reference) that is an unpure-pure-container function, the results of the \offset command may not provide a simple numerical offset from the results without the \offset command applied.” Thanks, Carl
Re: Distance of a grob from its reference point
Hi Aaron.
It's not Y-offset that has not to be used. It's the combination \offset +
Y-offset.
\override SomeGrob.Y-offset can be used (with a ruler, in an
uncomfortably way)
\offset Y-offset is nonsense.
See my reply to Carl, and his reply to me.
HTH
Paolo
On Thu, Jan 16, 2020 at 12:46 AM Aaron Hill
wrote:
> On 2020-01-15 1:57 pm, Paolo Prete wrote:
> > I quote Carl's words:
> >
> > "So offset applies to the *estimated* position, and then the spacing
> > engine
> > works on the offset+estimated postion and ends up putting things where
> > it
> > thinks they belong"
> >
> > I checked that with the examples made before and it seems absolutely
> > true.
> >
> > Then: you have to offset an estimated position. How could you do that
> > if
> > you don't know this estimated position?
>
> \offset is a simple tool that merely adds a number to a number. Well to
> be fair, it has some complexity behind the scenes as it can handle
> offsetting numbers, pairs of numbers, and lists of numbers. The problem
> is unlikely with \offset; rather, it is the property you are modifying
> not having the final say.
>
> Consider: Y-offset is a desired distance between the reference points of
> a grob and its parent. OttavaBrackets use a procedure to determine this
> initial desired distance. And because Y-axis spacing issues are tricky,
> the unpure-pure container system exists to assist. The pure value is an
> estimate used before line breaking, and the unpure value consulted after
> line breaking.
>
> But even with the issues of unpure-pure containers aside, Y-offset is
> not the sole arbiter of positioning a bracket. You can see this here:
>
>
> \version "2.19.83"
>
> visualizeYOffset = #(define-music-function (grob-path) (symbol-list?)
>(define (proc grob)
> (let* ((orig (ly:grob-property grob 'stencil))
> (yoff (ly:grob-property grob 'Y-offset))
> (y (- yoff))
> (sten (grob-interpret-markup grob #{ \markup
> \with-dimensions-from \stencil #orig
> \overlay {
> \stencil #orig
> \with-color #red \path #0.1 #`(
> (moveto -1 0) (lineto 1 0)
> (moveto 0 0) (lineto 0 ,y)
> (moveto -0.4 -1) (lineto 0 0) (lineto 0.4 -1)
> (moveto -1 ,y) (lineto 1 ,y))
> \translate #(cons -0.8 (/ y 2))
> \general-align #X #RIGHT \vcenter \rotate #90
> \whiteout \pad-around #0.2
> \with-color #red \normal-text \fontsize #-6
> \line { Y-offset: #(format #f "~,3f" yoff) }
> } #})))
>(ly:grob-set-property! grob 'layer 1000)
>(ly:grob-set-property! grob 'stencil sten)))
>#{ \override $grob-path .after-line-breaking = #proc #})
>
> notes = \fixed c''' { \ottava 1 a8( 8) \ottava 0 a,4 }
>
> {
>\visualizeYOffset Staff.OttavaBracket
>
>\notes
>\once \offset Y-offset 0.4 Staff.OttavaBracket
>\notes
>\once \override Staff.OttavaBracket.Y-offset = 6
>\notes
>\once \offset Y-offset 1.6 Staff.OttavaBracket
>\notes
>\once \override Staff.OttavaBracket.outside-staff-padding = 1
>\notes
> }
>
>
> The slur exerts influence on the final bracket position that goes beyond
> the bracket's Y-offset. The first \offset is not enough to overcome
> this; but the explicit value and larger \offset are enough to show that
> modifying Y-offset can work.
>
> The alternate approach would be to not use Y-offset at all but rather
> control something like outside-staff-padding, as shown in the final
> example.
>
>
> -- Aaron Hill
Slur across alternate ending - with example
So I figured out how to make and adjust a slur on my own. I am really
wondering though if there is a more elegant way like how simple it is to do
\repeatTie.
\version "2.18.2"
\language "english"
\relative c'' {
\key d \major
\time 4/4
\repeat volta 2 {
d4 d8 d8~ d8 a4 d8(
}
\alternative {
{ e4. d8~ d8 cs4) a8 a4 a8 fs'8~ fs8 e4 d8 \bar ":|." }
{ e4.-\tweak control-points #'((-1 . 3.1) (3 . 3.6) (8 . 3.4) (10 . 1.5)) (
d8~ d8 cs8)fs8 fs8~ } }
}
Re: Distance of a grob from its reference point
On 2020-01-15 1:57 pm, Paolo Prete wrote:
I quote Carl's words:
"So offset applies to the *estimated* position, and then the spacing
engine
works on the offset+estimated postion and ends up putting things where
it
thinks they belong"
I checked that with the examples made before and it seems absolutely
true.
Then: you have to offset an estimated position. How could you do that
if
you don't know this estimated position?
\offset is a simple tool that merely adds a number to a number. Well to
be fair, it has some complexity behind the scenes as it can handle
offsetting numbers, pairs of numbers, and lists of numbers. The problem
is unlikely with \offset; rather, it is the property you are modifying
not having the final say.
Consider: Y-offset is a desired distance between the reference points of
a grob and its parent. OttavaBrackets use a procedure to determine this
initial desired distance. And because Y-axis spacing issues are tricky,
the unpure-pure container system exists to assist. The pure value is an
estimate used before line breaking, and the unpure value consulted after
line breaking.
But even with the issues of unpure-pure containers aside, Y-offset is
not the sole arbiter of positioning a bracket. You can see this here:
\version "2.19.83"
visualizeYOffset = #(define-music-function (grob-path) (symbol-list?)
(define (proc grob)
(let* ((orig (ly:grob-property grob 'stencil))
(yoff (ly:grob-property grob 'Y-offset))
(y (- yoff))
(sten (grob-interpret-markup grob #{ \markup
\with-dimensions-from \stencil #orig
\overlay {
\stencil #orig
\with-color #red \path #0.1 #`(
(moveto -1 0) (lineto 1 0)
(moveto 0 0) (lineto 0 ,y)
(moveto -0.4 -1) (lineto 0 0) (lineto 0.4 -1)
(moveto -1 ,y) (lineto 1 ,y))
\translate #(cons -0.8 (/ y 2))
\general-align #X #RIGHT \vcenter \rotate #90
\whiteout \pad-around #0.2
\with-color #red \normal-text \fontsize #-6
\line { Y-offset: #(format #f "~,3f" yoff) }
} #})))
(ly:grob-set-property! grob 'layer 1000)
(ly:grob-set-property! grob 'stencil sten)))
#{ \override $grob-path .after-line-breaking = #proc #})
notes = \fixed c''' { \ottava 1 a8( 8) \ottava 0 a,4 }
{
\visualizeYOffset Staff.OttavaBracket
\notes
\once \offset Y-offset 0.4 Staff.OttavaBracket
\notes
\once \override Staff.OttavaBracket.Y-offset = 6
\notes
\once \offset Y-offset 1.6 Staff.OttavaBracket
\notes
\once \override Staff.OttavaBracket.outside-staff-padding = 1
\notes
}
The slur exerts influence on the final bracket position that goes beyond
the bracket's Y-offset. The first \offset is not enough to overcome
this; but the explicit value and larger \offset are enough to show that
modifying Y-offset can work.
The alternate approach would be to not use Y-offset at all but rather
control something like outside-staff-padding, as shown in the final
example.
-- Aaron Hill
Re: Distance of a grob from its reference point
Thanks to you Carl. Now, given that it's nonsense to offset an unknown value, I would remove this property from the offset command of Lilypond. Or at least, if that remove is not easily doable in the internal API, raise a *heavy* warning that you are using a random/deprecable command. Please do not see that as bad criticism. I'm telling that because it could save time to other people. On Thu, Jan 16, 2020 at 12:22 AM Carl Sorensen wrote: > > > > > *From: *Paolo Prete > *Date: *Wednesday, January 15, 2020 at 4:16 PM > *To: *Carl Sorensen > *Cc: *Lilypond-User Mailing List > *Subject: *Re: Distance of a grob from its reference point > > > > I don't mean that with *broken*. I mean that it's unusable, given that the > values you put inside this function don't correspond to anything that you > can measure. Then, pretty random values. > > > > Please note that this doesn't happen with \override SomeGrob.X/Y-offset. > In that case, you can measure the offset with a ruler (in a very > uncomfortable way, though, given that you have to offset the ruler as well > with the ref point of the grob). > > > > Yes, this is true. Because when you \override you replace the > unpure-pure-container estimate function with a fixed constant value. > > > > \offset adds a fixed constant value to the existing result, which is an * > *estimate** rather than an actual value in the case of a Y-offset whose > default value is a unpure-pure-container function. The fact that you are > offsetting an estimate leads to random values, since the difference between > the estimate and the actual value is not predictable before completing the > spacing algorithm. > > > > Thanks, > > > > Carl > > > >
Re: Distance of a grob from its reference point
From: Paolo Prete Date: Wednesday, January 15, 2020 at 4:16 PM To: Carl Sorensen Cc: Lilypond-User Mailing List Subject: Re: Distance of a grob from its reference point I don't mean that with *broken*. I mean that it's unusable, given that the values you put inside this function don't correspond to anything that you can measure. Then, pretty random values. Please note that this doesn't happen with \override SomeGrob.X/Y-offset. In that case, you can measure the offset with a ruler (in a very uncomfortable way, though, given that you have to offset the ruler as well with the ref point of the grob). Yes, this is true. Because when you \override you replace the unpure-pure-container estimate function with a fixed constant value. \offset adds a fixed constant value to the existing result, which is an *estimate* rather than an actual value in the case of a Y-offset whose default value is a unpure-pure-container function. The fact that you are offsetting an estimate leads to random values, since the difference between the estimate and the actual value is not predictable before completing the spacing algorithm. Thanks, Carl
Re: Distance of a grob from its reference point
I don't mean that with *broken*. I mean that it's unusable, given that the values you put inside this function don't correspond to anything that you can measure. Then, pretty random values. Please note that this doesn't happen with \override SomeGrob.X/Y-offset. In that case, you can measure the offset with a ruler (in a very uncomfortable way, though, given that you have to offset the ruler as well with the ref point of the grob). Thanks, Paolo On Wed, Jan 15, 2020 at 11:55 PM Carl Sorensen wrote: > > > > > *From: *Paolo Prete > *Date: *Wednesday, January 15, 2020 at 2:30 PM > *To: *Carl Sorensen > *Cc: *Lilypond-User Mailing List > *Subject: *Re: Distance of a grob from its reference point > > > > Then, do you agree that this causes that the \offset command is broken at > least for the X/Y-offset properties of any grob? > > > > It depends on what you mean by “broken”. If you mean it doesn’t give an > offset from what the final position would be without the \offset command, > yes, it’s broken for Y-offset of any grob whose Y-offset is a an > unpure-pure container. > > > > Please correct me if I'm wrong. I would be very happy to see a solution or > an alternative for making *fine tuning* while preserving the > avoid-collisions algo. > > In addition, I wonder if is there a way to get the final positioning (and > then the actual distance from the reference point) by overriding some stuff > in the .scm code. This is how I generated the html file instead of the svg > one. > > There is not, as far as I know. > > > > Carl > > > >
Re: Distance of a grob from its reference point
From: Paolo Prete Date: Wednesday, January 15, 2020 at 2:30 PM To: Carl Sorensen Cc: Lilypond-User Mailing List Subject: Re: Distance of a grob from its reference point Then, do you agree that this causes that the \offset command is broken at least for the X/Y-offset properties of any grob? It depends on what you mean by “broken”. If you mean it doesn’t give an offset from what the final position would be without the \offset command, yes, it’s broken for Y-offset of any grob whose Y-offset is a an unpure-pure container. Please correct me if I'm wrong. I would be very happy to see a solution or an alternative for making *fine tuning* while preserving the avoid-collisions algo. In addition, I wonder if is there a way to get the final positioning (and then the actual distance from the reference point) by overriding some stuff in the .scm code. This is how I generated the html file instead of the svg one. There is not, as far as I know. Carl
Re: Distance of a grob from its reference point
In other words, this means: "if you are lucky enough that the position estimated by Lilypond is the same that you have in mind, offset will offset to the quantity that you want. Otherwise it will led to improper placement (because it will mix the value that it has in mind, with the value that you have in mind)". Given that you obviously don't know what Lilypond estimates (and Lilypond doesn't know as well what you estimates) this ends in forcing the user to make improper trial and error procedures, with random values. Again: please, correct me if I am wrong. I would be *really* happy to find a way to use this properties. They are essential for the automatic avoid-collision algos. On Wed, Jan 15, 2020 at 10:57 PM Paolo Prete wrote: > I quote Carl's words: > > "So offset applies to the *estimated* position, and then the spacing > engine works on the offset+estimated postion and ends up putting things > where it thinks they belong" > > I checked that with the examples made before and it seems absolutely true. > > Then: you have to offset an estimated position. How could you do that if > you don't know this estimated position? > > Best, > P > > > > > > > > > On Wed, Jan 15, 2020 at 10:46 PM Aaron Hill > wrote: > >> On 2020-01-15 1:21 pm, Paolo Prete wrote: >> > Without a proper behavior of the "\offset" command you cannot do nor >> > the >> > automatic 2) placement, nor a fine tuning. >> >> What is "proper behavior" for \offset to you? It is my understanding >> \offset works precisely as documented, but that is a worthless metric if >> the documented behavior is not what people need of a tool. >> >> >> -- Aaron Hill >> >>
Re: Slurs in alternate endings
On 2020-01-15 11:19 am, Pastor Jim Neubauer wrote: I have an alternative ending that includes a slur. I know there is a \repeatTie command for ties across alternate endings, but is there anything as simple for slurs? Do you have a MWE you can provide along with possibly a picture or description of what you want? Absent of that, we have to guess and are likely to get things wrong. The LSR has a snippet [1] that could be relevant. [1]: http://lsr.di.unimi.it/LSR/Item?id=613 -- Aaron Hill
Re: Distance of a grob from its reference point
I quote Carl's words: "So offset applies to the *estimated* position, and then the spacing engine works on the offset+estimated postion and ends up putting things where it thinks they belong" I checked that with the examples made before and it seems absolutely true. Then: you have to offset an estimated position. How could you do that if you don't know this estimated position? Best, P On Wed, Jan 15, 2020 at 10:46 PM Aaron Hill wrote: > On 2020-01-15 1:21 pm, Paolo Prete wrote: > > Without a proper behavior of the "\offset" command you cannot do nor > > the > > automatic 2) placement, nor a fine tuning. > > What is "proper behavior" for \offset to you? It is my understanding > \offset works precisely as documented, but that is a worthless metric if > the documented behavior is not what people need of a tool. > > > -- Aaron Hill > >
Re: Distance of a grob from its reference point
On 2020-01-15 1:21 pm, Paolo Prete wrote: Without a proper behavior of the "\offset" command you cannot do nor the automatic 2) placement, nor a fine tuning. What is "proper behavior" for \offset to you? It is my understanding \offset works precisely as documented, but that is a worthless metric if the documented behavior is not what people need of a tool. -- Aaron Hill
Re: Distance of a grob from its reference point
Then, do you agree that this causes that the \offset command is broken at least for the X/Y-offset properties of any grob? Please correct me if I'm wrong. I would be very happy to see a solution or an alternative for making *fine tuning* while preserving the avoid-collisions algo. In addition, I wonder if is there a way to get the final positioning (and then the actual distance from the reference point) by overriding some stuff in the .scm code. This is how I generated the html file instead of the svg one. Thanks for your help, Paolo On Wed, Jan 15, 2020 at 4:52 AM Carl Sorensen wrote: > > > > > *From: *Paolo Prete > *Date: *Tuesday, January 14, 2020 at 8:10 PM > *To: *Aaron Hill > *Cc: *Lilypond-User Mailing List > *Subject: *Re: Distance of a grob from its reference point > > > > > > > > > > I really can't count how many times I had to to that in so many scores. > And there's no way to do that automagically. Really no way. > > Otherwise I would not have asked what I'm asking. > > Then I'm forced to use the extra-offset property for now. > > Hope that someone could solve this issue. I'm sure there's a way for doing > that, without changing the code and whole Lilypond would have a great > benefit from it. > > > > I’m sure that within the current code base there is no way to solve this > issue in the means you have proposed. When the Y-offset property of a grob > is an unpure-pure-container, final positioning is done **after** \offset > is applied to the unpure-pure-container value. And then collision > avoidance is applied, along with “automagic” placement. So the only way to > solve this problem with the current code base is to use extra-offset. But > then you also get to do your own collision avoidance. > > > > I’m sorry, but I think this is the current state of LilyPond’s placement > algorithms. And that’s why I prefer to find ways to tweak the placement > algorithms, as opposed to tweaking the grobs. > > > > Thanks, > > > > Carl > > >
Slurs in alternate endings
I have an alternative ending that includes a slur. I know there is a \repeatTie command for ties across alternate endings, but is there anything as simple for slurs?
Re: Distance of a grob from its reference point
Hi Aaron,
I apologize too if I'm going to use words that can appear a bit rude. This
is only for making the goal clearer, and I state again that without your
great help I could not do my editor.
Now: there's a misunderstanding in your reply too.
I'm not focusing on the *manual* tweaking. The opposite is true: I'm
focusing on the *automatic* tweaking.
It appears to me that you all are convinced that I want to bypass this
Lilypond feature in order to make a WYSIWYG editor.
That's absolutely false. WYSIWYG editors are IMHO too much time consuming.
Then I want to put in my editor the automatic algos of Lilypond. X/Y-offset
is one of them. I'm not interested in *manual* shifting the brackets. My
editor already does that with the extra-offset properties, and it works.
Instead, I'm focusing on the automatic placement of the other near objects
as a consequence ("avoid collisions method"). Doing that manually is very
tedious and I want to avoid it.
Don't interpret the thread as a "automatic vs manual placement method*;
instead see it as "automatic 1) vs automatic 2) placement".
In addition: you say that you disagree that everyone has to do fine tuning.
I think that the important thing is to make not me or you to do fine
tuning. The important thing is to allow *Lilypond* to make it, if required.
It would be really a waste that a so wonderful tool can't accomplish that
only because a dummy value is not pulled out.
Without a proper behavior of the "\offset" command you cannot do nor the
automatic 2) placement, nor a fine tuning.
Best,
Paolo
It seems
(I apologize if that
is coming across sarcastically, but I am afraid I lack better
wordsmithing.)
On Wed, Jan 15, 2020 at 4:50 AM Aaron Hill wrote:
> On 2020-01-14 7:10 pm, Paolo Prete wrote:
> > On Tue, Jan 14, 2020 at 9:08 PM Aaron Hill
> > wrote:
> >> I am not connected to the world of modern notation, but I
> >> cannot envision any musical meaning for the exact vertical position of
> >> an OttavaBracket.
> >
> > This is not true. There are many and many cases in which you need to
> > tune
> > the position of the ottava bracket as well as any other bracket.
> > And I'm not talking about modern notation. Even in nineteenth century
> > notation this is absolutely necessary.
> > The first obvious example is when you have slurs near brackets. Which
> > happen *very frequently*
> > In this cases a common algo is to:
> >
> > 1) choose which of the two objects has to be placed above (there's not
> > a
> > rule for that: it depends on aesthetical choices)
>
> That was what I suspected. This is aesthetics, not semantics. The
> vertical position of a bracket carries no musical intention; unlike how
> the vertical position of a note head relates to pitch. In my mind,
> LilyPond syntax is largely about communicating the musical content and
> letting the software deal with putting the right ink on the page in the
> right spot.
>
> That is not to say that aesthetics does not matter, and LilyPond should
> strive to meet what is generally considered good and pleasing to the
> eye. But in order for aesthetics to be codified, one just needs to
> surface all of the important aspects and constraints, and it sounds like
> LilyPond does not yet have that level of information. As such, you are
> finding it necessary to step in and shift things around.
>
> Side note: I should be clear that I am not "against" the prospect of
> manual tweaking tools. Even if it were just your life that was made
> easier--and it is clear you are not the only one who would benefit--then
> such tools are justified. But my view and practice of software
> engineering is largely focused on automation and getting the computer to
> do the heavy lifting. I dislike manual tweaking, as I have wasted away
> many hours on such details. For my own sanity and productivity, I have
> to restrain myself. As such, I very much need LilyPond to be able to
> make the smart decisions on my behalf. That is why I am trying to
> defend getting the automatic parts working better; but I need to be more
> mindful to not hinder progress on the manual parts.
>
> > 2) move them according to decision 1) and then *tune* their coordinates
> > (which is tedious even with WYSIWYG editors, and requires
> > trial-and-error
> > even with them!).
> > Please note that you can't simply say: "ok, let's move this up and this
> > down and all is done". You have to make heavy micro-tuning as a
> > consequence.
>
> I would disagree with the notion that everyone has to do fine tuning. I
> certainly do nothing of the sort in my work, but I do not work on the
> same type of projects. My needs and requirements are quite likely much
> less strict. When it comes to the matter of manual tweaking, my use
> cases are largely irrelevant. I should, therefore, really bow out of
> this conversation as I am not the target audience and am probably doing
> a better job of muddying the waters.
>
>
> -- Aaron Hill
>
>
Re: Getting readline to work in scheme-sandbox
Do you have "gettext" installed? If not, please install and retry.
Am 15.01.2020 um 18:38 schrieb Knute Snortum:
I didn't get past autogen:
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory guile-readline to autoreconf
autoreconf: Entering directory `guile-readline'
autoreconf: running: aclocal --force
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:18: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:13: installing './install-sh'
configure.ac:13: installing './missing'
Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
(or '*_CPPFLAGS')
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `guile-readline'
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
---
Knute Snortum
(via Gmail)
On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler wrote:
Ok, seems that guile-2.2-libs does not provide libguilereadline...
I think the remaining option is to build guile-1.8 from scratch.
First make sure that you have libreadline-dev installed, then, in your
home directory, do:
git clone -b branch_release-1-8 --single-branch
https://git.savannah.gnu.org/git/guile.git guile-1.8
cd guile-1.8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
make install
ldconfig
If you do not want to install your self-compiled guile-1.8 globally with
"make install" it should be also sufficient to
rename
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
to
libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
/home/knute/guile-1.8/guile-readline/.libs/
in there.
Then try with scheme-sandbox.ly again. Please report if it succeeds now.
Michael
Am 15.01.2020 um 00:05 schrieb Knute Snortum:
I'm not in a vanilla setup, so I changed the commands to: (just for posterity)
$ export
LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
$ strace -o readlinedebug.log
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/bin/lilypond
scheme-sandbox.ly
The log file is attached.
---
Knute Snortum
(via Gmail)
On Tue, Jan 14, 2020 at 8:47 AM Michael Käppler wrote:
This is weird. Seems that strace does not recognize the shebang in the
lilypond script.
Could you please to try to execute the steps in the startup script directly?
I assume you used the vanilla lilypond installer and installed to your
home directory
/home/knute/:
export LD_LIBRARY_PATH="/home/knute/lilypond/usr/lib"
strace -o readlinedebug.log /home/knute/lilypond/usr/bin/lilypond
scheme-sandbox.ly
Am 14.01.2020 um 16:36 schrieb Knute Snortum:
It looks like I get an error in strace. The sandbox is never executed:
execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
0x7ffe4792c428 /* 53 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++
---
Knute Snortum
(via Gmail)
On Mon, Jan 13, 2020 at 10:59 PM Michael Käppler wrote:
Hi Knute,
I'm currently working on this problem. A library called
libguilereadline, that comes with guile,
does provide the interface to the libreadline library. The version we
ship with our packages, however,
seems to be broken somehow.
There are some ways to get around this. Do you have
guile-2.2-libs installed, too?
If installing guile-2.2-libs does not help either, please send me the output
of
strace -o readlinedebug.log lilypond scheme-sandbox.ly
where you type the mentioned commands for activating readline.
Regards,
Michael
Am 14.01.2020 um 01:31 schrieb Knute Snortum:
I recently discovered the scheme-sandbox in LilyPond and I want to get
line editing to
Re: Getting readline to work in scheme-sandbox
I didn't get past autogen:
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory guile-readline to autoreconf
autoreconf: Entering directory `guile-readline'
autoreconf: running: aclocal --force
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:18: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:13: installing './install-sh'
configure.ac:13: installing './missing'
Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
(or '*_CPPFLAGS')
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `guile-readline'
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
---
Knute Snortum
(via Gmail)
On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler wrote:
>
> Ok, seems that guile-2.2-libs does not provide libguilereadline...
>
> I think the remaining option is to build guile-1.8 from scratch.
> First make sure that you have libreadline-dev installed, then, in your
> home directory, do:
>
> git clone -b branch_release-1-8 --single-branch
> https://git.savannah.gnu.org/git/guile.git guile-1.8
> cd guile-1.8
> ./autogen.sh
> ./configure --disable-error-on-warning --prefix=/usr/local
> make
> make install
> ldconfig
>
> If you do not want to install your self-compiled guile-1.8 globally with
> "make install" it should be also sufficient to
> rename
> /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
> to
> libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
> /home/knute/guile-1.8/guile-readline/.libs/
> in there.
>
> Then try with scheme-sandbox.ly again. Please report if it succeeds now.
>
> Michael
>
>
>
>
> Am 15.01.2020 um 00:05 schrieb Knute Snortum:
> > I'm not in a vanilla setup, so I changed the commands to: (just for
> > posterity)
> >
> > $ export
> > LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
> > $ strace -o readlinedebug.log
> > /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/bin/lilypond
> > scheme-sandbox.ly
> >
> > The log file is attached.
> >
> > ---
> > Knute Snortum
> > (via Gmail)
> >
> > On Tue, Jan 14, 2020 at 8:47 AM Michael Käppler wrote:
> >> This is weird. Seems that strace does not recognize the shebang in the
> >> lilypond script.
> >> Could you please to try to execute the steps in the startup script
> >> directly?
> >> I assume you used the vanilla lilypond installer and installed to your
> >> home directory
> >> /home/knute/:
> >>
> >> export LD_LIBRARY_PATH="/home/knute/lilypond/usr/lib"
> >> strace -o readlinedebug.log /home/knute/lilypond/usr/bin/lilypond
> >> scheme-sandbox.ly
> >>
> >>
> >>
> >> Am 14.01.2020 um 16:36 schrieb Knute Snortum:
> >>> It looks like I get an error in strace. The sandbox is never executed:
> >>>
> >>> execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
> >>> 0x7ffe4792c428 /* 53 vars */) = -1 ENOEXEC (Exec format error)
> >>> strace: exec: Exec format error
> >>> +++ exited with 1 +++
> >>>
> >>> ---
> >>> Knute Snortum
> >>> (via Gmail)
> >>>
> >>> On Mon, Jan 13, 2020 at 10:59 PM Michael Käppler
> >>> wrote:
> Hi Knute,
> I'm currently working on this problem. A library called
> libguilereadline, that comes with guile,
> does provide the interface to the libreadline library. The version we
> ship with our packages, however,
> seems to be broken somehow.
> There are some ways to get around this. Do you have
> guile-2.2-libs installed, too?
> If installing guile-2.2-libs does not help either, please send me the
> output
> of
>
> strace -o readlinedebug.log lilypond
Re: Getting readline to work in scheme-sandbox
Ok, seems that guile-2.2-libs does not provide libguilereadline...
I think the remaining option is to build guile-1.8 from scratch.
First make sure that you have libreadline-dev installed, then, in your
home directory, do:
git clone -b branch_release-1-8 --single-branch
https://git.savannah.gnu.org/git/guile.git guile-1.8
cd guile-1.8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
make install
ldconfig
If you do not want to install your self-compiled guile-1.8 globally with
"make install" it should be also sufficient to
rename
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
to
libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
/home/knute/guile-1.8/guile-readline/.libs/
in there.
Then try with scheme-sandbox.ly again. Please report if it succeeds now.
Michael
Am 15.01.2020 um 00:05 schrieb Knute Snortum:
I'm not in a vanilla setup, so I changed the commands to: (just for posterity)
$ export
LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
$ strace -o readlinedebug.log
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/bin/lilypond
scheme-sandbox.ly
The log file is attached.
---
Knute Snortum
(via Gmail)
On Tue, Jan 14, 2020 at 8:47 AM Michael Käppler wrote:
This is weird. Seems that strace does not recognize the shebang in the
lilypond script.
Could you please to try to execute the steps in the startup script directly?
I assume you used the vanilla lilypond installer and installed to your
home directory
/home/knute/:
export LD_LIBRARY_PATH="/home/knute/lilypond/usr/lib"
strace -o readlinedebug.log /home/knute/lilypond/usr/bin/lilypond
scheme-sandbox.ly
Am 14.01.2020 um 16:36 schrieb Knute Snortum:
It looks like I get an error in strace. The sandbox is never executed:
execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
0x7ffe4792c428 /* 53 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++
---
Knute Snortum
(via Gmail)
On Mon, Jan 13, 2020 at 10:59 PM Michael Käppler wrote:
Hi Knute,
I'm currently working on this problem. A library called
libguilereadline, that comes with guile,
does provide the interface to the libreadline library. The version we
ship with our packages, however,
seems to be broken somehow.
There are some ways to get around this. Do you have
guile-2.2-libs installed, too?
If installing guile-2.2-libs does not help either, please send me the output
of
strace -o readlinedebug.log lilypond scheme-sandbox.ly
where you type the mentioned commands for activating readline.
Regards,
Michael
Am 14.01.2020 um 01:31 schrieb Knute Snortum:
I recently discovered the scheme-sandbox in LilyPond and I want to get
line editing to work. In scheme-sandbox.ly the comments say:
% One typical thing you might want to put there is
% (use-modules (ice-9 readline))
% (activate-readline)
% in order to activate command line editing for interactive sessions.
I'm assuming that these are commands to type into the sandbox. But
when I do this I get an error:
guile> (use-modules (ice-9 readline))
ERROR: readline is not provided in this Guile installation
ABORT: (misc-error)
When I search for installed packages at the Linux command line, I see this:
libreadline8/eoan,now 8.0-3 amd64 [installed,automatic]
Any idea why readline is not available?
My system is Ubuntu 19.10, Guile is 2.2 and LilyPond is 2.19.83.
---
Knute Snortum
(via Gmail)
