[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamics context

From: Knute Snortum
Subject: Re: Dynamics context
Date: Tue, 8 Sep 2020 14:37:05 -0700

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
<> 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 <>:
>> 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 
>> <>:
>>> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]