Kieren MacMillan <[email protected]> writes: > Hello all, > > I don’t quite understand when a tweak will apply and when it won’t… > > For example, I have an ottavation function for “one-off” octave pops: > > octU_single = { > \once \override Staff.OttavaBracket.stencil = #ly:line-spanner::print > \once \override Staff.OttavaBracket.bound-details = > #`((left . ((X . -1) (Y . 0) (padding . -0.5) (stencil-align-dir-y . > ,0.85))) > (right . ((X . 2) (Y . 0) (padding . -1.5) (text . > ,(make-draw-line-markup (cons 0 -1)))))) > \once \override Staff.OttavaBracket.font-shape = #'roman > \once \override Staff.OttavaBracket.bound-details.left.text = \eightva > \once \override Staff.OttavaBracket.left-bound-info = > #ly:line-spanner::calc-left-bound-info-and-text > \once \override Staff.OttavaBracket.right-bound-info = > #ly:line-spanner::calc-right-bound-info > \ottava #1 > } > > Once this is applied, if I try to add a tweak later (e.g., changing > #’shorten-pair, either “inline” [in the content code] or “externally” > [via the edition-engraver]), it doesn’t seem to apply.*** But I swear > I’ve had [many many] other situations where I _can_ apply a tweak to a > previously-tweaked object.
Those aren't tweaks. They are overrides. I'll assume that you are using a fairly recent version of LilyPond (2.19.28 or later). If you aren't, stuff will behave differently, in particular less predictably. I haven't used the edition engraver yet but I'll assume that it works via overrides rather than tweaks. Overrides establish defaults for the creation of grobs, tweaks are applied afterwards. So an override will always lose to a tweak. Within overrides, we have the special cases of \once \override, \temporary \override, and subproperty overrides. \temporary \override differs from \override in that \override alone has "pop-first" semantics and will first execute a \revert before executing the override, removing any value previously established in this context. \once \override basically consists of a \temporary \override and a corresponding \revert at the end of the time step. These days, \once \override does its bookkeeping independently from non-\once \override, so the corresponding \revert will not accidentally attach itself to anything else. Subproperty overrides all do independent bookkeeping as well. If you override a subproperty override with some more generic property afterwards, the subproperty override will remain masked until reverting the more generic property. Reverts will only match overrides with the same exact property path. Anything else may be temporarily masked by coarser specified overrides but will resurface when the coarser override gets reverted. At any rate: that's all theory. Unless you actually follow up with an example of what you are actually doing which does not work as expected, it will be impossible to tell just what you are doing wrong. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
