subject:"Re\: best practices"

Re: Best practices for Da Capo/Dal Segno/al Fine/etc.

2018-02-21 Thread Joel C. Salomon

On 2018-02-20 5:21 PM, I asked:
> … what is the current (2.19) best practice for typesetting the Da
> Capo/‌Dal Segno/‌al Fine/‌etc. repeat marks?

I’m having some trouble extracting a readable-but-useful minimal example
from my code, but this excerpt might help the next fellow:

\include "poly-mark-engraver.ly"% from

\tagGroup #'(midi-only score-only)

…
lowerVI = {
  \clef bass
  \globalVI

  % \repeat coda 2 {
  \lowerVIabac
  % }   % \repeat coda

  % \alternative {
  %   { % \repeat coda
  \lowerVId
  %   }
  %   {}  % }   % \repeat coda

  % Manual repeat unfold for MIDI
  \tag #'midi-only \lowerVIabac
}

dynamicsVI = {
  <>\p
  % \repeat coda 2 {
  #(skip-of-length upperVIabac)
  % }   % \repeat coda

  \polyMark #'DCFine \markup \italic "Fine"
  \polyMark #'Fermata \markup \fermata
  \bar "|."

  % \alternative {
  %   { % \repeat coda
  #(skip-of-length upperVId)
  %   }
  %   {}
  % }   % \repeat coda

  % Manual repeat unfold for MIDI
  \tag #'midi-only #(skip-of-length upperVIabac)

  % Manual mark for \repeat coda
  \polyMark #'DCFine \markup \italic "D.C. al Fine"
  \bar "||"
}

…

scoreVI = \score {
  \keepWithTag #'score-only
  <<
\new Staff = "upper" \upperVI
\new Dynamics = "dynamics" \dynamicsVI
\new Staff = "lower" \lowerVI
  >>
  \layout {
\context { \Score
  polyMarkOptions = #`((DCFine
 (direction. ,DOWN)
 (self-alignment-X . 1.0)
 (break-visibility . ,begin-of-line-invisible))
   (Fermata
 (direction. ,UP)
 (self-alignment-X . 0.0)
 (break-visibility . ,begin-of-line-invisible)))
}
  }
}

midiVI = \score {
  \new PianoStaff
  \keepWithTag #'midi-only
  <<
\new Staff = "upper" <<
  \unfoldRepeats \upperVI
  \dynamicsVI
>>
\new Staff = "lower" <<
  \unfoldRepeats \lowerVI
  \dynamicsVI
>>
  >>
  \midi {}
}


There’s nothing here that isn’t already in
, and a good deal is missing
here which that snippet includes, but I think it does illustrate this
particular usage without invoking the full power of \polyMark.

––Joel C. Salomon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: best practices with tempo markings

2016-11-14 Thread tisimst

Tobian

On Mon, Nov 14, 2016 at 3:50 PM, Tobin Chodos [via Lilypond] <
ml-node+s1069038n196622...@n5.nabble.com> wrote:

> This one really is basic, but: a \tempo command in a large score will
> automatically register on each part, right?  that is, if I insert the
> marking to change tempo in the flute part in bar 2, it will appear on every
> other part...so where is it advisable to put it?
>

It will and it won't. By default, it is collected by the Score context, so
it will only appear above the top-most Staff unless you give a particular
staff permission to print it as well via a \with { \consists
"Metronome_mark_engraver" }. If you put the \tempo command in-line with the
part's music and reuse the same variable in the full score and part score,
then it will show up in both.

However, I find it prudent to put any Score-level items that generally
don't change from part to part (e.g., \tempo, \time, \key, \bar, etc.) in a
global variable that basically defines the structure and where each of
those items appears. For example:

struct = {
  \tempo 4=120
  \time 3/4
  \key a \minor
  s2.*7
  \bar "||"
  \tempo 4=80
  \time 4/4
  s1*10
  \bar "|."
}

This I then place in a simultaneous construct with each part within the
\score blocks. Thus, I can manage the overall structure in ONE place, but
apply it everywhere, both the full-score and individual parts. For example:

% full score
\score {
  <<
\new Staff << \struct \violinNotes >>
\new Staff << \struct \violaNotes >>
\new Staff << \struct \celloNotes >>
\new Staff << \struct \bassNotes >>
  >>
}

% violin part
\score {
  \new Staff << \struct \violinNotes >>
}

% viola part
\score {
  \new Staff << \struct \violaNotes >>
}

% cello part
\score {
  \new Staff << \struct \celloNotes >>
}

% bass part
\score {
  \new Staff << \struct \bassNotes >>
}

There are a variety of ways to customize this to your tastes and uses, but
this has been very reliable for me.

Hope that helps,
Abraham

--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/best-practices-with-tempo-markings-tp196622p196625.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [Best Practices] splitting and combining choral parts

2015-11-25 Thread Kieren MacMillan

p.s. To see the power of the system I’m trying to develop, add a manual line 
break at m. 8 (e.g., change line 103 to s4*2 \break s4*2), and then observe how 
the third system reacts.

=)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [Best Practices] splitting and combining choral parts

2015-11-25 Thread Kieren MacMillan

Hi, 

> Can we focus on how to achieve automatic frenching based on divisi?

Thanks.  =)

> this seems like a lot of work.

Well, I’m know it won’t be trivial… But I was hoping we could come up with a 
"Goldilocks solution”: a rather elegant way of handling it, with a minimum of 
effort on the engraver’s (i.e., user’s) part.

> It sounds like we want Lily to look at the line she's working on
> and decide whether some of the staves can be
> combined based on the content they have.

Eventually, sure, that’s the ideal. But for now, I’d be happy with manually 
entering \letStaffVanish and \showStaff (i.e., force visibility) at the 
sections where it’s clear those are necessary.

> An ideal solution would have to allow the user to turn certain rules on or 
> off.
> This seems like complex programming to me.

I’m not sure that’s in my Five-Year Plan for this feature/framework.  ;)

> would a solution that requires user intervention be acceptable?

Without a doubt. I sort of assume(d) that Phase One would be completely 
user-driven, with Phase Two [and beyond] being incremental automation of the 
various mechanisms involved.

> For example, a switch like \separateStaves which would force
> staves to be separated from the beginning of the current line, and a
> corresponding \combineStaves which would tell Lily to begin combining at the
> next line break. You would also have to specify which staves to combine.
> This puts the burden of decision on the user, hopefully simplifying the
> programming. Then, Lily just has to create a new Staff, use \partcombine,
> and assign lyrics to the voice.

Yes! This is the kind of discussion I want to have.

For \separateStaves, one can already put \letStaffVanish (resp. 
\letLyricsVanish) in the contexts that are not absolutely required, and 
\showStaff in those parts that are. And we have \quoteDuring, \partCombine, 
etc. to reduce the redundant code entry. See attached modified example.

There’s a divisi framework in openlilylib (cf. 
),
 but I haven’t investigated how mature it is, or how suitable to helping me 
solve this problem.

So… Here are some questions right off the bat:

1. How can I \addQuote and \quoteDuring lyrics?

2. If I wanted to condense the S+A staves on system 3 into a single SA staff, 
what’s the best approach?

3. Would all of this [kind of thing] be best conceived/coded as “exploding 
music” (i.e., start with a unison context, and divisi outwards), or “imploding 
music” (i.e., start with maximum spread, and combine to condense), or a 
combination thereof?

4. Is it better to use the soprano line as the unison line [as I’ve done here], 
or have a whole separate unison variable quoted in all parts [including the 
soprano]? In any case, one would want to add [as I have not] clarifying markups 
at the beginnings of systems or voice entries, as appropriate/necessary.

5. What would be the best way to simultaneously switch contexts/staves on and 
off? How can this be done with a minimum mixture of content and presentation?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info



WithersCarol_example.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [Best Practices] splitting and combining choral parts

2015-11-25 Thread tyronicus

Kieren wrote
> I’ve posted this question several times before, but the discussion always
> got truncated or derailed… I’m hoping this time we can work this through
> to a solution.

Simon and Michael, you make interesting points; yet, as an observer, I
submit that the topic has been derailed again. Can we focus on how to
achieve automatic frenching based on divisi?

Kieren, this seems like a lot of work. It sounds like we want Lily to look
at the line she's working on and decide whether some of the staves can be
combined based on the content they have. There would be a bunch of rules to
follow (do you allow Lily to combine when pitches are different but rhythms
are the same? what about a short melisma in one voice but not in the other;
would you split a whole line over that? Do you allow the alto staff and
tenor staff to combine for S/AT/B?). An ideal solution would have to allow
the user to turn certain rules on or off. This seems like complex
programming to me.

My question is, would a solution that requires user intervention be
acceptable? For example, a switch like \separateStaves which would force
staves to be separated from the beginning of the current line, and a
corresponding \combineStaves which would tell Lily to begin combining at the
next line break. You would also have to specify which staves to combine.
This puts the burden of decision on the user, hopefully simplifying the
programming. Then, Lily just has to create a new Staff, use \partcombine,
and assign lyrics to the voice.

--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Best-Practices-splitting-and-combining-choral-parts-tp184051p184123.html
Sent from the User mailing list archive at Nabble.com.

86 matches

Mail list logo