[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
<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
Re: Dynamics context, Paul Scott, 2020/09/08