bug-lilypond
[Top][All Lists]
Advanced

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

Re: \partcombine bugs


From: Knut Petersen
Subject: Re: \partcombine bugs
Date: Thu, 22 Jun 2017 00:36:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

Am 21.06.2017 um 22:28 schrieb Pierre-Luc Gauthier:
For choral music it is an old convention to merge dynamics if time of start,
time of end, and target are all identical.
I see. But wouldn't it be preference (style) rather than a bug?

Hmm. I think that I do not know enough of other notation traditions to decide
if the current behavior should be called a bug or a feature request.

I suppose you want that to be the default to merge most(all?) dynamics?
[\p, \f,etc] at identical time: merge
\< ... \! and \> ... \! : if time of start and time of end are identical: merge
\< ...[\p,\f,etc ]: if time of start, time of end, and target dynamics are 
identical: merge


I used \partcombineChords in your example to solve the bug1.

There are multiple ways around both "bugs". I often write my music definitions 
to a
separate file and read that file several times. The following lines illustrate 
the idea:

myfile.ily : music = { a2\myp }

main.ly:    myp = { \p }
                  \include "myfile.ily"
                  [...]
                  myp = { }
                  \include "myfile.ily"

That way it's easy to mask some code (e.g. the unwanted dynamics) from some of 
the scores contained in the main input file.

Bug 2 can circumvented by e.g.:

four  = { a'4\p 4 4 4 2\<   2   4\mp 4 4 4 \repeat volta 2 { 4 4 4 4 } 1 4 4 4 
4 }
five  = { d'4\p 4 4 4 4\< 4 4 4 4\mp 4 4 4 \repeat volta 2 { 4 4 4 4 } 1 4 4 4 
4 }

ufour = { \unfoldRepeats \four \bar "|."  }
ufive = { \unfoldRepeats \five \bar "|." }

\markup { "\partcombing already unfolded music does work ..." }
\score {
    \new ChoirStaff <<
        \new Staff \ufour
        \new Staff \ufive
        \new Staff \partcombine \ufour \ufive
    >>
    \layout{ }
}

This seems to be an easy workaround, but for more complex scores you end up 
with a lot of
almost identical code that needs to be written and maintained - one version for 
the music
with expanded repeats , one version for the version with unexpanded repeats.
If you produce a score to be printed, you normally need the unexpanded music,
if you produce midi/videos you need the expanded form.

Knut



reply via email to

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