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 : > 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 : > Hi Janek, > > > On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł > 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 : > 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
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 ste
Re: self-alignment-X has negligible effects on dynamics
Janek Warchoł writes: > Hi, > > 2014-07-28 16:13 GMT+02:00 David Nalesnik : >> 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 http://lilypond.org/doc/v2.18/Documentation/notation/aligning-objects#-Self_002daligning-objects-in-both-directions> with 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
Hi Janek, On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł wrote: > Hi, > > 2014-07-28 22:51 GMT+02:00 David Nalesnik : > > 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ł wrote Monday, July 28, 2014 10:12 PM > 2014-07-28 22:51 GMT+02:00 David Nalesnik : > >> 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, 2014-07-28 22:51 GMT+02:00 David Nalesnik : > 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
On Mon, Jul 28, 2014 at 3:17 PM, Janek Warchoł wrote: > Hi, > > 2014-07-28 16:13 GMT+02:00 David Nalesnik : > > 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 16:13 GMT+02:00 David Nalesnik : > 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
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