bug-lilypond
[Top][All Lists]
Advanced

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

Re: voiceOne dynamics should go above the staff


From: Mark Polesky
Subject: Re: voiceOne dynamics should go above the staff
Date: Sun, 19 Sep 2010 07:54:21 -0700 (PDT)

Trevor Daniels wrote:
> But a quick look through some of my music shows dynamics
> are more commonly placed above the staff, so I wonder why
> placing them below is the default?  But I don't have any
> instrumental parts to hand - where are the dynamics in
> these usually placed?

Vocal dynamics are usually placed above the staff so they
don't interfere with the lyrics.  Otherwise, dynamics are
usually placed below the staff for monophonic staves, and
for polyphonic staves when the dynamics are the same. But as
Kurt Stone, Ted Ross, and Gardner Read *all* agree,
polyphonic staves with different simultaneous dynamics
require upstem and downstem dynamics to be placed above
*and* below the staff respectively.  Why are we arguing when
the authorities are clear on this?
http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00259.html


Phil Holmes wrote:
> Why should voiceOne dynamics go above the staff?

So they're not mistaken for voiceTwo dynamics!

> I frequently set music only putting the dynamics in one
> voice, and I don't expect that to determine where the
> dynamic goes.

I do expect it to.

> If you want it above the staff, you can use c2^\f.

If you're going to use single-staff polyphony and put your
dynamics in an odd-numbered voice, I think the burden should
be on you to use \dynamicDown.  The way I see it, it's far
easier to ask a user in your situation to do this once...

\layout {
  \context {
    \Score
    \override DynamicText #'direction = #DOWN
    \override DynamicLineSpanner #'direction = #DOWN
  }
}

...than to make a user like me have to keep doing this
every time I have polyphonic dynamics:

<< { \dynamicUp c4\p\< c c c\f } \\ { a1\mf } >>


David Kastrup wrote:
>> So why doesn't it also imply \dynamicUp ?
> Because that will be startling for basically homophonic
> voicing with only short
> not-actually-a-voice-but-we-need-to-write-it-such
> passages.

Hmm.

> As I said: the right thing to me seems to put the dynamics
> in every voice (and let the performers work from that),
> and give the dynamics engraver options to funnel them off
> to a common place as long as they can be unified (like in
> the middle of a piano stuff).

I do agree with you on this point -- from a semantics view,
every voice intended to be associated with a dynamic should
be given one, and this musical information should be
independent of the "style" in which it is displayed (think
HTML and CSS).  And if "dynamic contamination" is to be
assumed, it should be formalized somewhere.  Also, be
careful with the word "performers"; I assume you mean
Dynamic_performer?

>> ...what legitimate code would possibly break by changing
>> this?
>
> \relative c'' { << { c2\f } \\ { a2 } >> }
>
> Namely code that makes use of the fact that a dynamic
> specification in a single voice contaminates all other
> voices (and the Midi) by default.
>
> If all other dynamic specifitions end up below the staff,
> you'll be surprised at this one.
>
> I consider it bad style to write like this, but there have
> not been convincing alternatives yet, have they?

Eloquently stated.

I'm starting to think that this is a bigger problem than I
initially thought.  You've said the LilyPond has "no clean
concept of dynamics related to voices rather than merely to
current time."  Is there a solution?

- Mark


      



reply via email to

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