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
<martinrinconbotero@gmail.com> 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 <soundsfromsound@gmail.com>:
>>
>> 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 
>> <antlists@youngman.org.uk>:
>>>
>>> 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