VS: DynamicTextSpanner spacing
Thank you Aaron, it seems to work! But what does stencil mean exactly?
Best,
Erika
Lähettäjä: Aaron Hill
Lähetetty: lauantai 5. maaliskuuta 2022 18.35
Vastaanottaja: Erika Pirnes
Kopio: lilypond-user@gnu.org
Aihe: Re: DynamicTextSpanner spacing
On 2022-03-05 3:49 pm, Erika Pirnes wrote:
> I would like the dotted line of the crescendo to start a bit later and
> end a bit earlier. It is too close to "cresc.", in my opinion at
> least. And sometimes too close to the "f" as well. (A tiny detail, for
> sure, but it looks annoying.) Any ideas?
> [...]
> music = \relative c' {
> \repeat unfold 5{c8 \p \cresc d e f g a b4 c8 \f b c2.}
> }
You will need to play around with the bound-details for the
DynamicTextSpanner:
\version "2.18.2"
\relative c' {
%% The space before the left side of the spanner.
%% (NOTE: This includes the attached stencil.)
%% Default is 0.75; we are adding two units of space.
\override DynamicTextSpanner.bound-details.left.padding = #2.75
%% Since we want the space between the stencil and
%% line, we need to shift the stencil over a bit.
%% Default is (-0.75 . -0.5); we move it left by the
%% same increment we applied to the padding above.
\override DynamicTextSpanner.bound-details
.left.stencil-offset = #'(-2.75 . -0.5)
%% The space after the right side of the spanner.
%% Default is 0.75; we are adding two units of space.
\override DynamicTextSpanner.bound-details.right.padding = #2.75
%% (For debugging only...)
%% Highlight the grob in red for better visibility.
%% Also make the line solid to show its extents clearly.
\override DynamicTextSpanner.color = #red
\override DynamicTextSpanner.dash-fraction = #1
\repeat unfold 5{ c8 \p \cresc d e f g a b4 c8 \f b c2. }
}
-- Aaron Hill
Re: DynamicTextSpanner spacing
On 2022-03-05 3:49 pm, Erika Pirnes wrote:
I would like the dotted line of the crescendo to start a bit later and
end a bit earlier. It is too close to "cresc.", in my opinion at
least. And sometimes too close to the "f" as well. (A tiny detail, for
sure, but it looks annoying.) Any ideas?
[...]
music = \relative c' {
\repeat unfold 5{c8 \p \cresc d e f g a b4 c8 \f b c2.}
}
You will need to play around with the bound-details for the
DynamicTextSpanner:
\version "2.18.2"
\relative c' {
%% The space before the left side of the spanner.
%% (NOTE: This includes the attached stencil.)
%% Default is 0.75; we are adding two units of space.
\override DynamicTextSpanner.bound-details.left.padding = #2.75
%% Since we want the space between the stencil and
%% line, we need to shift the stencil over a bit.
%% Default is (-0.75 . -0.5); we move it left by the
%% same increment we applied to the padding above.
\override DynamicTextSpanner.bound-details
.left.stencil-offset = #'(-2.75 . -0.5)
%% The space after the right side of the spanner.
%% Default is 0.75; we are adding two units of space.
\override DynamicTextSpanner.bound-details.right.padding = #2.75
%% (For debugging only...)
%% Highlight the grob in red for better visibility.
%% Also make the line solid to show its extents clearly.
\override DynamicTextSpanner.color = #red
\override DynamicTextSpanner.dash-fraction = #1
\repeat unfold 5{ c8 \p \cresc d e f g a b4 c8 \f b c2. }
}
-- Aaron Hill
DynamicTextSpanner spacing
I would like the dotted line of the crescendo to start a bit later and end a
bit earlier. It is too close to "cresc.", in my opinion at least. And sometimes
too close to the "f" as well. (A tiny detail, for sure, but it looks annoying.)
Any ideas?
Minimal example below. (The problem with "f" didn't appear without repeting the
passage.)
\version "2.18.2"
music = \relative c' {
\repeat unfold 5{c8 \p \cresc d e f g a b4 c8 \f b c2.}
}
\score{
\new Staff {\music}
\layout{
\context{
\Score
\override DynamicTextSpanner.style = #'dotted-line
\override DynamicLineSpanner.staff-padding = #3
}
}
}
Thank you!
Erika
Re: Setting up classical guitar fingerings
Thanks Valentin, this is useful. Sounds like I'll be back with questions :-) L On Sat, Mar 5, 2022 at 5:46 PM Valentin Petzel wrote: > Hello Luca, > > the design of Lilypond inherently implies that there is no clear border > between users and developers. Lilypond has an user interface, which is > covered > more or less in the docs, an extended interface in scheme, which is not > documented that extensively, and the C++ code that works behind this, > which > barely documented. This means that in the Lilypond-verse it is useful to > speak > Lilypond, Scheme, C++ (and maybe Python), with basic users sitting at the > Lilypond end and developers sitting at the C++ side, with the scheme stuff > hanging in between. > > This means that you as a user can turn into a developer of some sort and > write > code into you Lilypond score that drastically changes how Lilypond does > things > (which is kind of cool). But if you are trying to do this you will often > find > yourself in the situation that you do not know how certain things are > handled > and the docs offer very little support. > > Thus I find it easier to look directly into the code. Lilypond has three > directories of relevant code in it’s source directory: > > → Ly: Which contains code in Lilypond-Language, mostly setting up the > defaults > and music functions and such > → scm: Which contains code in Scheme and contains a decent bit of > Lilypond’s > functionality, at least that part which does not matter that much > performance- > wise > → lily: Which contains the c++-Code, which is the major part of the core > functionality. > > If I’m looking for things I usually grep for these things in these > directories. Eventually you’ll have a good idea where what is sitting. For > example a scheme function like ly:somethingA::somethingB is usually a > callback to the c++ class somethingA, method somethingB. > > In scm you also have the definitions of the default grobs, so if you want > to > know what exact properties a grob has, you can look in define-grobs.scm. > And > similar stuff. > > And if you encounter something you really do not understand, ask the list. > We’ve got some really marvellous people here who appear to know about > everything you might want to know about Lilypond. > > Cheers, > Valentin > > Am Samstag, 5. März 2022, 17:05:22 CET schrieb Luca Fascione: > > I took a "brief" detour where I went and learned a bit about scheme > > Interlude > > FWIW, I don't recall seeing this reference in your resources about > learning > > Scheme, so I'll leave a comment here: > > > > Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme > approx > > in 1996, > > which I thought were extremely well conceived and clear. Certainly more > to > > the point that sicp > > (which is a very interesting approach if you're learning Lisp and sw > > engineering at the same time, > > but I found did not make good use of my pre-acquired understanding of the > > field, and just slowed me down). > > I found the book very easy to follow and I loved that he teaches Scheme > by > > showing a series of gradually > > more accurate implementations of scheme, partially in scheme. Also it > > teaches Scheme in a way that is > > very compatible with other programming languages, that makes it really > easy > > to keep it straight in one's head > > what is new information or different vs what is just the same. > > Unfortunately the several available copies online were never completed, > so > > there are several little bugs, > > missing cross-references and other polish-grade features missing. But I > > thought the juice of the book is certainly excellent. > > > > It seems Prof Wilson has since retired, and various threads on the > internet > > indicate folks are unable to reach him. > > He seems to have done work in the 90's about garbage collection in > > languages. > > > > > > Now that I can follow Scheme source with a certain level of confidence, I > > went back to work on the fingering task, > > and re-read Valentin's code. And thanks again kind sir. > > > > I was thinking again about the idea of instead of pushing the fingering > > "down" (say we're doing \stemsUp) because the beams are too low, > > to push the beams "up" to leave space for the fingering. And I played > for a > > second with Stem.details.beamed-lengths > > (using an override in the .ly file, inbetween the notes) which seems to > > achieve what we need. > > So in order to automate that, I'd like to understand better the execution > > of before-line-break and after-line-break callbacks. > > I'm thinking that I could set up the fingering position in > > Fingering.before-line-break and alter the stem length > > (details.beamed-lengths, being my current thinking) in > > Stem.before-line-break. > > > > Really the question is a meta-question: I can certainly hack at this and > > see what happens, but also how I do help myself learn this better: > > where is the code that handles this stuff
Re: Setting up classical guitar fingerings
Hello Luca, the design of Lilypond inherently implies that there is no clear border between users and developers. Lilypond has an user interface, which is covered more or less in the docs, an extended interface in scheme, which is not documented that extensively, and the C++ code that works behind this, which barely documented. This means that in the Lilypond-verse it is useful to speak Lilypond, Scheme, C++ (and maybe Python), with basic users sitting at the Lilypond end and developers sitting at the C++ side, with the scheme stuff hanging in between. This means that you as a user can turn into a developer of some sort and write code into you Lilypond score that drastically changes how Lilypond does things (which is kind of cool). But if you are trying to do this you will often find yourself in the situation that you do not know how certain things are handled and the docs offer very little support. Thus I find it easier to look directly into the code. Lilypond has three directories of relevant code in it’s source directory: → Ly: Which contains code in Lilypond-Language, mostly setting up the defaults and music functions and such → scm: Which contains code in Scheme and contains a decent bit of Lilypond’s functionality, at least that part which does not matter that much performance- wise → lily: Which contains the c++-Code, which is the major part of the core functionality. If I’m looking for things I usually grep for these things in these directories. Eventually you’ll have a good idea where what is sitting. For example a scheme function like ly:somethingA::somethingB is usually a callback to the c++ class somethingA, method somethingB. In scm you also have the definitions of the default grobs, so if you want to know what exact properties a grob has, you can look in define-grobs.scm. And similar stuff. And if you encounter something you really do not understand, ask the list. We’ve got some really marvellous people here who appear to know about everything you might want to know about Lilypond. Cheers, Valentin Am Samstag, 5. März 2022, 17:05:22 CET schrieb Luca Fascione: > I took a "brief" detour where I went and learned a bit about scheme > Interlude > FWIW, I don't recall seeing this reference in your resources about learning > Scheme, so I'll leave a comment here: > > Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme approx > in 1996, > which I thought were extremely well conceived and clear. Certainly more to > the point that sicp > (which is a very interesting approach if you're learning Lisp and sw > engineering at the same time, > but I found did not make good use of my pre-acquired understanding of the > field, and just slowed me down). > I found the book very easy to follow and I loved that he teaches Scheme by > showing a series of gradually > more accurate implementations of scheme, partially in scheme. Also it > teaches Scheme in a way that is > very compatible with other programming languages, that makes it really easy > to keep it straight in one's head > what is new information or different vs what is just the same. > Unfortunately the several available copies online were never completed, so > there are several little bugs, > missing cross-references and other polish-grade features missing. But I > thought the juice of the book is certainly excellent. > > It seems Prof Wilson has since retired, and various threads on the internet > indicate folks are unable to reach him. > He seems to have done work in the 90's about garbage collection in > languages. > > > Now that I can follow Scheme source with a certain level of confidence, I > went back to work on the fingering task, > and re-read Valentin's code. And thanks again kind sir. > > I was thinking again about the idea of instead of pushing the fingering > "down" (say we're doing \stemsUp) because the beams are too low, > to push the beams "up" to leave space for the fingering. And I played for a > second with Stem.details.beamed-lengths > (using an override in the .ly file, inbetween the notes) which seems to > achieve what we need. > So in order to automate that, I'd like to understand better the execution > of before-line-break and after-line-break callbacks. > I'm thinking that I could set up the fingering position in > Fingering.before-line-break and alter the stem length > (details.beamed-lengths, being my current thinking) in > Stem.before-line-break. > > Really the question is a meta-question: I can certainly hack at this and > see what happens, but also how I do help myself learn this better: > where is the code that handles this stuff and how do I trace the sequence > of events around this stuff? > > I'm looking for a couple one-liner breadcrumbs such as "this section of the > docs" (which I tried to read without much success), > "grep and in the source", it's all in "scm/ filenames>". Vague pointers like that are hopefully all I'll need. > > Many thanks, >
Re: `TextSpanner` vs. `DynamicTextSpanner`
Le 05/03/2022 à 17:19, Werner LEMBERG a écrit : Sometimes, this would be very helpful, yes (see attached image from the last scene of 'Wozzeck'). I guess a possible work-around would be to (ab)use `DynamicTextSpanner` for that. [...] There is also this kind of code: [...] See issue #3176. Very nice, thanks! Maybe this should be added? Definitely, but I really, really have too many projects dragging for months to personally look into it more closely before much time, sorry. On the other hand, if someone wants to do it, I'll be happy to assist. Best, Jean
Re: `TextSpanner` vs. `DynamicTextSpanner`
>> Sometimes, this would be very helpful, yes (see attached image from >> the last scene of 'Wozzeck'). I guess a possible work-around would >> be to (ab)use `DynamicTextSpanner` for that. > > [...] There is also this kind of code: [...] See issue #3176. Very nice, thanks! Maybe this should be added? Werner
Re: Setting up classical guitar fingerings
I took a "brief" detour where I went and learned a bit about scheme Interlude FWIW, I don't recall seeing this reference in your resources about learning Scheme, so I'll leave a comment here: Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme approx in 1996, which I thought were extremely well conceived and clear. Certainly more to the point that sicp (which is a very interesting approach if you're learning Lisp and sw engineering at the same time, but I found did not make good use of my pre-acquired understanding of the field, and just slowed me down). I found the book very easy to follow and I loved that he teaches Scheme by showing a series of gradually more accurate implementations of scheme, partially in scheme. Also it teaches Scheme in a way that is very compatible with other programming languages, that makes it really easy to keep it straight in one's head what is new information or different vs what is just the same. Unfortunately the several available copies online were never completed, so there are several little bugs, missing cross-references and other polish-grade features missing. But I thought the juice of the book is certainly excellent. It seems Prof Wilson has since retired, and various threads on the internet indicate folks are unable to reach him. He seems to have done work in the 90's about garbage collection in languages. Now that I can follow Scheme source with a certain level of confidence, I went back to work on the fingering task, and re-read Valentin's code. And thanks again kind sir. I was thinking again about the idea of instead of pushing the fingering "down" (say we're doing \stemsUp) because the beams are too low, to push the beams "up" to leave space for the fingering. And I played for a second with Stem.details.beamed-lengths (using an override in the .ly file, inbetween the notes) which seems to achieve what we need. So in order to automate that, I'd like to understand better the execution of before-line-break and after-line-break callbacks. I'm thinking that I could set up the fingering position in Fingering.before-line-break and alter the stem length (details.beamed-lengths, being my current thinking) in Stem.before-line-break. Really the question is a meta-question: I can certainly hack at this and see what happens, but also how I do help myself learn this better: where is the code that handles this stuff and how do I trace the sequence of events around this stuff? I'm looking for a couple one-liner breadcrumbs such as "this section of the docs" (which I tried to read without much success), "grep and in the source", it's all in "scm/". Vague pointers like that are hopefully all I'll need. Many thanks, Luca On Mon, Feb 21, 2022 at 6:49 PM Luca Fascione wrote: > Yes exactly, because of how our finger to note relation works, the > enhancement in readability with the indication right at the head is > enormous. > > L > > On Mon, 21 Feb 2022, 18:16 Valentin Petzel, wrote: > >> Sure. I suppose for a guitar person having stacked fingerings on top >> would be >> rather confusing, as there is no monotonic relating between finger and >> pitch. >> As such I suppose guitar people would want to use fingerings with left or >> right >> orientations in chords anyway. >> >> Cheers, >> Valentin >> >> Am Montag, 21. Februar 2022, 17:47:58 CET schrieb Luca Fascione: >> > I suspect we might be saying the same thing, Valentin? >> > >> > I was saying infix can be a bit awkward if you want 'pianist' chord >> > fingering (just a stack of numbers above or below), and that your >> original >> > -1-2-3 reads quite nicely (as in: it's easy to see in your head >> what >> > you will get in the engraving just by looking at the source). So a >> keyboard >> > person wouldn't want to use infix, I don't think >> > >> > Whereas a guitar person might find it more attractive to use > g-3> >> > because it's easier to keep it straight in your head what fingers you >> use >> > on what note that way >> > >> > L >> > >> > On Mon, Feb 21, 2022 at 5:42 PM Valentin Petzel >> wrote: >> > > No, not nescessarily. If we want all Fingerings on top or below there >> is >> > > no real benefit of doing the chord thing. In fact doing that leads to >> the >> > > exact same issue of the fingering for d being next to the other ones. >> > > >> > > Cheers, >> > > Valentin >> > > >> > > 21.02.2022 12:38:40 Luca Fascione : >> > > >> > > But wouldn't you finger that as ? (Didn't check the >> number, >> > > I'm just meaning going infix vs postfix) >> > > >> > > I can see that this idea of mine does have issues for fingering your >> way >> > > around (which seems to me it's more of a fingering atop thing, like >> you >> > > would have in a keyboard score) >> > > >> > > L >> > > >> > > On Mon, 21 Feb 2022, 12:32 Valentin Petzel, >> wrote: >> > >> Hello Luca, >> > >> >> > >> changing the X-parent to the NoteHead would mean that we are >> aligning the >> > >> Fingering horizontally wrt. the
