TupletNumber placement with fingering
Hello,
When I have a beamed tuplet (without a bracket) and a fingering on one
note, the TupletNumber moves outward from the staff despite there being no
possibility of a collison. In normal usage, TupletNumber should stay as
close as possible to the beam.
Example:
\version "2.22.2"
\relative c
{\tuplet 3/2 { g''8-4 g g } \tuplet 3/2 { c_4 c c } }
Is this the expected behaviour? The fix I have found is increasing the
value of Fingering.outside-staff-priority. Is that the best solution?
Thank you!
Re: Box around system
Jean Abou Samra writes:
> Le 19/05/2022 à 00:56, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 18/05/2022 à 23:58, Jean Abou Samra a écrit :
(say)
\overrideMidBrokenSpanner Context.Grob.property = ...
>>>
>>> Actually, the ideal interface for this is probably a modifier
>>> like \once, \temporary and \single.
>>>
>>> \broken \override Context.Grob.property = ...
>> I am not sure: it seems more natural that breaking any spanner into
>> pieces leaves you with the properties valid at the start of the broken
>> piece, without needing extra instructions.
>>
>> But for doing the equivalent with tweaks, it would be rather tricky to
>> make _that_ information column-dependent as well in some manner. So
>> it's not clear that this leads to something wonderful.
>
>
>
> Allow me to doubt: should the behavior of this piece of code
> really change?
>
> \version "2.22.2"
>
> <<
> \new Staff { c'1\< \break 2 2\! }
> \new Staff { c'1\< \break 2 2\! }
> \new Staff {
> R1
> \override Score.Hairpin.color = red
> g2\< 2\!
> }
> \new Staff {
> R1
> g2\< 2\!
> }
>>>
>
>
> Assuming that it is desirable to make the two upper
> hairpins red in this case, it sounds like a serious
> compatibility issue.
Well, compatibility would definitely end up being a problem. So you may
be right about the \broken qualification being necessary. Which would
severely reduce the performance impact when the feature is not being
used.
--
David Kastrup
Re: Box around system
Le 19/05/2022 à 00:56, David Kastrup a écrit :
Jean Abou Samra writes:
Le 18/05/2022 à 23:58, Jean Abou Samra a écrit :
(say)
\overrideMidBrokenSpanner Context.Grob.property = ...
Actually, the ideal interface for this is probably a modifier
like \once, \temporary and \single.
\broken \override Context.Grob.property = ...
I am not sure: it seems more natural that breaking any spanner into
pieces leaves you with the properties valid at the start of the broken
piece, without needing extra instructions.
But for doing the equivalent with tweaks, it would be rather tricky to
make _that_ information column-dependent as well in some manner. So
it's not clear that this leads to something wonderful.
Allow me to doubt: should the behavior of this piece of code
really change?
\version "2.22.2"
<<
\new Staff { c'1\< \break 2 2\! }
\new Staff { c'1\< \break 2 2\! }
\new Staff {
R1
\override Score.Hairpin.color = red
g2\< 2\!
}
\new Staff {
R1
g2\< 2\!
}
>>
Assuming that it is desirable to make the two upper
hairpins red in this case, it sounds like a serious
compatibility issue.
Re: Box around system
Jean Abou Samra writes: > Le 18/05/2022 à 23:58, Jean Abou Samra a écrit : >> (say) >> \overrideMidBrokenSpanner Context.Grob.property = ... > > > Actually, the ideal interface for this is probably a modifier > like \once, \temporary and \single. > > \broken \override Context.Grob.property = ... I am not sure: it seems more natural that breaking any spanner into pieces leaves you with the properties valid at the start of the broken piece, without needing extra instructions. But for doing the equivalent with tweaks, it would be rather tricky to make _that_ information column-dependent as well in some manner. So it's not clear that this leads to something wonderful. -- David Kastrup
Re: Box around system
Le 18/05/2022 à 23:58, Jean Abou Samra a écrit : (say) \overrideMidBrokenSpanner Context.Grob.property = ... Actually, the ideal interface for this is probably a modifier like \once, \temporary and \single. \broken \override Context.Grob.property = ...
Re: Box around system
Le 18/05/2022 à 22:37, David Kastrup a écrit :
Valentin Petzel writes:
Jean is correct in telling you why your approach does not work. The
system is not something that is created in a certain timestep, but
rather as a single grob at the begin of translation and then broken
down afterward, basically copying the properties of the original
System grob.
That makes for the thought experiment: what would the cost be for
retaining the per-time properties? Essentially one would have to keep a
copy of the grob-properties for each breakable column until the final
breakpoints are established.
How useful would that be? How expensive would that be? Frankly, I am
fuzzy about either. Could it be used as a basis for something like
line-break dependent accident rules?
Could it provide a more user-accessible way of doing things than
\alterBroken ?
Interestingly, our thoughts crossed. It's not unthinkable.
My wonder is whether it is going to be more convenient
than \alterBroken in the general case. With that approach,
if the break points change, you likely need to move your special
overrides around. With the current incarnation of \alterBroken,
you might not need to adjust the invocation at all. You do
need it if the number of broken pieces changes, or if the
override is intrinsically dependent on layout details (e.g.
extra-offset). I don't have enough experience with real-world
use of \alterBroken to judge whether the intuitiveness of (say)
\overrideMidBrokenSpanner Context.Grob.property = ... will offset the
possible inconvenience of having to move this command around.
Here's a hasty and dirty proof of concept, in case anyone wants
to play around with the principle.
\version "2.22.2"
#(set-object-property! 'Broken 'translation-type? ly:grob-properties?)
#(set-object-property! 'Broken 'is-grob? #t)
#(set-object-property! 'broken-info 'backend-type? list?)
#(set-object-property! 'origin-context 'backend-type? ly:context?)
#(define grob-names (map car all-grob-descriptions))
#(for-each
(lambda (name)
(set-object-property! name 'backend-type? scheme?))
grob-names)
\layout {
\context {
\Global
Broken = #(ly:make-grob-properties '())
}
\context {
\Score
\consists
#(lambda (context)
(let ((all-contexts '()))
(make-engraver
(acknowledgers
((grob-interface engraver grob source-engraver)
(let ((grob-context (ly:translator-context source-engraver)))
(set! all-contexts (cons grob-context all-contexts))
(ly:grob-set-property! grob 'origin-context
grob-context
((stop-translation-timestep engraver)
(let ((column (ly:context-property context
'currentCommandColumn)))
(ly:grob-set-property!
column
'broken-info
(map (lambda (ctx)
(cons ctx
(ly:context-grob-definition ctx 'Broken)))
all-contexts)))
\override NonMusicalPaperColumn.after-line-breaking =
#(lambda (column)
(let* ((sys (ly:grob-system column))
(all (ly:grob-array->list (ly:grob-object sys
'all-elements)))
(info (ly:grob-property column 'broken-info)))
(for-each
(lambda (grob)
(if (and (ly:spanner? grob)
(eq? column (ly:spanner-bound grob LEFT)))
(let* ((origin-context (ly:grob-property grob
'origin-context))
(origin-alist (assq-ref info origin-context))
(origin-def (assq-ref origin-alist (grob::name
grob
(if origin-def
(for-each
(lambda (pair)
(ly:grob-set-property! grob
(car pair)
(cdr pair)))
origin-def)
all)))
}
}
{
c'1\<
\break
\override Broken.Hairpin.color = red
1 1\!
}
Jean
Re: Box around system
Valentin Petzel writes: > Jean is correct in telling you why your approach does not work. The > system is not something that is created in a certain timestep, but > rather as a single grob at the begin of translation and then broken > down afterward, basically copying the properties of the original > System grob. That makes for the thought experiment: what would the cost be for retaining the per-time properties? Essentially one would have to keep a copy of the grob-properties for each breakable column until the final breakpoints are established. How useful would that be? How expensive would that be? Frankly, I am fuzzy about either. Could it be used as a basis for something like line-break dependent accident rules? Could it provide a more user-accessible way of doing things than \alterBroken ? -- David Kastrup
Re: Box around system
Le 18/05/2022 à 17:56, Valentin Petzel a écrit : Jean is correct in telling you why your approach does not work. The system is not something that is created in a certain timestep, but rather as a single grob at the begin of translation and then broken down afterward, basically copying the properties of the original System grob. However while it is correct that we cannot use \override on already created grobs we can still change such values as long as we can get a reference to the grob. In this case this is quite easy. The System grob is X parent to the PaperColumn and Y parent to VerticalAlignment and thus an ancestor of pretty much any grob on the page. This means we can use the after-line-breaking callback of a grob to modify the System grob this particular grob is a descendant of. Have a look at the appended file for details. Yes, that works too. FYI, you don't need to code find-parent-system yourself, it's available as ly:grob-system. Also, by design, not pretty much all but absolutely all grobs have a System as ultimate parent on both axes (and it's the same on both axes for each grob). Of course, this doesn't apply during translation, where the parents are in the process of being assigned for each grob. There is also a caveat: ly:grob-system may occasionally fail to give you the system in some cases even though it is there. This mostly applies to the unbroken original grobs. There are also edge cases with those paper columns that are killed because they are unused. Yes, this is suboptimal. (I want to change that eventually but it's part of a larger piece of work on break substitution, which has stalled lately.) Jean
Re: Box around system
Jean is correct in telling you why your approach does not work. The system is
not something that is created in a certain timestep, but rather as a single
grob at the begin of translation and then broken down afterward, basically
copying the properties of the original System grob.
However while it is correct that we cannot use \override on already created
grobs we can still change such values as long as we can get a reference to the
grob. In this case this is quite easy. The System grob is X parent to the
PaperColumn and Y parent to VerticalAlignment and thus an ancestor of pretty
much any grob on the page. This means we can use the after-line-breaking
callback of a grob to modify the System grob this particular grob is a
descendant of.
Have a look at the appended file for details.
Cheers,
Valentin
Am Mittwoch, 18. Mai 2022, 16:02:30 CEST schrieb Jean Abou Samra:
> Le 18/05/2022 à 15:44, Rip _Mus a écrit :
> > Good morning,
> > I really appreciate your solutions and I'm trying to impress box only
> > on some systems of the score.
> > So I'm trying to do something like \once \override
> > Score.System.stencil = ...
> > But there is no response. I've tried also with \overrideProperty, but
> > nothing happens.
> > Do you have any advice for me?
>
> Because there is actually only one system when you do the \override.
> It spans the whole score. You can't \override a grob's properties once
> it has been created, and the System was created at the very beginning.
> It is only much later that it is broken into several smaller systems.
> You could use \alterBroken if it supported callbacks, but it doesn't
> (well, they may or may not work or work partially depending on internal
> details) so you need to do the work yourself:
>
>
> \version "2.22.2"
>
> #(define ((box-system-parts thickness padding parts) grob)
> (let ((my-index (list-index (lambda (g)
> (eq? g grob))
> (ly:spanner-broken-into
> (ly:grob-original grob)
> (if (memv my-index parts)
> (box-stencil
>(ly:make-stencil
> '()
> (ly:grob-extent grob grob X)
> (ly:grob-extent grob grob Y))
>thickness
>padding)
> '(
>
> \layout {
>\context {
> \Score
> \override System.stencil =
>#(box-system-parts
> 0.2 ; thickness
> 0.3 ; padding
> '(0 2 3))
>}
> }
>
> \repeat unfold 5 {
>c'1
>\break
> }
>
>
> Valentin's approach could also be adapted to do this.
>
> Best,
> Jean
%%% DEFINITIONS FOR IMPROVED BOXING (NOT NESCESSARY BUT SPECIFYING THICKNESS AND PADDING WILL NOT WORK WITHOUT THIS!)
#(define*-public ((box-grob-stencil-with-thickness #:optional (thick 0.1) (pad 0)) grob)
(let* ((xext (ly:grob-extent grob grob 0))
(yext (ly:grob-extent grob grob 1))
(xext (interval-widen xext pad))
(yext (interval-widen yext pad)))
(ly:stencil-add
(make-filled-box-stencil (interval-widen xext thick) (cons (- (car yext) thick) (car yext)))
(make-filled-box-stencil (interval-widen xext thick) (cons (cdr yext) (+ (cdr yext) thick)))
(make-filled-box-stencil (cons (cdr xext) (+ (cdr xext) thick)) yext)
(make-filled-box-stencil (cons (- (car xext) thick) (car xext)) yext
#(define-public (box-grob-stencil grob)
(let* ((det (ly:grob-property grob 'details))
(thick (assoc-get 'box-thickness det 0.1))
(pad (assoc-get 'box-padding det 0)))
((box-grob-stencil-with-thickness thick pad) grob)))
%%% DEFINITION FOR BOXING SYSTEMS
#(define (find-parent-system grob)
(if (null? grob)
grob
(if (grob::has-interface grob 'system-interface)
grob
(let ((X-dir (find-parent-system (ly:grob-parent grob X
(if (null? X-dir)
(find-parent-system (ly:grob-parent grob Y))
X-dir)
boxCurrentSystem = <>
-\tweak
after-line-breaking
#(lambda (grob)
(let ((sys (find-parent-system grob)))
(ly:grob-set-property! sys 'stencil box-grob-stencil)))
-\tweak
stencil
##f
-\markup""
boxCurrentSystemWith =
#(define-music-function (thick pad) (number? number?)
#{
<>
-\tweak
after-line-breaking
#(lambda (grob)
(let* ((sys (find-parent-system grob))
(det (ly:grob-property sys 'details))
(det (cons* (cons 'box-thickness thick)
(cons 'box-padding pad)
det)))
(ly:grob-set-property! sys 'stencil box-grob-stencil)
(ly:grob-set-property! sys 'details det)))
-\tweak
stencil
##f
-\markup""
#})
%%% EXAMPLE
{
c1 \break
\boxCurrentSystem
c \break
c \break
\boxCurrentSystemWith #0.4 #1
c
}
signature.asc
Description: This is a digitally signed message part.
Re: Box around system
Le 18/05/2022 à 16:02, Jean Abou Samra a écrit : You could use \alterBroken if it supported callbacks, but it doesn't (well, they may or may not work or work partially depending on internal details) OK, https://gitlab.com/lilypond/lilypond/-/merge_requests/1369
Re: Box around system
Le 18/05/2022 à 15:44, Rip _Mus a écrit :
Good morning,
I really appreciate your solutions and I'm trying to impress box only
on some systems of the score.
So I'm trying to do something like \once \override
Score.System.stencil = ...
But there is no response. I've tried also with \overrideProperty, but
nothing happens.
Do you have any advice for me?
Because there is actually only one system when you do the \override.
It spans the whole score. You can't \override a grob's properties once
it has been created, and the System was created at the very beginning.
It is only much later that it is broken into several smaller systems.
You could use \alterBroken if it supported callbacks, but it doesn't
(well, they may or may not work or work partially depending on internal
details) so you need to do the work yourself:
\version "2.22.2"
#(define ((box-system-parts thickness padding parts) grob)
(let ((my-index (list-index (lambda (g)
(eq? g grob))
(ly:spanner-broken-into
(ly:grob-original grob)
(if (memv my-index parts)
(box-stencil
(ly:make-stencil
'()
(ly:grob-extent grob grob X)
(ly:grob-extent grob grob Y))
thickness
padding)
'(
\layout {
\context {
\Score
\override System.stencil =
#(box-system-parts
0.2 ; thickness
0.3 ; padding
'(0 2 3))
}
}
\repeat unfold 5 {
c'1
\break
}
Valentin's approach could also be adapted to do this.
Best,
Jean
Re: Box around system
Good morning,
I really appreciate your solutions and I'm trying to impress box only on
some systems of the score.
So I'm trying to do something like \once \override Score.System.stencil =
...
But there is no response. I've tried also with \overrideProperty, but
nothing happens.
Do you have any advice for me?
Thank you
Il giorno lun 16 mag 2022 alle ore 08:28 Rip _Mus <
ripetizioni.mus...@gmail.com> ha scritto:
> Hello Valentin,
> thanks a lot!
> This approach is also very useful and sophisticated!
> I will have to decide, sooner or later, to deepen the Scheme side.
>
> Best regards
>
> Il giorno dom 15 mag 2022 alle ore 21:08 Valentin Petzel <
> valen...@petzel.at> ha scritto:
>
>> Hello Jean, hello Rip.
>>
>> instead of imposing this empty stencil I’d extent the original command
>> such
>> that it allows for such things. The appended file does implement a way to
>> call
>> (box-grob-stencil-with-thickness thickness padding) and a way to use the
>> original function but to be able to specify thickness and padding using
>> details.box-thickness and details.box-padding.
>>
>> Cheers,
>> Valentin
>>
>>
>> Am Sonntag, 15. Mai 2022, 11:09:29 CEST schrieb Jean Abou Samra:
>> > Le 15/05/2022 à 10:40, Rip _Mus a écrit :
>> > > Good morning,
>> > > I found this interesting snippet:
>> > > https://lsr.di.unimi.it/LSR/Snippet?id=257
>> > >
>> > > that draws a box around systems.
>> > > According to you, is it possible to specify box line thickness ?
>> > >
>> > > Thank you!
>> > >
>> > > Rip_mus
>> >
>> > It looks like box-grob-stencil does not support this.
>> make-stencil-boxer, on
>> > the other hand, does. It expects a callback yielding a stencil, though,
>> so
>> > you need to define a little function returning a stencil empty of inking
>> > with the grob's extent.
>> >
>> > \version "2.22.2"
>> >
>> > #(define (empty-stencil-from-grob-extents grob)
>> > (ly:make-stencil
>> > '()
>> > (ly:grob-extent grob grob X)
>> > (ly:grob-extent grob grob Y)))
>> >
>> > \layout {
>> >\context {
>> > \Score
>> > \override System.stencil =
>> >% adjust thickness and padding
>> >#(make-stencil-boxer 0.2 0.3 empty-stencil-from-grob-extents)
>> >}
>> > }
>> >
>> > {
>> >\slurDown c4 ( g4 c''4)
>> > }
>> >
>> >
>> > Best,
>> > Jean
>>
>>
Re: Offset ClefTransposition number
Thanks, No comment on the documentation. The fault is on me because I only looked at the internals of the Clef and not the Clef Modifier which was literally the next chapter. It's one of those things I rarely use so I hadn't looked thoroughly at those specific chapters. On Wed, May 18, 2022 at 12:44 AM Jean Abou Samra wrote: > Le 17/05/2022 à 23:38, Jean Abou Samra a écrit : > > There is also the more traditional method of looking at the > > end of the relevant section in the Notation Reference, > > namely in this case: > > > https://lilypond.org/doc/v2.22/Documentation/notation/displaying-pitches#clef > > > > There is always a heading "See also", here it contains > > (among others): "Internals Reference: Clef_engraver, Clef, > > ClefModifier, clef-interface". > > > Oh, and actually, that section is pretty explicit: > > """ > Known issues and warnings > > Ottavation numbers attached to clefs are treated as separate grobs. > So any \override done to the Clef will also need to be applied, as > a separate \override, to the ClefModifier grob. > > [example] > """ > > To be clear, I absolutely don't want to blame anyone asking on the > lists: yes, there is a lot of material in the docs, and it's not > always easy to find your way. I am also the first person to ask > how to improve the docs. In this case, though, I think the documentation > is about as good as you can get ... > > Jean > >
Re: Chord mode: changing N.C.
Carl, thanks for your verbose explanation. This helps understanding
Lilypond "under the hood" more and more!
Stephan
Am 17.05.2022 um 21:58 schrieb Carl Sorensen:
On Tue, May 17, 2022 at 1:26 PM Stephan Schöll wrote:
Hi all
My impression that the mailing list has long delays somewhere
seems to be confirmed... When I post to the mailinglist I don't
get my own post in my inbox for a long time (an hour or so) I will
keep an eye on that. Maybe it's on my side.
Carl, where can I find any documentation for noChordMarkup? The
link you mentioned writes about noChordSymbol (1 occurence on the
english version of the page). Even (my) Google doesn't find
anything about noChordMarkup.
You can't. I typed it wrong because I was working on my phone,
instead of my computer. It is noChordSymbol.
You can read (a little bit) more about noChordSymbol in the Internals
Reference:
https://lilypond.org/doc/v2.22/Documentation/internals/tunable-context-properties
https://lilypond.org/doc/v2.22/Documentation/internals/chordnames
https://lilypond.org/doc/v2.22/Documentation/internals/chord_005fname_005fengraver
You can see where the default value of \markup{"N.C"} is set here :
https://lilypond.org/doc/v2.22/Documentation/internals/score
It's a bit hard to figure out where the default value is set. If you
start with the ChordNames context you see that the Chord_name_engraver
is part of the ChordNames context, and it reads the noChordSymbol
property. You can't find any interfaces to set the noChordSymbol
property, so I just move up in the context hierarchy.
I don't need any other contexts to support a ChordNames context, so I
just look at the Score context.
And there I can see that the noChordSymbol is set to "N.C.". To fix
it I can just set it to some other value, using the \
set command as described in
https://lilypond.org/doc/v2.22/Documentation/notation/overview-of-modifying-properties
I'm sorry about the confusion. I hope this helps.
Carl
