lilypond-user
[Top][All Lists]
Advanced

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

Re: relative music inside music functions explodes when used twice


From: David Kastrup
Subject: Re: relative music inside music functions explodes when used twice
Date: Sun, 12 Oct 2014 12:45:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

> Thanks David and Paul - that's helpful.  However, while the situation
> improved the output is still not what i want:
> \version "2.19.13"
>
> voiceDivisi =
> #(define-music-function (parser location m1 m2) (ly:music? ly:music?)
>    #{
>      \tag divI { $m1 }
>      \tag divII { $m2 }
>      \tag together << { \dynamicUp $m1 } \\ { \dynamicDown $m2 } >>
>    #})
>
> music = \relative c' {
>   \voiceDivisi {
>     c4 d e f
>   }{
>     a,1
>   }
> }
> musicII = \relative c' {
>   \voiceDivisi {
>     f4 e d c
>   } {
>     a1
>   }
> }
>
> \new Staff \with { instrumentName = "part I" }
> \removeWithTag divII.together { \music \musicII }
>
> \new Staff \with { instrumentName = "part II" }
> \removeWithTag divI.together { \music \musicII }
>
> \new Staff \with { instrumentName = "combined" }
> \removeWithTag divI.divII { \music \musicII }
>
> if i understand correctly, "relativization" happens too late, i.e. after
> the music is processed by the voiceDivisi function.

I'm not even sure I understand _how_ you want the relativization to
happen.  One after the other?  In that case, you can use

voiceDivisi =
#(define-music-function (parser location m1 m2) (ly:music? ly:music?)
  (make-relative (m1 m2) #{ #m1 #m2 #}
  #{
      \tag divI { $m1 }
      \tag divII { $m2 }
      \tag together << { \dynamicUp $m1 } \\ { \dynamicDown $m2 } >>
  #}))

> How should i work around this?  Maybe instead of using tags i should
> write a function with a switch statement inside?  I know that i can
> put \relative command inside \voiceDivisi, but i'd like to avoid this
> as it would add a lot of typing.

It seems like the ingenuity of my make-relative macro never really
caught on...

By the way: I'm not sure it will be transparent enough to have << \\ >>
be recognized at the proper point of time.  If not, you'll need to use
explicit voices instead.

-- 
David Kastrup



reply via email to

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