Dynamics context

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamics context

Martín Rincón Botero
Hello,

I discovered today that my main complain about Lilypond, namely, its default positioning of dynamics, is corrected by using a Dynamics context. After reading Gilberto’s suggestion in an old thread I have complemented Lilypond’s behavior with 

\layout { 
  \context { 
    \Dynamics 
    \override VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
  } 


The result of this combination, which reminds me of the excellent Sibelius’ magnetic layout, is exactly what I want for all dynamics of all instruments in a score and in parts (no piano). I wanted to ask if using the Dynamics context is the simplest way available in Lilypond for achieving this kind of vertically aligned dynamics. The huge drawback of the Dynamics context is that it disrupts the syntax, since dynamics can’t be used next to the first note they’re attached to, but instead they need a separate variable, reducing readability of the actual “music”. I tried as suggested somewhere else to make Lilypond import the music variable in the \new Dynamic while removing the dynamics engraver from the “music”. This is not optimal since a lot of stuff (articulations, text, etc.) are also “imported” by the \new Dynamic context and thus duplicated in print. Is there any way of achieving this by means of overrides or similar that can be applied globally, without having to resort to having to manually define variables full of spacers?

Best regards, 
Martín.
--
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Kieren MacMillan
Hi Martín,

> I wanted to ask if using the Dynamics context is the simplest way available in Lilypond for achieving this kind of vertically aligned dynamics.

I believe so.

> The huge drawback of the Dynamics context is that it disrupts the syntax, since dynamics can’t be used next to the first note they’re attached to, but instead they need a separate variable, reducing readability of the actual “music”.

I imagine three possible ways to solve this problem, while being able to enter all input (notes, dynamics, etc.) in a single variable:

1. Send the variable into two different contexts, one (the "Staff") which strips all dynamic events, and one (the "Dynamics") which contains only dynamic events. It seems like this is what you tried to do, but failed at — perhaps if you include a MWE, we can all work with it and see how it can be improved.

2. Have a mechanism like "\change Staff" which allows you to "push" dynamic events into a separate context (the way that staff changes "pushes" notes into a different staff context).

3. Write an engraver that does the extraction/removal/addition automagically.

I have not put a lot of effort (or even thought) into seeing which of these is even possible in Lilypond… but maybe this thread will inspire the community (including me) to do so?

Best,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Martín Rincón Botero
Hi Kieren,

thank you for your answer. Here a MWE:

\version "2.20.0"

scoreAViolinI = \relative c'' {
r2 r4 d,16-.\p\< dis'-. e-. g-.
fis,4:32->\ff\>^"sul pont." r\! r2
}

\score {
  <<
  \new Voice \with { \remove "Dynamic_engraver" } \scoreAViolinI
    \new Dynamics \scoreAViolinI  >>
 
 \layout {
     \context {
    \Dynamics
    \override VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
  }
  }
}

For I which I get the attached result. Weirdly, with this minimal example I'm also getting a bunch of "script direction not yet known". I don't think that was happening before. Anyways, the visual result is the same I was getting with the full code, with duplicated articulations and text.

Am Mo., 7. Sept. 2020 um 18:27 Uhr schrieb Kieren MacMillan <[hidden email]>:
Hi Martín,

> I wanted to ask if using the Dynamics context is the simplest way available in Lilypond for achieving this kind of vertically aligned dynamics.

I believe so.

> The huge drawback of the Dynamics context is that it disrupts the syntax, since dynamics can’t be used next to the first note they’re attached to, but instead they need a separate variable, reducing readability of the actual “music”.

I imagine three possible ways to solve this problem, while being able to enter all input (notes, dynamics, etc.) in a single variable:

1. Send the variable into two different contexts, one (the "Staff") which strips all dynamic events, and one (the "Dynamics") which contains only dynamic events. It seems like this is what you tried to do, but failed at — perhaps if you include a MWE, we can all work with it and see how it can be improved.

2. Have a mechanism like "\change Staff" which allows you to "push" dynamic events into a separate context (the way that staff changes "pushes" notes into a different staff context).

3. Write an engraver that does the extraction/removal/addition automagically.

I have not put a lot of effort (or even thought) into seeing which of these is even possible in Lilypond… but maybe this thread will inspire the community (including me) to do so?

Best,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]



--

Example.png (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Xavier Scheuer
On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <[hidden email]> wrote:
>
> For I which I get the attached result. Weirdly, with this minimal example I'm also getting a bunch of "script direction not yet known". I don't think that was happening before. Anyways, the visual result is the same I was getting with the full code, with duplicated articulations and text.

Hello Martin,

Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
You might also want to remove "Text_spanner_engraver" if you have TextSpanners in your music.

 \layout {
    \context {
      \Dynamics
      \override VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
      \remove "Script_engraver"
      \remove "Text_engraver"
      % \remove "Text_spanner_engraver"
    }
  }

The list of engravers the Dynamics is built from is documented in the Internals Reference manual.
IR 2.1.7 Dynamics

Cheers,
Xavier

--
Xavier Scheuer <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Martín Rincón Botero
Thank you very much, Xavier. I’ll try that!

On Tue 8. Sep 2020 at 11:58 Xavier Scheuer <[hidden email]> wrote:
On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <[hidden email]> wrote:
>
> For I which I get the attached result. Weirdly, with this minimal example I'm also getting a bunch of "script direction not yet known". I don't think that was happening before. Anyways, the visual result is the same I was getting with the full code, with duplicated articulations and text.

Hello Martin,

Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
You might also want to remove "Text_spanner_engraver" if you have TextSpanners in your music.

 \layout {
    \context {
      \Dynamics
      \override VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
      \remove "Script_engraver"
      \remove "Text_engraver"
      % \remove "Text_spanner_engraver"
    }
  }



The list of engravers the Dynamics is built from is documented in the Internals Reference manual.
IR 2.1.7 Dynamics





Cheers,
Xavier


--
Xavier Scheuer <[hidden email]>



--
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Wols Lists
In reply to this post by Martín Rincón Botero
On 07/09/2020 17:01, Martín Rincón Botero wrote:
> I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics. The huge drawback of the Dynamics context is that it disrupts
> the syntax, since dynamics can’t be used next to the first note they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.

Just to throw my two-pennorth in, while I didn't know about the dynamics
context, I've started separating dynamics out ...

I do band parts, and if the dynamics are replicated across, say, all
trombones I find it easier to have the notes in one variable, the
dynamics in another, and to merge them for each part. Especially as,
although I haven't really been doing scores, I can then merge all the
trombone parts, and the dynamics, to put them on one line of the score.

It's not unusual for different instruments to have different dynamics,
as usually the cornets have the melody in the first section, then the
bass instruments in the trio, often with the middle instruments such as
trombones and euphs having a middle section. So whoever's got the melody
might be ff, with the others p underneath.

At the end of the day, horses for courses and if it doesn't work for you
then fine. But it does work for people like me :-)

Cheers,
Wol

Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Martín Rincón Botero
In reply to this post by Xavier Scheuer
Dear Xavier,

thank you very much again. This works as expected! I also find this solution more powerful than the one suggested in the Snippet Repository http://lsr.di.unimi.it/LSR/Item?id=450. This last command however, preceded with \once, is the one I normally use when manually positioning a dynamic. This command doesn't work anymore if dynamics are sent to the dynamics context. This is something I can live with, since the Dynamics context already provides the result I want for the majority of cases, but I wonder if it's possible to use a similar override/tweak for the one case where a dynamic is not placed to my taste.

Best regards,
Martín.

Am Di., 8. Sept. 2020 um 11:58 Uhr schrieb Xavier Scheuer <[hidden email]>:
On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <[hidden email]> wrote:
>
> For I which I get the attached result. Weirdly, with this minimal example I'm also getting a bunch of "script direction not yet known". I don't think that was happening before. Anyways, the visual result is the same I was getting with the full code, with duplicated articulations and text.

Hello Martin,

Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
You might also want to remove "Text_spanner_engraver" if you have TextSpanners in your music.

 \layout {
    \context {
      \Dynamics
      \override VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
      \remove "Script_engraver"
      \remove "Text_engraver"
      % \remove "Text_spanner_engraver"
    }
  }

The list of engravers the Dynamics is built from is documented in the Internals Reference manual.
IR 2.1.7 Dynamics

Cheers,
Xavier

--
Xavier Scheuer <[hidden email]>



--
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Martín Rincón Botero
In reply to this post by Wols Lists
Hi Wol,

yes, what you mention is indeed a good case for using dynamics in their own variable. The problem comes when using a Dynamics context from an independent dynamics variable for music that by its own nature is not really compatible with that approach, or for which the resulting code looks/feels clumsy. Btw. if you have your dynamics already in a different variable, maybe you could give the Dynamics context a shot! ;-).

Cheers,
Martín. 

Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <[hidden email]>:
On 07/09/2020 17:01, Martín Rincón Botero wrote:
> I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics. The huge drawback of the Dynamics context is that it disrupts
> the syntax, since dynamics can’t be used next to the first note they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.

Just to throw my two-pennorth in, while I didn't know about the dynamics
context, I've started separating dynamics out ...

I do band parts, and if the dynamics are replicated across, say, all
trombones I find it easier to have the notes in one variable, the
dynamics in another, and to merge them for each part. Especially as,
although I haven't really been doing scores, I can then merge all the
trombone parts, and the dynamics, to put them on one line of the score.

It's not unusual for different instruments to have different dynamics,
as usually the cornets have the melody in the first section, then the
bass instruments in the trio, often with the middle instruments such as
trombones and euphs having a middle section. So whoever's got the melody
might be ff, with the others p underneath.

At the end of the day, horses for courses and if it doesn't work for you
then fine. But it does work for people like me :-)

Cheers,
Wol



--
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Paul Scott
In reply to this post by Wols Lists


> On Sep 8, 2020, at 9:03 AM, antlists <[hidden email]> wrote:
>
> On 07/09/2020 17:01, Martín Rincón Botero wrote:
>> I wanted to ask if using the Dynamics context is the simplest way available in Lilypond for achieving this kind of vertically aligned dynamics. The huge drawback of the Dynamics context is that it disrupts the syntax, since dynamics can’t be used next to the first note they’re attached to, but instead they need a separate variable, reducing readability of the actual “music”.
>
> Just to throw my two-pennorth in, while I didn't know about the dynamics context, I've started separating dynamics out ...
>
> I do band parts, and if the dynamics are replicated across, say, all trombones I find it easier to have the notes in one variable, the dynamics in another, and to merge them for each part. Especially as, although I haven't really been doing scores, I can then merge all the trombone parts, and the dynamics, to put them on one line of the score.
>
> It's not unusual for different instruments to have different dynamics, as usually the cornets have the melody in the first section, then the bass instruments in the trio, often with the middle instruments such as trombones and euphs having a middle section. So whoever's got the melody might be ff, with the others p underneath.
>
> At the end of the day, horses for courses and if it doesn't work for you then fine. But it does work for people like me :-)

I do a separate dynamics variables also.  Sometimes there is a complicated sequence of spacings shared between my global and dynamics variables which I put in a separate variable to save typoing.

Stay safe all,

Paul



Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

SoundsFromSound
In reply to this post by Martín Rincón Botero
On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:
Hi Wol,

yes, what you mention is indeed a good case for using dynamics in their own variable. The problem comes when using a Dynamics context from an independent dynamics variable for music that by its own nature is not really compatible with that approach, or for which the resulting code looks/feels clumsy. Btw. if you have your dynamics already in a different variable, maybe you could give the Dynamics context a shot! ;-).

Cheers,
Martín. 

Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <[hidden email]>:
On 07/09/2020 17:01, Martín Rincón Botero wrote:
> I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics. The huge drawback of the Dynamics context is that it disrupts
> the syntax, since dynamics can’t be used next to the first note they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.

Just to throw my two-pennorth in, while I didn't know about the dynamics
context, I've started separating dynamics out ...

I do band parts, and if the dynamics are replicated across, say, all
trombones I find it easier to have the notes in one variable, the
dynamics in another, and to merge them for each part. Especially as,
although I haven't really been doing scores, I can then merge all the
trombone parts, and the dynamics, to put them on one line of the score.

It's not unusual for different instruments to have different dynamics,
as usually the cornets have the melody in the first section, then the
bass instruments in the trio, often with the middle instruments such as
trombones and euphs having a middle section. So whoever's got the melody
might be ff, with the others p underneath.

At the end of the day, horses for courses and if it doesn't work for you
then fine. But it does work for people like me :-)

Cheers,
Wol



--

Martín,

I'm curious: what would you say the pros/cons are for using a dynamics context vs. a separate dynamics variable in your input files? (which scenario to use which, etc) -- is it alignment concerns?


composer | sound designer | asmr artist
LilyPond video tutorials: http://bit.ly/LearnLilyPond
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Paul Scott


On Sep 8, 2020, at 11:50 AM, Ben <[hidden email]> wrote:

On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:

(snip)



--

Martín,

I'm curious: what would you say the pros/cons are for using a dynamics context vs. a separate dynamics variable in your input files? (which scenario to use which, etc) -- is it alignment concerns?


This may have been said but I believe a dynamic variable can be in a dynamic context.

Paul



Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Martín Rincón Botero
In reply to this post by SoundsFromSound
Hey Ben,

good question. I write contemporary classical music. In my score, for example, I have an independent tempo variable as a workaround for the current Lilypond lack of "tempo spanners" like rit., accel., etc. I merge this together in the score, and in the parts. Though not ideal, this is a minor inconvenience, since tempi are not something that changes so often, not even in CCM. But dynamics are something that changes very quickly. In my music, it's not seldom to see four dynamics in one measure. An independent dynamics variable full of spacers is thus cumbersome, since the variable where the actual music is, would have to be stripped of dynamics information, or I would have to remove the dynamics engraver and duplicate the corresponding dynamics to the variable full of spacers. With whatever option, when writing a new phrase, I would have to write everything in the music variable and then go to the dynamics variable, count the rhythms (which often includes tuplets) and add the dynamics. This is not really an efficient way to compose! :-). The music variable wouldn't look as readable to me without the dynamics. Lilypond's syntax is basically its "interface", and an independent dynamics variable, if not used as such (see the case of band music above), reduces "usability", in my opinion. So I would say the only pro of using a separate dynamic variable is that you can reuse a dynamic variable. The same can be said of basically every variable. For the sake of keeping a more readable syntax, though, in case I would really need to call the same dynamics (even in concert band music!), I would rather put my music with its normal syntax, make it into a section variable and call the section variables from a dynamics context, using the technique described by Xavier. That way the Lilypond syntax can remain unaffected.

As for what I started using the dynamics context, yes, it is alignment concerns. Lilypond's default behavior of making dynamics only aware of crescendi/decrescendi is not ideal.

Cheers,
Martín.

Am Di., 8. Sept. 2020 um 20:52 Uhr schrieb Ben <[hidden email]>:
On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:
Hi Wol,

yes, what you mention is indeed a good case for using dynamics in their own variable. The problem comes when using a Dynamics context from an independent dynamics variable for music that by its own nature is not really compatible with that approach, or for which the resulting code looks/feels clumsy. Btw. if you have your dynamics already in a different variable, maybe you could give the Dynamics context a shot! ;-).

Cheers,
Martín. 

Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <[hidden email]>:
On 07/09/2020 17:01, Martín Rincón Botero wrote:
> I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics. The huge drawback of the Dynamics context is that it disrupts
> the syntax, since dynamics can’t be used next to the first note they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.

Just to throw my two-pennorth in, while I didn't know about the dynamics
context, I've started separating dynamics out ...

I do band parts, and if the dynamics are replicated across, say, all
trombones I find it easier to have the notes in one variable, the
dynamics in another, and to merge them for each part. Especially as,
although I haven't really been doing scores, I can then merge all the
trombone parts, and the dynamics, to put them on one line of the score.

It's not unusual for different instruments to have different dynamics,
as usually the cornets have the melody in the first section, then the
bass instruments in the trio, often with the middle instruments such as
trombones and euphs having a middle section. So whoever's got the melody
might be ff, with the others p underneath.

At the end of the day, horses for courses and if it doesn't work for you
then fine. But it does work for people like me :-)

Cheers,
Wol



--

Martín,

I'm curious: what would you say the pros/cons are for using a dynamics context vs. a separate dynamics variable in your input files? (which scenario to use which, etc) -- is it alignment concerns?




--
Reply | Threaded
Open this post in threaded view
|

Re: Dynamics context

Knute Snortum
Here is an example of using custom dynamic spanners in the Dynamic Context:

%%%
\version "2.20.0"

rh = \relative c' {
  c4 c c c|
  d4^\mf d d d|
}

lh = \relative c {
  \clef bass
  f4_\mp f f f |
  g4 g g g |
}

dyn = \relative {
  s4\ff s s s\pp |
  \override TextSpanner.bound-details.left.text = "rit."
  s4\startTextSpan s s s\stopTextSpan |
}

\score {
  <<
    \new Staff \rh
    \new Dynamics \dyn
    \new Staff \lh
  >>
}
%%%

It also shows my take on how to use dynamics, with some of them being
on the Dynamic Context and the others, if needed, on the Staff.  I
transcribe mostly piano music and this works well for me, but YMMV.
---
Knute Snortum
(via Gmail)


---
Knute Snortum
(via Gmail)


On Tue, Sep 8, 2020 at 12:16 PM Martín Rincón Botero
<[hidden email]> wrote:

>
> Hey Ben,
>
> good question. I write contemporary classical music. In my score, for example, I have an independent tempo variable as a workaround for the current Lilypond lack of "tempo spanners" like rit., accel., etc. I merge this together in the score, and in the parts. Though not ideal, this is a minor inconvenience, since tempi are not something that changes so often, not even in CCM. But dynamics are something that changes very quickly. In my music, it's not seldom to see four dynamics in one measure. An independent dynamics variable full of spacers is thus cumbersome, since the variable where the actual music is, would have to be stripped of dynamics information, or I would have to remove the dynamics engraver and duplicate the corresponding dynamics to the variable full of spacers. With whatever option, when writing a new phrase, I would have to write everything in the music variable and then go to the dynamics variable, count the rhythms (which often includes tuplets) and add the dynamics. This is not really an efficient way to compose! :-). The music variable wouldn't look as readable to me without the dynamics. Lilypond's syntax is basically its "interface", and an independent dynamics variable, if not used as such (see the case of band music above), reduces "usability", in my opinion. So I would say the only pro of using a separate dynamic variable is that you can reuse a dynamic variable. The same can be said of basically every variable. For the sake of keeping a more readable syntax, though, in case I would really need to call the same dynamics (even in concert band music!), I would rather put my music with its normal syntax, make it into a section variable and call the section variables from a dynamics context, using the technique described by Xavier. That way the Lilypond syntax can remain unaffected.
>
> As for what I started using the dynamics context, yes, it is alignment concerns. Lilypond's default behavior of making dynamics only aware of crescendi/decrescendi is not ideal.
>
> Cheers,
> Martín.
>
> Am Di., 8. Sept. 2020 um 20:52 Uhr schrieb Ben <[hidden email]>:
>>
>> On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:
>>
>> Hi Wol,
>>
>> yes, what you mention is indeed a good case for using dynamics in their own variable. The problem comes when using a Dynamics context from an independent dynamics variable for music that by its own nature is not really compatible with that approach, or for which the resulting code looks/feels clumsy. Btw. if you have your dynamics already in a different variable, maybe you could give the Dynamics context a shot! ;-).
>>
>> Cheers,
>> Martín.
>>
>> Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <[hidden email]>:
>>>
>>> On 07/09/2020 17:01, Martín Rincón Botero wrote:
>>> > I wanted to ask if using the Dynamics context is the simplest way
>>> > available in Lilypond for achieving this kind of vertically aligned
>>> > dynamics. The huge drawback of the Dynamics context is that it disrupts
>>> > the syntax, since dynamics can’t be used next to the first note they’re
>>> > attached to, but instead they need a separate variable, reducing
>>> > readability of the actual “music”.
>>>
>>> Just to throw my two-pennorth in, while I didn't know about the dynamics
>>> context, I've started separating dynamics out ...
>>>
>>> I do band parts, and if the dynamics are replicated across, say, all
>>> trombones I find it easier to have the notes in one variable, the
>>> dynamics in another, and to merge them for each part. Especially as,
>>> although I haven't really been doing scores, I can then merge all the
>>> trombone parts, and the dynamics, to put them on one line of the score.
>>>
>>> It's not unusual for different instruments to have different dynamics,
>>> as usually the cornets have the melody in the first section, then the
>>> bass instruments in the trio, often with the middle instruments such as
>>> trombones and euphs having a middle section. So whoever's got the melody
>>> might be ff, with the others p underneath.
>>>
>>> At the end of the day, horses for courses and if it doesn't work for you
>>> then fine. But it does work for people like me :-)
>>>
>>> Cheers,
>>> Wol
>>>
>>
>>
>> --
>> www.martinrinconbotero.com
>>
>> Martín,
>>
>> I'm curious: what would you say the pros/cons are for using a dynamics context vs. a separate dynamics variable in your input files? (which scenario to use which, etc) -- is it alignment concerns?
>>
>>
>
>
> --
> www.martinrinconbotero.com