Re: Extending the width of a glissando
Sure, I didn't mean that transforms weren't well-documented. I just suggest a paragraph of NR documentation, possibly linking back to the IR, simply because the kind of technical language we use in IR isn't obvious to understand for most users I would guess (linear transform? complex number? number pair? etc.). But that's a programming tool. There is not much of a point in the NR. And even the level of the EG does not seem to make it much of a good fit there. I think here we lost sight of the starting point of the discussion. We noticed that the documentation for Grob.rotation is wrong, and I asked whether it would make sense to provide both the current behaviour and the behaviour claimed by the documentation. And, if I understood correctly, Jean pointed out that in order to decide that, one would have to look at typical use cases to see which ways of representing a grob rotation might actually be needed. I think it may well be that the current Grob.rotation behaviour is the ideal solution, and that it suffices to make the documentation match the implementation. But if there are use cases that are more naturally served with another representation for rotation/translation, by definition the NR would be the place to explain the corresponding (and to be devised) interface. Lukas
Re: Extending the width of a glissando
Jean Abou Samra writes: > Le 20/09/2021 à 23:55, David Kastrup a écrit : >> Jean Abou Samra writes: >> >>> Le 20/09/2021 à 23:31, David Kastrup a écrit : Jean Abou Samra writes: > Thoughts? One would have to look at the most typical use cases > to decide on an interface. Anything wrong with using a ly:transform? type? It's straightforward to create and manipulate. >>> I had already forgotten about those. Given sufficient >>> documentation, it would probably work well. >> I find in the IR: >> >> -- Function: ly:make-transform xx yx xy yy x0 y0 >> Create a transform. Without options, it is an identity transform. >> Given four arguments XX, YX, XY, and YY, it is a linear transform, >> given six arguments (with X0 and Y0 last), it is an affine >> transform. Transforms can be called as functions on other >> transforms (concatening them) or on points given either as complex >> number or real number pair. See also ‘ly:make-rotation’, >> ‘ly:make-scaling’, and ‘ly:make-translation’. >> >> -- Function: ly:transform? x >> Is X a ‘Transform’ object? >> >> -- Function: ly:transform->list transform >> Convert a transform matrix to a list of six values. Values are XX, >> YX, XY, YY, X0, Y0. >> >> -- Function: ly:make-translation x y >> Make a transform translating by X and Y. If only X is given, it >> can also be a complex number or a pair of numbers indicating the >> offset to use. >> >> -- Function: ly:make-rotation angle center >> Make a transform rotating by ANGLE in degrees. If CENTER is given >> as a pair of coordinates, it is the center of the rotation, >> otherwise the rotation is around (0 . 0). >> >> -- Function: ly:make-scaling scale scaley >> Create a scaling transform from argument SCALE and optionally >> SCALEY. When both arguments are given, they must be real and give >> the scale in X and Y direction. If only SCALE is given, it may >> also be complex to indicate a scaled rotation in the manner of >> complex number rotations, or a pair of reals for specifying >> different scales in X and Y direction like with the first calling >> convention. > > > Sure, I didn't mean that transforms weren't well-documented. > I just suggest a paragraph of NR documentation, possibly linking > back to the IR, simply because the kind of technical language > we use in IR isn't obvious to understand for most users I would > guess (linear transform? complex number? number pair? etc.). But that's a programming tool. There is not much of a point in the NR. And even the level of the EG does not seem to make it much of a good fit there. -- David Kastrup
Re: Extending the width of a glissando
Le 20/09/2021 à 23:55, David Kastrup a écrit : Jean Abou Samra writes: Le 20/09/2021 à 23:31, David Kastrup a écrit : Jean Abou Samra writes: Thoughts? One would have to look at the most typical use cases to decide on an interface. Anything wrong with using a ly:transform? type? It's straightforward to create and manipulate. I had already forgotten about those. Given sufficient documentation, it would probably work well. I find in the IR: -- Function: ly:make-transform xx yx xy yy x0 y0 Create a transform. Without options, it is an identity transform. Given four arguments XX, YX, XY, and YY, it is a linear transform, given six arguments (with X0 and Y0 last), it is an affine transform. Transforms can be called as functions on other transforms (concatening them) or on points given either as complex number or real number pair. See also ‘ly:make-rotation’, ‘ly:make-scaling’, and ‘ly:make-translation’. -- Function: ly:transform? x Is X a ‘Transform’ object? -- Function: ly:transform->list transform Convert a transform matrix to a list of six values. Values are XX, YX, XY, YY, X0, Y0. -- Function: ly:make-translation x y Make a transform translating by X and Y. If only X is given, it can also be a complex number or a pair of numbers indicating the offset to use. -- Function: ly:make-rotation angle center Make a transform rotating by ANGLE in degrees. If CENTER is given as a pair of coordinates, it is the center of the rotation, otherwise the rotation is around (0 . 0). -- Function: ly:make-scaling scale scaley Create a scaling transform from argument SCALE and optionally SCALEY. When both arguments are given, they must be real and give the scale in X and Y direction. If only SCALE is given, it may also be complex to indicate a scaled rotation in the manner of complex number rotations, or a pair of reals for specifying different scales in X and Y direction like with the first calling convention. Sure, I didn't mean that transforms weren't well-documented. I just suggest a paragraph of NR documentation, possibly linking back to the IR, simply because the kind of technical language we use in IR isn't obvious to understand for most users I would guess (linear transform? complex number? number pair? etc.).
Re: Extending the width of a glissando
Jean Abou Samra writes: > Le 20/09/2021 à 23:31, David Kastrup a écrit : >> Jean Abou Samra writes: >> >>> Thoughts? One would have to look at the most typical use cases >>> to decide on an interface. >> Anything wrong with using a ly:transform? type? It's straightforward to >> create and manipulate. > > I had already forgotten about those. Given sufficient > documentation, it would probably work well. I find in the IR: -- Function: ly:make-transform xx yx xy yy x0 y0 Create a transform. Without options, it is an identity transform. Given four arguments XX, YX, XY, and YY, it is a linear transform, given six arguments (with X0 and Y0 last), it is an affine transform. Transforms can be called as functions on other transforms (concatening them) or on points given either as complex number or real number pair. See also ‘ly:make-rotation’, ‘ly:make-scaling’, and ‘ly:make-translation’. -- Function: ly:transform? x Is X a ‘Transform’ object? -- Function: ly:transform->list transform Convert a transform matrix to a list of six values. Values are XX, YX, XY, YY, X0, Y0. -- Function: ly:make-translation x y Make a transform translating by X and Y. If only X is given, it can also be a complex number or a pair of numbers indicating the offset to use. -- Function: ly:make-rotation angle center Make a transform rotating by ANGLE in degrees. If CENTER is given as a pair of coordinates, it is the center of the rotation, otherwise the rotation is around (0 . 0). -- Function: ly:make-scaling scale scaley Create a scaling transform from argument SCALE and optionally SCALEY. When both arguments are given, they must be real and give the scale in X and Y direction. If only SCALE is given, it may also be complex to indicate a scaled rotation in the manner of complex number rotations, or a pair of reals for specifying different scales in X and Y direction like with the first calling convention. -- David Kastrup
Re: Extending the width of a glissando
Jean Abou Samra writes: > Thoughts? One would have to look at the most typical use cases > to decide on an interface. Anything wrong with using a ly:transform? type? It's straightforward to create and manipulate. -- David Kastrup
Re: Extending the width of a glissando
Le 20/09/2021 à 23:31, David Kastrup a écrit : Jean Abou Samra writes: Thoughts? One would have to look at the most typical use cases to decide on an interface. Anything wrong with using a ly:transform? type? It's straightforward to create and manipulate. I had already forgotten about those. Given sufficient documentation, it would probably work well.
Re: Extending the width of a glissando
Le 20/09/2021 à 22:02, Lukas-Fabian Moser a écrit : Question to the experts: Am I right in thinking that the documentation is misleading here? That is also my understanding. The rotation property works on a stencil using its own extents, performing the equivalent of ly:stencil-rotate, not ly:stencil-rotate-absolute. After that, LilyPond places the stencil using the newly created extents. The placement on the staff can depend or not on these extents, e.g. that of a Clef won't but that of a Hairpin will. The term “reference point” is a bit ambiguous. LilyPond places every object relative to its parents, displacing it by X-offset and Y-offset. If you are writing an [XY]-offset callback, you might think of the reference point as being the point where the object would be placed if its X-offset and Y-offset were 0. On top of that, the object is drawn using a stencil, which carries its own extents. If you are writing a stencil callback, you can think of the reference point as being the point where a point stencil (having extents '(0 . 0) and '(0 . 0)) would be placed, i.e. taking X-offset and Y-offset into account this time. It is the latter notion that applies here. Yes, exactly. But the one thing the term "reference point" should never mean is "just the object's center". So if the rotation is done with respect to the object's center (and in scaled coordinates such that the object's extents are from -1 to 1) - and this is what happens, as can be seen in the attached file where blue crosses mark the centers of objects, red crosses their respective '(0 . 0) point -, then to describe this as and the x and y coordinates of the point relative to the object’s reference point about which the rotation is to be performed (http://lilypond.org/doc/v2.23/Documentation/notation/rotating-objects.html#rotating-layout-objects) is simply wrong in my opinion. If you agree, I'll try and prepare a MR to change the documentation. I absolutely agree. Please go ahead! Maybe one might consider if it would be nice to have both behaviours: .rotation with respect to the object's center (current behaviour), but also with respect to the the stencil's '(0 . 0). Of course, one can achieve the latter with a bit of scheme code, but maybe a grob property of the form \override Hairpin.rotation-system = #'absolute % offset (0,0) is the stencil's reference point, offset units are in staff spaces \override Hairpin.rotation-system = #'relative % offset (0,0) is the object's center, offset units are such that the object's edges are at +- 1. might be useful? I dunno. In the end, rotation around any point is equivalent to rotation around the center and then some translation. Perhaps it would be more intuitive to tweak the translation directly? One could make the rotation property accept bare numbers instead of 3-element lists, making the rotation center default to '(0 . 0), and then it's a matter of setting X-offset and Y-offset, possibly using \offset to make it relative to the reference point in the sense of the stencil's origin if X/Y-offset were untweaked. Thoughts? One would have to look at the most typical use cases to decide on an interface. Cheers, Jean
Re: Extending the width of a glissando
Question to the experts: Am I right in thinking that the
documentation is misleading here?
That is also my understanding. The rotation property works on a stencil
using its own extents, performing the equivalent of ly:stencil-rotate,
not ly:stencil-rotate-absolute. After that, LilyPond places the stencil
using the newly created extents. The placement on the staff can depend
or not on these extents, e.g. that of a Clef won't but that of a Hairpin
will.
The term “reference point” is a bit ambiguous. LilyPond places every
object relative to its parents, displacing it by X-offset and Y-offset.
If you are writing an [XY]-offset callback, you might think of the
reference point as being the point where the object would be placed
if its X-offset and Y-offset were 0. On top of that, the object is
drawn using a stencil, which carries its own extents. If you are writing
a stencil callback, you can think of the reference point as being
the point where a point stencil (having extents '(0 . 0) and '(0 . 0))
would be placed, i.e. taking X-offset and Y-offset into account
this time. It is the latter notion that applies here.
Yes, exactly. But the one thing the term "reference point" should never
mean is "just the object's center".
So if the rotation is done with respect to the object's center (and in
scaled coordinates such that the object's extents are from -1 to 1) -
and this is what happens, as can be seen in the attached file where blue
crosses mark the centers of objects, red crosses their respective '(0 .
0) point -, then to describe this as
and the x and y coordinates of the point relative to the object’s
reference point about which the rotation is to be performed
(http://lilypond.org/doc/v2.23/Documentation/notation/rotating-objects.html#rotating-layout-objects)
is simply wrong in my opinion.
If you agree, I'll try and prepare a MR to change the documentation.
Maybe one might consider if it would be nice to have both behaviours:
.rotation with respect to the object's center (current behaviour), but
also with respect to the the stencil's '(0 . 0). Of course, one can
achieve the latter with a bit of scheme code, but maybe a grob property
of the form
\override Hairpin.rotation-system = #'absolute % offset (0,0) is the
stencil's reference point, offset units are in staff spaces
\override Hairpin.rotation-system = #'relative % offset (0,0) is the
object's center, offset units are such that the object's edges are at +- 1.
might be useful?
Lukas
\version "2.22"
#(define* (cross x y #:optional (col black) (delta 0.25) (thickness 0.15))
(stencil-with-color
(ly:stencil-add
(make-line-stencil thickness (- x delta) (- y delta) (+ x delta) (+ y delta))
(make-line-stencil thickness (- x delta) (+ y delta) (+ x delta) (- y delta)))
col))
#(define (stencil-overlay stil . overlays)
(ly:stencil-outline (apply ly:stencil-add stil overlays) stil))
showPoints =
#(define-music-function (path) (symbol-list?)
#{
\override $path .stencil =
#(grob-transformer
'stencil
(lambda (grob orig)
(let ((x-ext (ly:stencil-extent orig X))
(y-ext (ly:stencil-extent orig Y)))
(stencil-overlay
orig
(cross (interval-center x-ext) (interval-center y-ext) blue)
(cross 0 0 red)
#})
\score {
\layout {
\showPoints Score.TimeSignature
\showPoints Score.Clef
}
{
% Compare:
% \once \override Score.Clef.rotation = #'(100 0 0)
% \once \override Score.Clef.rotation = #'(90 0 0)
% \once \override Score.Clef.rotation = #'(95 0 0)
\showPoints Hairpin
a4\< d'4\!
\once \showPoints NoteHead
a4\< d'4\!
}
}
\score {
\layout {
\showPoints Score.StaffSymbol
\override Score.StaffSymbol.rotation = #'(30 0 0)
}
\relative {
c'4 d e f | g2 g
}
}
Re: Extending the width of a glissando
Le 20/09/2021 à 17:23, Werner LEMBERG a écrit : If I understand it correctly, the "reference point" of a layout object should be its relative (0,0) coordinate. It is possible to display that point using a small function: [...] It would be very nice if appendix A.8, "The Emmentaler font", could display the metrics boxes as given in the proof output of METAFONT (see image for an example; please ignore the point numbers, which are of no relevance for the question at hand). Maybe a skilled Scheme author could add this, also magnifying the Emmentaler glyphs a bit... Is this the same as the glyph stencil's extents? If so, it should be possible to add \box around \musicglyph in Documentation/en/included/font-table.ly. Jean
Re: Extending the width of a glissando
Le 20/09/2021 à 15:36, Lukas-Fabian Moser a écrit :
Hi Peter,
One thing puzzles me about the documentation when it comes to
placement - it continually refers to the 'reference point' for an
object. I sort of understand what it means, but it doesn't seem to
be defined anywhere. For instance - to rotate a hairpin you have to
specify the co-ordinates of the centre of rotation relative to its
reference point. But where is the reference point for a hairpin? The
start, the middle, the end? (The phrase is also used in other
contests, such as octave placement in NR section 1.1.1, to add to the
confusion).
If I understand it correctly, the "reference point" of a layout object
should be its relative (0,0) coordinate. It is possible to display
that point using a small function:
\version "2.23.4"
showReferencePoint =
#(define-music-function (path) (symbol-list?)
#{
\override $path .stencil =
#(grob-transformer
'stencil
(lambda (grob orig)
(ly:stencil-outline
(ly:stencil-add
orig
(stencil-with-color (make-line-stencil 0.2 -0.5 -0.5 0.5
0.5) red)
(stencil-with-color (make-line-stencil 0.2 -0.5 0.5 0.5
-0.5) red))
orig)))
#})
\layout {
\showReferencePoint Score.TimeSignature
\showReferencePoint Score.Clef
}
{
\showReferencePoint Hairpin
a4\< d'4\!
\once \showReferencePoint NoteHead
a4\< d'4\!
\bar "||"
\showReferencePoint NoteHead
\showReferencePoint DynamicText
c'1\f
\once \override DynamicText.X-offset = 0
% Now the reference point of the "f" is aligned with the reference point
% of the notehead.
c'1\f
\bar "||"
\showReferencePoint Rest
r8
\tweak Y-offset 1 r
}
But I'm a bit wary of the statement in
http://lilypond.org/doc/v2.23/Documentation/notation/rotating-objects.html#rotating-layout-objects
that the .rotate property uses x/y-coordinates relative to the
object's reference point. It rather seems to me (if I read grob.cc and
stencil.cc in the source correctly) that the .rotation property uses
the same coordinate system as ly:stencil-rotate does, namely
(0,0) = center of object
(-1,-1) = lower left corner
(1,1) = upper right corner.
This also explains the example regarding rotating hairpins: -1 0 is
center-left (which also happens to be the reference point of a Hairpin).
(Of course, studying the effect of setting .rotation for a layout
object is complicated by the fact that LilyPond's spacing engine might
move the object around after rotating.)
Question to the experts: Am I right in thinking that the documentation
is misleading here?
That is also my understanding. The rotation property works on a stencil
using its own extents, performing the equivalent of ly:stencil-rotate,
not ly:stencil-rotate-absolute. After that, LilyPond places the stencil
using the newly created extents. The placement on the staff can depend
or not on these extents, e.g. that of a Clef won't but that of a Hairpin
will.
The term “reference point” is a bit ambiguous. LilyPond places every
object relative to its parents, displacing it by X-offset and Y-offset.
If you are writing an [XY]-offset callback, you might think of the
reference point as being the point where the object would be placed
if its X-offset and Y-offset were 0. On top of that, the object is
drawn using a stencil, which carries its own extents. If you are writing
a stencil callback, you can think of the reference point as being
the point where a point stencil (having extents '(0 . 0) and '(0 . 0))
would be placed, i.e. taking X-offset and Y-offset into account
this time. It is the latter notion that applies here.
Best,
Jean
Re: Extending the width of a glissando
> If I understand it correctly, the "reference point" of a layout object > should be its relative (0,0) coordinate. It is possible to display > that point using a small function: [...] It would be very nice if appendix A.8, "The Emmentaler font", could display the metrics boxes as given in the proof output of METAFONT (see image for an example; please ignore the point numbers, which are of no relevance for the question at hand). Maybe a skilled Scheme author could add this, also magnifying the Emmentaler glyphs a bit... Werner
Re: Extending the width of a glissando
Hi Peter,
One thing puzzles me about the documentation when it comes to
placement - it continually refers to the 'reference point' for an
object. I sort of understand what it means, but it doesn't seem to be
defined anywhere. For instance - to rotate a hairpin you have to
specify the co-ordinates of the centre of rotation relative to its
reference point. But where is the reference point for a hairpin? The
start, the middle, the end? (The phrase is also used in other
contests, such as octave placement in NR section 1.1.1, to add to the
confusion).
If I understand it correctly, the "reference point" of a layout object
should be its relative (0,0) coordinate. It is possible to display that
point using a small function:
\version "2.23.4"
showReferencePoint =
#(define-music-function (path) (symbol-list?)
#{
\override $path .stencil =
#(grob-transformer
'stencil
(lambda (grob orig)
(ly:stencil-outline
(ly:stencil-add
orig
(stencil-with-color (make-line-stencil 0.2 -0.5 -0.5 0.5
0.5) red)
(stencil-with-color (make-line-stencil 0.2 -0.5 0.5 0.5
-0.5) red))
orig)))
#})
\layout {
\showReferencePoint Score.TimeSignature
\showReferencePoint Score.Clef
}
{
\showReferencePoint Hairpin
a4\< d'4\!
\once \showReferencePoint NoteHead
a4\< d'4\!
\bar "||"
\showReferencePoint NoteHead
\showReferencePoint DynamicText
c'1\f
\once \override DynamicText.X-offset = 0
% Now the reference point of the "f" is aligned with the reference point
% of the notehead.
c'1\f
\bar "||"
\showReferencePoint Rest
r8
\tweak Y-offset 1 r
}
But I'm a bit wary of the statement in
http://lilypond.org/doc/v2.23/Documentation/notation/rotating-objects.html#rotating-layout-objects
that the .rotate property uses x/y-coordinates relative to the object's
reference point. It rather seems to me (if I read grob.cc and stencil.cc
in the source correctly) that the .rotation property uses the same
coordinate system as ly:stencil-rotate does, namely
(0,0) = center of object
(-1,-1) = lower left corner
(1,1) = upper right corner.
This also explains the example regarding rotating hairpins: -1 0 is
center-left (which also happens to be the reference point of a Hairpin).
(Of course, studying the effect of setting .rotation for a layout object
is complicated by the fact that LilyPond's spacing engine might move the
object around after rotating.)
Question to the experts: Am I right in thinking that the documentation
is misleading here?
Lukas
Re: Extending the width of a glissando
Hello Lukas-Fabian,
Thanks again. I was looking at the wrong place in the documentation. There's a
fine line to be drawn between tweaking and changing a default when you only
want to do it once.
One thing puzzles me about the documentation when it comes to placement - it
continually refers to the 'reference point' for an object. I sort of
understand what it means, but it doesn't seem to be defined anywhere. For
instance - to rotate a hairpin you have to specify the co-ordinates of the
centre of rotation relative to its reference point. But where is the reference
point for a hairpin? The start, the middle, the end? (The phrase is also used
in other contests, such as octave placement in NR section 1.1.1, to add to the
confusion).
Best regards,
Peter
mailto:lilyp...@ptoye.com
www.ptoye.com
-
Sunday, September 19, 2021, 5:10:33 PM, Lukas-Fabian Moser wrote:
> Hi Peter,
> Am 19.09.21 um 18:02 schrieb Peter Toye:
>> I need to extend the width of a glissando so that it's visible. There isn't
>> room between the dot and the accidental for any meaningful symbol. As you
>> can see, I've tried various tweaks but none of them has any effect.
>> \version "2.22.1"
>> \language "english"
>> {
>> \override Glissando.style = #'zigzag
>> % \override Glissando.X-extent = #'( -10 . 10)
>> % \override Glissando.gap = #5
>> % \override SpacingSpanner.shortest-duration-space = #50
>> cs'4. \glissando c'8
>> }
> This is discussed in the manual:
> https://lilypond.org/doc/v2.23/Documentation/notation/spanners.html#using-the-spanner_002dinterface
> Lukas
Re: Extending the width of a glissando
Hi Peter,
Am 19.09.21 um 18:02 schrieb Peter Toye:
I need to extend the width of a glissando so that it's visible. There
isn't room between the dot and the accidental for any meaningful
symbol. As you can see, I've tried various tweaks but none of them has
any effect.
\version "2.22.1"
\language "english"
{
\override Glissando.style = #'zigzag
% \override Glissando.X-extent = #'( -10 . 10)
% \override Glissando.gap = #5
% \override SpacingSpanner.shortest-duration-space = #50
cs'4. \glissando c'8
}
This is discussed in the manual:
https://lilypond.org/doc/v2.23/Documentation/notation/spanners.html#using-the-spanner_002dinterface
Lukas
Extending the width of a glissando
I need to extend the width of a glissando so that it's visible. There isn't
room between the dot and the accidental for any meaningful symbol. As you can
see, I've tried various tweaks but none of them has any effect.
\version "2.22.1"
\language "english"
{
\override Glissando.style = #'zigzag
% \override Glissando.X-extent = #'( -10 . 10)
% \override Glissando.gap = #5
% \override SpacingSpanner.shortest-duration-space = #50
cs'4. \glissando c'8
}
Regards,
Petermailto:lilyp...@ptoye.com
www.ptoye.com
