Re: Reusability of lilypond code? (lyuser: message 4 of 20)
Hello Aaron, > Tags might be a reasonably simple option here. Yes, that really looks promising! I'll try that as soon as I can. Thank you! -- Markus Grunwald https://www.the-grue.de/~markus/markus_grunwald.gpg ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Reusability of lilypond code?
On 06/27, Ben wrote:
> Mason,
>
> Does that mean for every piece of yours you have separate dynamic contexts
> for every single instrument? I'd imagine that could possibly clutter up your
> score a bit, no?
>
> To have many dynamic context variables mapped to all their appropriate
> instruments, just curious how you manage it all? Do you only pick a few
> dynamic contexts for main instruments, or really all?
>
> Interested to hear more :)
I try to avoid clutter by breaking my project into many .ily files, each either
containing one kind of information or fulfilling one role in piecing together
the project. For example, each instrument has one file containing all of its
notes and one file containing all of its dynamics. These files are included in
another file defining that instrument's staff, which looks like this:
---
\new Staff { \include "../music/instrument-name/notes.ily" }
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} { \include "../music/instrument-name/dynamics.ily" }
---
This file is in turn included in another file that puts together that
instrument's part, like this:
---
\score {
<<
\include "../staves/instrument.ily"
>>
\layout {}
}
---
as well as the file that puts together the score, which contains something like
this:
---
\score {
<<
\include "../staves/instrument.ily"
\include "../staves/another-instrument.ily"
\include "../staves/a-third-instrument.ily"
\include "../staves/etc.ily"
>>
\layout {}
}
---
As an example of how I organize all this, here's the project setup for the
piece I'm about to start engraving:
https://notabug.org/chaosmonk/untouchable-space
This isn't the final setup. I'll make the score and part generation more
modular and give instruments edition-mods.ily files once all the notes are in
and I start tweaking and creating editions for different paper/tablet sizes.
I'd be interested to hear about other approaches. How do you normally manage
your projects with respect to dynamics and in general?
signature.asc
Description: PGP signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Reusability of lilypond code?
On 6/27/2018 1:20 PM, Mason Hock wrote:
On 06/27, lyuser.theg...@spamgourmet.com wrote:
But I have one issue with the reuse of my work. My last score e.g. has
four voices (T1, T2, B1, B2). I assign music and lyrics for each voice
to a variable and combine them info a choir staff. So for our
rehearsal, everybody can see all the voices.
There are other usecases, where I would like to have only one
voice per staff. I can do that with lilypond, of course, by reusing
the variables that I created before.
Now comes the problem:
For the "one voice per staff" solution (and for midi files, by the
way), the single voices have to be annotated with all "bells and
whistles", like dynamics, for example.
But for the "four voices per staff", all the annotations would pile
up (one 'p' above the other 'p' for the two tenor voices, for example)
and with all the duplicated dynamic, hairpins, markup, the score would
become unreadable.
I typically use a separate Dynamics staff, which can then be attached once to
any music staff as appropriate. This will also align dynamics vertically, which
is my preference. Notice that in the third example the p is not aligned with
the other dynamics.
-
\version "2.19.82"
notesA = \relative c' {
a'2. a4 | a
}
notesB = \relative c' {
d2. d4 | a
}
dynamics = {
s2\fp\< s4 s\f s\p
}
notesBdynamics = \relative c' {
d2.\fp\< d4\f a\p
}
\score {
<<
\new Staff \notesA
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
\new Staff \notesB
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
>>
\layout { }
}
\score {
<<
\new Staff \partcombine \notesA \notesB
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
>>
\layout { }
}
\score {
<<
\new Staff \notesBdynamics
>>
\layout { }
}
-
Mason,
Does that mean for every piece of yours you have separate dynamic
contexts for every single instrument? I'd imagine that could possibly
clutter up your score a bit, no?
To have many dynamic context variables mapped to all their appropriate
instruments, just curious how you manage it all? Do you only pick a few
dynamic contexts for main instruments, or really all?
Interested to hear more :)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Reusability of lilypond code?
On 06/27, lyuser.theg...@spamgourmet.com wrote:
> But I have one issue with the reuse of my work. My last score e.g. has
> four voices (T1, T2, B1, B2). I assign music and lyrics for each voice
> to a variable and combine them info a choir staff. So for our
> rehearsal, everybody can see all the voices.
>
> There are other usecases, where I would like to have only one
> voice per staff. I can do that with lilypond, of course, by reusing
> the variables that I created before.
>
> Now comes the problem:
>
> For the "one voice per staff" solution (and for midi files, by the
> way), the single voices have to be annotated with all "bells and
> whistles", like dynamics, for example.
>
> But for the "four voices per staff", all the annotations would pile
> up (one 'p' above the other 'p' for the two tenor voices, for example)
> and with all the duplicated dynamic, hairpins, markup, the score would
> become unreadable.
I typically use a separate Dynamics staff, which can then be attached once to
any music staff as appropriate. This will also align dynamics vertically, which
is my preference. Notice that in the third example the p is not aligned with
the other dynamics.
-
\version "2.19.82"
notesA = \relative c' {
a'2. a4 | a
}
notesB = \relative c' {
d2. d4 | a
}
dynamics = {
s2\fp\< s4 s\f s\p
}
notesBdynamics = \relative c' {
d2.\fp\< d4\f a\p
}
\score {
<<
\new Staff \notesA
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
\new Staff \notesB
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
>>
\layout { }
}
\score {
<<
\new Staff \partcombine \notesA \notesB
\new Dynamics \with {
\override VerticalAxisGroup.staff-affinity = #UP
} \dynamics
>>
\layout { }
}
\score {
<<
\new Staff \notesBdynamics
>>
\layout { }
}
-
signature.asc
Description: PGP signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Reusability of lilypond code?
Hi Markus,
\tags are, as Aaron said, the way to go.
I'd just like to mention the way I often handle this, perhaps this is on any
help:
Instead of tagging each and every single dynamic element, I often completely
\omit certain stencils of a voice, if applicable.
The following example, while not being quite correct (because each voice
should get its own dynamics if they differ in any way), the DynamicText (and
Hairpin) stencils of hornII will be omitted in the score, the dynamics of
hornI will be used for both in the score and placed below the stave.
The parts keep their individual dynamics.
%%
\version "2.19.81"
hornI = {
\tag score \dynamicDown
g'1\p\< ~ 1 ~ 1 ~ 1\f
}
hornII = {
\tag score { \omit Voice.DynamicText \omit Voice.Hairpin }
R1 c'\mp\< ~ 1 ~ 1\f
}
\score {
\new Staff \partcombine \hornI \hornII
}
\score {
\new Staff \removeWithTag score \hornI
}
\score {
\new Staff \removeWithTag score \hornII
}
%%
HTH,
Torsten
--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Reusability of lilypond code?
On 2018-06-27 04:08, lyuser.theg...@spamgourmet.com wrote: What I would like to have is a simple switch in lilypond that hides the duplicated markup, so that I can use the same variables for both use cases. You mentioned finding some proposed solutions already, so I hope I am not just reiterating something you already looked at. Tags might be a reasonably simple option here. You can tag any elements that you only want to show up when the part is used by itself. Then it is easy to reference the part and conditionally include or exclude the elements in question. See the following documentation on tags which includes examples: http://lilypond.org/doc/v2.19/Documentation/notation/different-editions-from-one-source#using-tags -- Aaron Hill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Reusability of lilypond code?
Hello, This time, I have a more general question: I've set some scores for my men's choir using lilypond - and I love it :) With the help of this list, these scores look just like I would like to have them and our singers like to read them. But I have one issue with the reuse of my work. My last score e.g. has four voices (T1, T2, B1, B2). I assign music and lyrics for each voice to a variable and combine them info a choir staff. So for our rehearsal, everybody can see all the voices. There are other usecases, where I would like to have only one voice per staff. I can do that with lilypond, of course, by reusing the variables that I created before. Now comes the problem: For the "one voice per staff" solution (and for midi files, by the way), the single voices have to be annotated with all "bells and whistles", like dynamics, for example. But for the "four voices per staff", all the annotations would pile up (one 'p' above the other 'p' for the two tenor voices, for example) and with all the duplicated dynamic, hairpins, markup, the score would become unreadable. What I would like to have is a simple switch in lilypond that hides the duplicated markup, so that I can use the same variables for both use cases. Frescobaldi provides some tools to remove the markup from a selection. That is not what I want, because it creates two versions of the music. Not good, they will diverge. I've searched this and other lists and there seem to be solutions, but they are too complicated for me: I don't understand them and they never worked for me Can you help me this this problem? cu-- Markus Grunwald https://www.the-grue.de/~markus/markus_grunwald.gpg signature.asc Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
