Re: self-alignment-X has negligible effects on dynamics
Time to get back to work! :)
2014-07-28 23:33 GMT+02:00 Trevor Daniels t.dani...@treda.co.uk:
If your code changes necessitate a change to the documentation and you
haven't done this yourself, please add an issue to the tracker explaining
what changes and/or additions need to be made to the documentation at
the time the code change is pushed. Remember at the time you push
your changes it is likely that you are the only one who understands what
the implications are re the documentation. It is unlikely any doc editor
will pick this up otherwise.
Yes, you're right. I should have opened an issue after pushing code
for issue 3978.
Anyway, i'm going to wait until we decide how the alignment stuff
should work, and when the new version of the code is approved, i'll
write a doc draft with usage examples, leaving it to the doc writers
to polish it up. That should be an efficient use of both my time and
doc writers' time.
2014-07-28 23:56 GMT+02:00 David Nalesnik david.nales...@gmail.com:
Hi Janek,
On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł janek.lilyp...@gmail.com
wrote:
{
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
\override DynamicText.self-alignment-X = #RIGHT
c'4\f
\override DynamicText.self-alignment-X = #LEFT
c'4\f
\override DynamicText.self-alignment-X = #CENTER
c'4\f
}
will produce different output before and after my patch. That's
because before my patch DynamicTexts' position was calculated from
x-aligned-on-self AND centered-on-x-parent, in a way that was opaque
and not configurable by the user. Of course, it's possible to mimic
old behaviour.
Are you referring to that ly:make-simple-closure stuff which was commonly
found in X-offset callbacks? If so, I don't think this was ever the setting
for DynamicText.X-offset. At least, in 2.18.2, we have
(X-offset . ,ly:self-alignment-interface::x-aligned-on-self)
And of course in 2.19.10, we have
(X-offset . ,ly:self-alignment-interface::aligned-on-x-parent)
Indeed, that was the default value of the property (i.e what people
could see in scm/define-grobs.scm). But there was also a call to
centered-on-x-parent _hardcoded_ in C++ code. Because of that
hardcoded part, the actual X-offset value was different from what
you'd get just from x-aligned-on-self. Very nasty, i think i lost
half a day looking for the explanation. My patch removed that
hardcoded stuff (at least for dynamics; there's a similar problem with
fingerings but there's something else in the code that prevented me
from making the change there).
2014-07-29 0:58 GMT+02:00 Thomas Morley thomasmorle...@gmail.com:
Well, the output while using 'self-alignment-X with DynamicText _has_ changed.
This needs thoroughly documentation.
And it will likely break some of my custom-functions.
Don't worry, we'll get this fixed so that your functions should
continue to work :)
See https://code.google.com/p/lilypond/issues/detail?id=4036#c14
I uploaded two images for better comparing, with ref-points and
testing TextScript, too:
2.18.0
http://imgur.com/2vcBG3n.png
2.19.11
http://imgur.com/vE8HaSg.png
Thanks!
cheers,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Hi all. yes, i need to update the documentation, and some parts of my patch should be changed to make it more backward-compatible. I'll think about this, but right now i'm still too upset and i don't want to start a flamewar. Please give me several days to calm down. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
self-alignment-X has negligible effects on dynamics
In the following example, the ordinary overrides of self-alignment-X appear
to have no effect on the position pf the dynamics (or an effect I can't
see). Large numbers are needed for an obvious shift.
Is this a bug, or something I'm doing wrong?
\version 2.19.10
{
\override DynamicText.self-alignment-X = #LEFT
c'4\f
\override DynamicText.self-alignment-X = #RIGHT
c'4\f
\override DynamicText.self-alignment-X = #CENTER
c'4\f
\override DynamicText.self-alignment-X = #20
c'4\f
}
Thanks,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Hi,
2014-07-28 16:13 GMT+02:00 David Nalesnik david.nales...@gmail.com:
In the following example, the ordinary overrides of self-alignment-X appear
to have no effect on the position pf the dynamics (or an effect I can't
see). Large numbers are needed for an obvious shift.
Is this a bug, or something I'm doing wrong?
You're misusing self-alignment-X. This feature is *not* for shifting
stuff - it is meant for aligning particular point of an object on a
particular point of its parent. For example, self-alignment-X = #LEFT
means place this object so that its left edge (i.e. left end of
X-extent) is horizontally aligned with its parent's left edge. It
doesn't mean move stuff around. Look:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #RIGHT
% forte's right edge is aligned with notehead's right edge
c'4\f
\override DynamicText.self-alignment-X = #LEFT
% forte's left edge is aligned with notehead's left edge
c'4\f
% forte's center is aligned with notehead's center
\override DynamicText.self-alignment-X = #CENTER
c'4\f
}
% see what happens when we use wider dynamics:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #RIGHT
% forte's right edge is aligned with notehead's right edge
c'2\fff
\override DynamicText.self-alignment-X = #LEFT
% forte's left edge is aligned with notehead's left edge
c'\fff
}
% Using numbers outside [-1, 1] interval for alignment doesn't make
% much sense. What does it mean if self-alignment-X = #5 ? What is
% aligned to what? It's hard to say what this means in English at all.
% Of course, we could use some more alignment options.
% That's exactly what I'm doing in issue 4022.
% With https://code.google.com/p/lilypond/issues/detail?id=4022 ,
% this code will produce output as in the attachment:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #`(,RIGHT . ,LEFT)
% forte's right edge is aligned with notehead's left edge
c'2\f
\override DynamicText.self-alignment-X = #`(,LEFT . ,RIGHT)
% forte's left edge is aligned with notehead's right edge
c'\f
}
% Now, if you want to move stuff around, use X-offset, not
% self-alignment-X:
{
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.X-offset = -2.5
c'2\f
\override DynamicText.X-offset = 1
c'\f
}
% Maybe some day we'll have a more unified interface for both
% moving stuff around and aligning it - i'm working on this - but
% for now these are separate tasks.
% Is this clearer now?
% Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
On Mon, Jul 28, 2014 at 3:17 PM, Janek Warchoł janek.lilyp...@gmail.com
wrote:
Hi,
2014-07-28 16:13 GMT+02:00 David Nalesnik david.nales...@gmail.com:
In the following example, the ordinary overrides of self-alignment-X
appear
to have no effect on the position pf the dynamics (or an effect I can't
see). Large numbers are needed for an obvious shift.
Is this a bug, or something I'm doing wrong?
You're misusing self-alignment-X. This feature is *not* for shifting
stuff - it is meant for aligning particular point of an object on a
particular point of its parent. For example, self-alignment-X = #LEFT
means place this object so that its left edge (i.e. left end of
X-extent) is horizontally aligned with its parent's left edge. It
doesn't mean move stuff around. Look:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #RIGHT
% forte's right edge is aligned with notehead's right edge
c'4\f
\override DynamicText.self-alignment-X = #LEFT
% forte's left edge is aligned with notehead's left edge
c'4\f
% forte's center is aligned with notehead's center
\override DynamicText.self-alignment-X = #CENTER
c'4\f
}
% see what happens when we use wider dynamics:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #RIGHT
% forte's right edge is aligned with notehead's right edge
c'2\fff
\override DynamicText.self-alignment-X = #LEFT
% forte's left edge is aligned with notehead's left edge
c'\fff
}
% Using numbers outside [-1, 1] interval for alignment doesn't make
% much sense. What does it mean if self-alignment-X = #5 ? What is
% aligned to what? It's hard to say what this means in English at all.
% Of course, we could use some more alignment options.
% That's exactly what I'm doing in issue 4022.
% With https://code.google.com/p/lilypond/issues/detail?id=4022 ,
% this code will produce output as in the attachment:
{
% draw boxes around grobs, representing their extents
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.self-alignment-X = #`(,RIGHT . ,LEFT)
% forte's right edge is aligned with notehead's left edge
c'2\f
\override DynamicText.self-alignment-X = #`(,LEFT . ,RIGHT)
% forte's left edge is aligned with notehead's right edge
c'\f
}
% Now, if you want to move stuff around, use X-offset, not
% self-alignment-X:
{
\override DynamicText.stencil =
#(make-stencil-boxer 0.03 0 ly:text-interface::print)
\override NoteHead.stencil =
#(make-stencil-boxer 0.03 0 ly:note-head::print)
\override DynamicText.X-offset = -2.5
c'2\f
\override DynamicText.X-offset = 1
c'\f
}
% Maybe some day we'll have a more unified interface for both
% moving stuff around and aligning it - i'm working on this - but
% for now these are separate tasks.
% Is this clearer now?
This is clearer. Thanks!
What is potentially confusing (and you see how badly I've been confused) is
that the default setting of X-offset has changed.
I'm used to the old behavior
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
gets it back.
I think that this should be made clear in the documentation, if you haven't
already done this!
Sorry for any trouble,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Hi,
2014-07-28 22:51 GMT+02:00 David Nalesnik david.nales...@gmail.com:
What is potentially confusing (and you see how badly I've been confused) is
that the default setting of X-offset has changed.
I'm not sure if i understand. You mean that default X-offset values
for DynamicTexts changed, or that DynamicText.X-offset uses a
different callback now?
I'm used to the old behavior
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
gets it back.
It doesn't, actually. I mean,
{
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
\override DynamicText.self-alignment-X = #RIGHT
c'4\f
\override DynamicText.self-alignment-X = #LEFT
c'4\f
\override DynamicText.self-alignment-X = #CENTER
c'4\f
}
will produce different output before and after my patch. That's
because before my patch DynamicTexts' position was calculated from
x-aligned-on-self AND centered-on-x-parent, in a way that was opaque
and not configurable by the user. Of course, it's possible to mimic
old behaviour.
I think that this should be made clear in the documentation, if you haven't
already done this!
Yes, i should do this (or maybe some doc editor would like to help me?
I would prefer to focus on making further changes in the code).
best,
Janek
PS i may not be able to reply again until tomorrow evening (~18 UTC).
I found that it's harder for me to focus on my day job when i read
LilyPond email in the morning, especially in case of emotionally
involving topics like this one.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Janek Warchoł wrote Monday, July 28, 2014 10:12 PM 2014-07-28 22:51 GMT+02:00 David Nalesnik david.nales...@gmail.com: I think that this should be made clear in the documentation, if you haven't already done this! Yes, i should do this (or maybe some doc editor would like to help me? I would prefer to focus on making further changes in the code). If your code changes necessitate a change to the documentation and you haven't done this yourself, please add an issue to the tracker explaining what changes and/or additions need to be made to the documentation at the time the code change is pushed. Remember at the time you push your changes it is likely that you are the only one who understands what the implications are re the documentation. It is unlikely any doc editor will pick this up otherwise. Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Hi Janek,
On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł janek.lilyp...@gmail.com
wrote:
Hi,
2014-07-28 22:51 GMT+02:00 David Nalesnik david.nales...@gmail.com:
What is potentially confusing (and you see how badly I've been confused)
is
that the default setting of X-offset has changed.
I'm not sure if i understand. You mean that default X-offset values
for DynamicTexts changed, or that DynamicText.X-offset uses a
different callback now?
The default callback has changed.
I'm used to the old behavior
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
gets it back.
It doesn't, actually. I mean,
{
\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self
\override DynamicText.self-alignment-X = #RIGHT
c'4\f
\override DynamicText.self-alignment-X = #LEFT
c'4\f
\override DynamicText.self-alignment-X = #CENTER
c'4\f
}
will produce different output before and after my patch. That's
because before my patch DynamicTexts' position was calculated from
x-aligned-on-self AND centered-on-x-parent, in a way that was opaque
and not configurable by the user. Of course, it's possible to mimic
old behaviour.
Are you referring to that ly:make-simple-closure stuff which was commonly
found in X-offset callbacks? If so, I don't think this was ever the
setting for DynamicText.X-offset. At least, in 2.18.2, we have
(X-offset . ,ly:self-alignment-interface::x-aligned-on-self)
And of course in 2.19.10, we have
(X-offset . ,ly:self-alignment-interface::aligned-on-x-parent)
I think that this should be made clear in the documentation, if you
haven't
already done this!
Yes, i should do this (or maybe some doc editor would like to help me?
I would prefer to focus on making further changes in the code).
best,
Janek
PS i may not be able to reply again until tomorrow evening (~18 UTC).
I found that it's harder for me to focus on my day job when i read
LilyPond email in the morning, especially in case of emotionally
involving topics like this one.
I can imagine. Sorry :(
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Janek Warchoł janek.lilyp...@gmail.com writes: Hi, 2014-07-28 16:13 GMT+02:00 David Nalesnik david.nales...@gmail.com: In the following example, the ordinary overrides of self-alignment-X appear to have no effect on the position pf the dynamics (or an effect I can't see). Large numbers are needed for an obvious shift. Is this a bug, or something I'm doing wrong? You're misusing self-alignment-X. This feature is *not* for shifting stuff - it is meant for aligning particular point of an object on a particular point of its parent. For example, self-alignment-X = #LEFT means place this object so that its left edge (i.e. left end of X-extent) is horizontally aligned with its parent's left edge. The documentation states: 3.2.98 self-alignment-interface --- Position this object on itself and/or on its parent. To this end, the following functions are provided: ‘Self_alignment_interface::[xy]_aligned_on_self’ Align self on reference point, using ‘self-alignment-X’ and ‘self-alignment-Y’. ‘Self_alignment_interface::aligned_on_[xy]_parent’ ‘Self_alignment_interface::centered_on_[xy]_parent’ Shift the object so its own reference point is centered on the extent of the parent User settable properties: . ‘self-alignment-X’ (number) Specify alignment of an object. The value ‘-1’ means left aligned, ‘0’ centered, and ‘1’ right-aligned in X direction. Other numerical values may also be specified. ‘self-alignment-Y’ (number) Like ‘self-alignment-X’ but for the Y axis. Now a number of grobs have their definition of X-offset changed in a manner where they will behave quite differently to previously, and particularly differently with regard to self-alignment-X which previously was used in several cases to only affect the self-alignment with regard to a parent reference point. Compare URL:http://lilypond.org/doc/v2.18/Documentation/notation/aligning-objects#-Self_002daligning-objects-in-both-directions with URL:http://lilypond.org/doc/v2.19/Documentation/notation/aligning-objects#-Self_002daligning-objects-in-both-directions It's not just that the example looks different, the code comments no longer fit either. This is a mechanism that has been _advertised_ for tweaking the positioning. It _still_ is advertised in that manner. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: self-alignment-X has negligible effects on dynamics
Well, the output while using 'self-alignment-X with DynamicText _has_ changed.
This needs thoroughly documentation.
And it will likely break some of my custom-functions.
This will not be a big problem for me, I assume, though maybe others
rely on the old behaviour as well.
I uploaded two images for better comparing, with ref-points and
testing TextScript, too:
2.18.0
http://imgur.com/2vcBG3n.png
2.19.11
http://imgur.com/vE8HaSg.png
(The source-code uses my most recent code for ref-points, which may
not be the same as in openlilylib, is attached.)
All in all I'd vote for the new behaviour, because it seems to be more
logical and consistent to how TextScript is aligned.
Cheers,
Harm
\version 2.18.0
% \version 2.19.11
#(define (add-dot text?)
;; Sets a grob' stencil-property by adding a red dot and an optional text
;; to the actual grob-stencil.
(lambda (grob)
(let* ((layout (ly:grob-layout grob))
(props (layout-extract-page-properties layout))
(font
(ly:paper-get-font layout
(cons '((font-encoding . fetaMusic)) props)))
;; Get the stencil-procedure from ly:grob-basic-properties.
;; If any, use it to create the stencil.
(function (assoc-get 'stencil (ly:grob-basic-properties grob)))
(stencil (if function (function grob) point-stencil))
;; Get the grob-name and create a text-stencil.
;; Read out the y-length for later translate.
(grob-name-proc
(lambda (x) (assq-ref (ly:grob-property x 'meta) 'name)))
(grob-name (grob-name-proc grob))
(grob-string (if (symbol? grob-name)
(symbol-string grob-name)
no name))
(ref-text-stil (grob-interpret-markup grob
(markup
#:with-color red
#:normal-text
#:abs-fontsize 6
(string-append grob-string
(ref-text-stil-length
(interval-length (ly:stencil-extent ref-text-stil Y)))
(grob-string-stil (if text? (grob-interpret-markup grob
(markup
#:with-dimensions '(0 . 0) '(0 . 0)
#:stencil
ref-text-stil))
point-stencil
))
;; Create a red-dot-stencil
(dot (ly:font-get-glyph font dots.dot))
(red-dot (ly:stencil-in-color dot 1 0 0))
(red-dot-length
(interval-length (ly:stencil-extent red-dot X)))
(red-dot-stil
(ly:stencil-translate-axis red-dot (/ red-dot-length -2) X)))
;; If there's a grob with stencil-procedure and a valid stencil is
;; created, add the red-dot-stil and an optional text-stencil.
(if (and function (ly:stencil? stencil) ) ;; and: (grob::is-live? grob) ???
(ly:grob-set-property! grob 'stencil
(ly:stencil-add
stencil
red-dot-stil
(ly:stencil-translate-axis
(ly:stencil-rotate
grob-string-stil
90 0 0)
(/ ref-text-stil-length 2)
X)))
% needs to be here for 2.16.2
#(define-public (symbol-list-or-symbol? x)
(if (list? x)
(every symbol? x)
(symbol? x)))
#(define (add-red-dot-to-grobs override? text? l)
;; Applies @code{(add-dot text?)} via after-line-breaking to the specified
;; grob(s) in @code{l}
;;
;; possible values for l:
;; 'all-grobs (adds red-dots to all grobs, where possible)
;; this will naturally cause collisions,
;; a single grob-name, must be a symbol,
;; a list of grob-names,
;; anything else (returns the unchanged original stencil)
;; TODO: How to apply it once?
(let ((grobs-to-consider
(cond ((eq? l 'all-grobs)
all-grob-descriptions)
((symbol? l)
(list (assoc l all-grob-descriptions)))
((list? l)
(map
(lambda (grob)
(assoc grob all-grob-descriptions))
l))
(else '()
(lambda (context)
(let loop ((x grobs-to-consider))
(if (not (null? x))
(let ((grob-name (caar x)))
(ly:context-pushpop-property
context
grob-name
'after-line-breaking
(if override?
(add-dot text?) '())
)
(loop (cdr x
printRefpointOn =
#(define-music-function (parser location text? s-or-l)
(boolean? symbol-list-or-symbol?)
Adds a red dot (and an optional text) to the stencil's
