Re: Dynamics collide with span bar

[Aaron Hill]

On 2024-03-22 5:30 pm, Michael Bret wrote:
Then, it should be added that transposing your first fix (namely, 
BarLine.bar-extent = #'(0 . 1) and transparent = ##t) DOES solve the 
issue WITH “Bar_engraver” consisted. How does that make sense? I 
probably don’t get what "Span_bar_stub_engraver getting tripped up by 
the Bar_engraver” entails. It might be useful to keep it in mind, in 
order to identify cases where the fix messes up something.



In reviewing the code for Span_bar_stub_engraver, it intentionally does 
not create stubs for contexts that have the Bar_engraver.  But the stubs 
are not specifically needed if you have an actual BarLine grob.  That is 
why my earlier workaround worked.


Neither Lyrics nor ChordNames consist the Bar_engraver, so they rely on 
Span_bar_stub_engraver.  And the issue for ChordNames was the lack of 
Pure_from_neighbor_engraver.


Dynamics is interesting because it does consist the Bar_engraver, so it 
needs to be handled a little differently.  Of course, there are some 
elements of Dynamics such as hairpins that normally are acceptable to 
span across measures.  So, we would need to be careful that any changes 
to Dynamics does not break how people expect it to work.



-- Aaron Hill

Re: Dynamics collide with span bar (was Re: Chord names collide with span bar)

[Michael Bret]

Many thanks, Aaron. So here is a cleaner MWE, with your fix:


\version "2.25.13"
#(ly:set-option 'debug-skylines #t)
\layout {
 \context { \Score
  \override NonMusicalPaperColumn.show-horizontal-skylines = ##t
 }
}

\layout {
 \context { \Dynamics
   \consists Pure_from_neighbor_engraver
   \remove Bar_engraver
 }
}

\score {
 \new GrandStaff <<
   \new Staff \relative { e''4 4 4 4 | 4 4 4 4 }
   \new Dynamics { s1 | s1 \ppp  }
   \new Staff \relative { d''4 4 4 4 | 4 4 4 4 }
 >>
}



Then, it should be added that transposing your first fix (namely, 
BarLine.bar-extent = #'(0 . 1) and transparent = ##t) DOES solve the issue WITH 
“Bar_engraver” consisted. How does that make sense? I probably don’t get what 
"Span_bar_stub_engraver getting tripped up by the Bar_engraver” entails. It 
might be useful to keep it in mind, in order to identify cases where the fix 
messes up something.
Same MWE as above, with this instead:

\layout {
 \context { \Dynamics
   \consists "Bar_engraver"
   \override BarLine.bar-extent = #'(0 . 1)
   \override BarLine.transparent = ##t
 }
}

Re: Dynamics collide with span bar (was Re: Chord names collide with span bar)

[Aaron Hill]

On 2024-03-22 4:08 pm, Michael Bret wrote:

Dear Werner, Aaron and Knute,
(it is y first time attempting to contribute to such lilypond 
discussion so I don’t dare cc-ing the whole mailing list)



(Adding the mailing list for visibility...)

Regardless of your experience or comfort level, it is always recommended 
to include the mailing list in all discussions unless something must be 
privately communicated.  The reason is simple: All of us are volunteers, 
in one form or another.  Our time and availability are subject to change 
on a whim.  Directly emailing individuals greatly limits your chances of 
getting a prompt response (or any response at all), whereas writing to 
the broader audience increases the likelihood of a reply from someone 
who has the time to get back to sooner.  It is also very helpful to have 
email archives that are complete.  Off-list messages can disrupt proper 
threading of emails.



Is this issue related to this one (collision between dynamic text and 
span bar)?

https://music.stackexchange.com/questions/116312/lilypond-auto-horizontal-space-for-dynamic-text

Root cause seems similar since it is about the skyline of span-bar not 
being extended.


However, the solution provided by Werner doesn’t seem to transpose 
effectively. I tried this to no avail:



This would appear to be related, although a new wrinkle has appeared.

Something to note is that the Dynamics context already consists the 
Bar_engraver in order to make use of the to-barline property.  In my 
testing, I found that having the Bar_engraver consisted is getting in 
the way.  If you remove Bar_engraver and consist 
Pure_from_neighbor_engraver within Dynamics, it behaves similar to the 
ChordNames fix.  So, it would seem the Span_bar_stub_engraver is perhaps 
getting tripped up by the Bar_engraver.



\version "2.25.13"
\language "italiano"

common = {
  \key sol \minor
  \time 4/4
  \tempo "Largo [Широко]"
}

right = \relative do'' {
  \key sol \major
  sol8 (fad re mi sol fad re4) |
  sol8 (fad re mib sol fad re4)
}

left = \relative do' {
  \key sol \major
  sol,8 (re' si' re,) sol, (re' do' re,) |
  sol, (re' sib' re,) sol, (re' do' re,) |
}

dynamics = {
  s1 |
  \override DynamicText.extra-spacing-width = #'(-1 . 1)
  s8 \ppp s8 s8 s8 s8 s8 s4
}

%% #(ly:set-option 'debug-skylines #t)
\layout {
  \context { \Dynamics
\consists Pure_from_neighbor_engraver
\remove Bar_engraver
  }
}

\score {
  \new PianoStaff <<
\new Staff = "right" \right
\new Dynamics \dynamics
\new Staff = "left" { \clef bass \left }
  >>
}



-- Aaron Hill

Re: dynamics in coulour

[Michael Werner]

Hi Stefan,

On Tue, Feb 20, 2024 at 9:49 AM Stefan Thomas 
wrote:

> Dear community,
> is it possible to display the dynamics, also haipins and other things like
> crescendo etc., in coulour?
> Could someone could give me a hint?
>

Sure can. Most (if not all) grobs have a color property that can be
overridden. If you want to change all grobs of that type in a score to a
certain color, you can put the override into the layout block. Or, if you
want to change just one instance, you can put the override into the music
expression. Here's some sample code showing both:

\version "2.24.3"

mus = \relative c' {
  f4\p a4\< c8 d b4\f |
  \once \override DynamicText.color = #yellow f4\p a4\< c8 d b4\f
}

\score {
  \new Staff {
\new Voice {
  \mus
}
  }
}

\layout {
  \context {
\Voice
\override Hairpin.color = #red
\override DynamicText.color = #blue
  }
}

producing:

[image: image.png]

The overrides in the layout block have gone into the Voice context, as
that's where they live by default. If, however, you put your dynamics into
a Dynamics context of their own you would need to modify the layout block
accordingly.

The override in the music expression is using the \once command, so that
only the next instance of that grob is affected. If you want to change
*all* the grobs of that type from that point onward, just omit the \once

Also, one of the (sometimes) tricky parts can be finding the right name for
the grob. The best resource I've found for that is:
https://lilypond.org/doc/v2.25/Documentation/ly-examples/visualindex.pdf
It's a 2 page PDF with an amazing amount of information. It's listed as
being in the 2.25 docs, but if you're using the 2.24 series it should still
be useful, as I'm pretty sure all the grob names, contexts, end engravers
are pretty much the same names.
-- 
Michael

Re: dynamics in coulour

[Stefan Thomas]

Thanks, I'll check it out!
Best,
Stefan

Am Di., 20. Feb. 2024 um 16:33 Uhr schrieb Ritchie Fraser <
euphoge...@gmail.com>:

> Hi Stefan,
>
> I did just that last week I need to do the same thing for a cue part. This
> is how I achieved it.
>
>
> \new CueVoice {
>\override Staff.StaffSymbol.color = #magenta
>\override Accidental.color = #magenta
>\override Beam.color = #magenta
>\override NoteHead.color = #magenta
>\override Stem.color = #magenta
>\override Rest.color = #magenta
>\override TextScript.color = #magenta
>\override DynamicText.color = #magenta
>\override DynamicTextSpanner.color = #magenta
> f,4\f^"Bb Bass" r4 r4 |
> c4 r4 r4 |
> g'4 r4 r4 |
> c,2. |
> f4\f r4 r4 |
> d4 r4 r4 |
> g4 r4 r4 |
> c,2. |
> fis2.\pp\( |
> g4\) r4 r4 |
> e2.\( |
> f4\) r4 r4 |
> }
>
> Regards
>
> Ritchie
>
> On Tue, 20 Feb 2024 at 14:49, Stefan Thomas 
> wrote:
>
>> Dear community,
>> is it possible to display the dynamics, also haipins and other things
>> like crescendo etc., in coulour?
>> Could someone could give me a hint?
>> Thanks,
>> Stefan
>>
>
>
> --
> Kind Regards
>
> Ritchie
> -
> Ritchie Fraser
>
>

Re: Dynamics [pl|sp]acing weirdness

[Kieren MacMillan]

Hi MIchael,

> While that works, wrapping that combo isn't required all the time. E.g. when 
> you have
> dynamicsA = {
>   s2. s4\mf\< | s2 s2\f |
> }

That’s because this version does not use \after, which is a music function that 
expects a single musical expression as its first parameter.

> there still is the bar check warning, implying that the combo \mf\f does use 
> musical time.
> That's something I don't understand. Especially since it doesn't seem to when 
> wrapped in {}.

\mf\< is two musical expressions; { \mf\< } is one musical expression.
"Use musical time” isn’t exactly how I would frame the behaviour.

> If that's intended (and I'm not saying it isn't or can't be) I'd like to 
> understand the reason for this (to me) inconsistency.

It is intended, as far as I know.

Hope that helps!
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: Dynamics [pl|sp]acing weirdness

[Michael Gerdau]

Hi Kieren,

thanks for answering :)


I've come across some placing or spacing weirdness with dynamics.
In the attached example \dynamicsA is what I tried to code, aka the \< starts 
directly after the \mf. What I expected is what you see in \dynamicsB. However it 
seems as if the combo \mf\< does use some musical time which makes the \f appear 1 
quaver later than I had expected.
Is this behaviour expected or a bug?


Did you notice the error(s) when you tried to compile?  ;)


You mean the failed bar check? That's basically my complaint. I don't 
understand why the bar check fails.



Try this instead:

dynamicsA = {
   s2. \after 8... { <>\mf\< } s4 | s2 s2\f |
}

Note that the combo you’re trying to insert needs to be wrapped in braces so 
that it’s a single musical expression.


While that works, wrapping that combo isn't required all the time. E.g. 
when you have


dynamicsA = {
   s2. s4\mf\< | s2 s2\f |
}

everything compiles w/o a complaint. Of course the placement of the \mf 
is different.


However when you try something like

dynamicsA = {
   s2. \after 64 \mf\< s4 | s2 s2\f |
}

there still is the bar check warning, implying that the combo \mf\f does 
use musical time.


That's something I don't understand. Especially since it doesn't seem to 
when wrapped in {}.


If that's intended (and I'm not saying it isn't or can't be) I'd like to 
understand the reason for this (to me) inconsistency.


Kind regards,
Michael
--
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

Re: Dynamics [pl|sp]acing weirdness

[Kieren MacMillan]

Hi Michael,

> I've come across some placing or spacing weirdness with dynamics.
> In the attached example \dynamicsA is what I tried to code, aka the \< starts 
> directly after the \mf. What I expected is what you see in \dynamicsB. 
> However it seems as if the combo \mf\< does use some musical time which makes 
> the \f appear 1 quaver later than I had expected.
> Is this behaviour expected or a bug?

Did you notice the error(s) when you tried to compile?  ;)

Try this instead:

dynamicsA = {
  s2. \after 8... { <>\mf\< } s4 | s2 s2\f |
}

Note that the combo you’re trying to insert needs to be wrapped in braces so 
that it’s a single musical expression.

Hope that helps!
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: Dynamics placement in partCombine

[Michael Gerdau]

Quick answer, and I’m not sure it will help much:

\dynamicUp affects the context (Voice) in which it’s placed. 
\partCombine combines its arguments into new Voices and \dynamicUp 
ended up in a different voice than the p


Thank you for your answer.

When you remove \dynamicUp ALL dynamics appear below. What irritates me 
is that when you have identical dynamic markings in both voices 
\dynamicUp and things like \override DynamicTextSpanner.style = #'none 
work normally. However when voices have differing dynamics it stops to 
work at some point.


Might be due to the temporary contexts created by \partCombine 
internally. The current behaviour is very unexpected to me though.


The following seems to work:
- snip - snip - snip - snip - snip - snip -
\version "2.25.9"

musa = { \dynamicUp c'4\p \repeat unfold 3 { c' }
  \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }
musb = { \dynamicUp s1
  \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }

\score {
  \partCombine \musa \musb
}

\score {
  \partCombine \musb \musa
}

\score {
  \partCombine \musa \musa
}

\score {
  \partCombine \musb \musb
}
- snip - snip - snip - snip - snip - snip -

Kind regards,
Michael--
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver\version "2.25.9"

musa = { \dynamicUp c'4\p \repeat unfold 3 { c' }
  \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }
musb = { \dynamicUp s1
  \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }

\score {
  \partCombine \musa \musb
}

\score {
  \partCombine \musb \musa
}

\score {
  \partCombine \musa \musa
}

\score {
  \partCombine \musb \musb
}


partCombine-Test.pdf
Description: Adobe PDF document

Re: Dynamics placement in partCombine

[Michael Gerdau]

Quick answer, and I’m not sure it will help much:

\dynamicUp affects the context (Voice) in which it’s placed. \partCombine 
combines its arguments into new Voices and \dynamicUp ended up in a different 
voice than the p


Thank you for your answer.

When you remove \dynamicUp ALL dynamics appear below. What irritates me 
is that when you have identical dynamic markings in both voices 
\dynamicUp and things like \override DynamicTextSpanner.style = #'none 
work normally. However when voices have differing dynamics it stops to 
work at some point.


Might be due to the temporary contexts created by \partCombine 
internally. The current behaviour is very unexpected to me though.


Kind regards,
Michael--
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

Re: Dynamics placement in partCombine

[Michael Gerdau]

Quick answer, and I’m not sure it will help much:

\dynamicUp affects the context (Voice) in which it’s placed. \partCombine 
combines its arguments into new Voices and \dynamicUp ended up in a different 
voice than the p


Thank you for your answer.

When you remove \dynamicUp ALL dynamics appear below. What irritates me 
is that when you have identical dynamic markings in both voices 
\dynamicUp and things like \override DynamicTextSpanner.style = #'none 
work normally. However when voices have differing dynamics it stops to 
work at some point.


Might be due to the temporary contexts created by \partCombine 
internally. The current behaviour is very unexpected to me though.


Kind regards,
Michael
--
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

Re: Dynamics placement in partCombine

[Michael Gerdau]

I presume that partCombine overrides the dynamic placement so that 
dynamics for the two parts are placed above and below, which seems a 
reasonable approach when the parts are more distinct than in the given 
example.  Using ^ to override it in this case seems a tolerable alternative.


Thank you for your answer.

I'm not sure that's the correct explanation though.
See this:
- snip - snip - snip - snip - snip - snip - snip -
\version "2.25.9"

musa = { \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }
musb = { \dynamicUp s1
  c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }

\score {
  \partCombine \musa \musb
}

\score {
  \partCombine \musb \musa
}

\score {
  \partCombine \musa \musa
}

\score {
  \partCombine \musb \musb
}
- snip - snip - snip - snip - snip - snip - snip -

When you repeat the last bar identically in both \musa and \musb the 
dynamics stay below in the first two scores and stay above in the second 
two scores.


To me this looks like a bug.

Kind regards,
Michael
--
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver\version "2.25.9"

musa = { \dynamicUp c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }
musb = { \dynamicUp s1
  c'4\p \repeat unfold 3 { c' }
  c'4\p \repeat unfold 3 { c' } }

\score {
  \partCombine \musa \musb
}

\score {
  \partCombine \musb \musa
}

\score {
  \partCombine \musa \musa
}

\score {
  \partCombine \musb \musb
}


partCombine-Test.pdf
Description: Adobe PDF document

Re: Dynamics placement in partCombine

[Paul Hodges]

I presume that partCombine overrides the dynamic placement so that dynamics for 
the two parts are placed above and below, which seems a reasonable approach 
when the parts are more distinct than in the given example.  Using ^ to 
override it in this case seems a tolerable alternative.


Paul



 From:   Michael Gerdau  
 To:   lilypond-user  
 Sent:   13/10/2023 11:30 
 Subject:   Dynamics placement in partCombine 

Hi list, 
 
the following code places the 2nd \p under the music but I'd like it  
above. I know I could explicitly add a placement (like ^\p) but wonder  
why \dynamicUp doesn't do its job. 
 
- snip - snip - snip - snip - snip - snip - snip - 
\version "2.25.9" 
 
musa = { \dynamicUp c'4\p \repeat unfold 3 { c' } c'4\p \repeat unfold 3  
{ c' } } 
musb = { \dynamicUp s1 c'4\p \repeat unfold 3 { c' } } 
\score { 
   \partCombine \musa \musb 
} 
- snip - snip - snip - snip - snip - snip - snip - 
 
Kind regards, 
Michael 
--  
  Michael Gerdau       email: m...@qata.de 
  GPG-keys available on request or at public keyserver

Re: Dynamics placement in partCombine

[Leo Correia de Verdier]

Quick answer, and I’m not sure it will help much: 

\dynamicUp affects the context (Voice) in which it’s placed. \partCombine 
combines its arguments into new Voices and \dynamicUp ended up in a different 
voice than the p

> 13 okt. 2023 kl. 12:32 skrev Michael Gerdau :
> 
> Hi list,
> 
> the following code places the 2nd \p under the music but I'd like it above. I 
> know I could explicitly add a placement (like ^\p) but wonder why \dynamicUp 
> doesn't do its job.
> 
> - snip - snip - snip - snip - snip - snip - snip -
> \version "2.25.9"
> 
> musa = { \dynamicUp c'4\p \repeat unfold 3 { c' } c'4\p \repeat unfold 3 { c' 
> } }
> musb = { \dynamicUp s1 c'4\p \repeat unfold 3 { c' } }
> \score {
> \partCombine \musa \musb
> }
> - snip - snip - snip - snip - snip - snip - snip -
> 
> Kind regards,
> Michael
> -- 
> Michael Gerdau   email: m...@qata.de
> GPG-keys available on request or at public keyserver
> 
> 

Re: Dynamics for both staves

[p]

On 2023-02-07 12:47, Jean Abou Samra wrote:

On 07/02/2023 12:44, p...@ocmatos.com wrote:

On 2023-02-03 17:41, Knute Snortum wrote:


What I do is have a separate dynamics variable, then include that
variable in both staves of the piano staff in the midi block.  Then I
switch the dynamic performer to the staff level.  It looks like this
(for only one staff):



Thanks. What is the meaning of two scores though? I thought scores 
were something that were going to be rendered. Yet you have two scores 
but only one rendered. How does lilypond decide what to render and 
what to not render?



\score has no \midi or \layout blocks ⇒ PDF
\score has a \midi block but no \layout block ⇒ only MIDI
\score has a \layout block but no \midi block ⇒ PDF
\score has both a \layout block and a \midi block ⇒ MIDI and PDF

See 
https://lilypond.org/doc/v2.24/Documentation/notation/the-midi-block


Awesome - thanks.

Re: Dynamics for both staves

[Jean Abou Samra]

On 07/02/2023 12:44, p...@ocmatos.com wrote:
> On 2023-02-03 17:41, Knute Snortum wrote:
>>
>> What I do is have a separate dynamics variable, then include that
>> variable in both staves of the piano staff in the midi block.  Then I
>> switch the dynamic performer to the staff level.  It looks like this
>> (for only one staff):
>>
> 
> Thanks. What is the meaning of two scores though? I thought scores were 
> something that were going to be rendered. Yet you have two scores but only 
> one rendered. How does lilypond decide what to render and what to not render?


\score has no \midi or \layout blocks ⇒ PDF
\score has a \midi block but no \layout block ⇒ only MIDI
\score has a \layout block but no \midi block ⇒ PDF
\score has both a \layout block and a \midi block ⇒ MIDI and PDF

See https://lilypond.org/doc/v2.24/Documentation/notation/the-midi-block



OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics for both staves

[p]

On 2023-02-03 17:41, Knute Snortum wrote:


What I do is have a separate dynamics variable, then include that
variable in both staves of the piano staff in the midi block.  Then I
switch the dynamic performer to the staff level.  It looks like this
(for only one staff):



Thanks. What is the meaning of two scores though? I thought scores were 
something that were going to be rendered. Yet you have two scores but 
only one rendered. How does lilypond decide what to render and what to 
not render?

--
Paulo

Re: Dynamics for both staves

[Knute Snortum]

On Fri, Feb 3, 2023 at 8:41 AM Knute Snortum  wrote:
>
> On Fri, Feb 3, 2023 at 12:21 AM Paulo Matos  wrote:
> >
> > Hi,
> >
> > I am trying to apply dynamic marking like piano and so forth to both
> > staves.
> [...]
> > i.e. start a new group called Dynamics and add the dynamics there but
> > this seems suboptimal as it makes the typesetting separate from the
> > notes _and_ as far as I understand it, doesn't affect MIDI - and the
> > first solution does.
> > Is there a better solution to this?
>
> What I do is have a separate dynamics variable, then include that
> variable in both staves of the piano staff in the midi block.  Then I
> switch the dynamic performer to the staff level.  It looks like this
> (for only one staff):
[...]

And here's a more complete example that also shows how you can have
dynamics in the staff as well as the dynamics "staff":

\version "2.25.1"

upper = { c''4 4 4 4 }
lower = { \clef bass c4 4 4\mp 4 }

dyn = { s4\f s\mf s s\p }

\score {
  \new PianoStaff <<
\new Staff \upper
\new Dynamics \dyn
\new Staff \lower
  >>
  \layout {}
}

\score {
  <<
\new Staff << \upper \dyn >>
\new Staff << \lower \dyn >>
  >>
  \midi {
  \context {
  \Staff
  \consists "Dynamic_performer"
}
\context {
  \Voice
  \remove "Dynamic_performer"
}
  }
}


--
Knute Snortum

Re: Dynamics for both staves

[Knute Snortum]

On Fri, Feb 3, 2023 at 12:21 AM Paulo Matos  wrote:
>
> Hi,
>
> I am trying to apply dynamic marking like piano and so forth to both
> staves.
[...]
> i.e. start a new group called Dynamics and add the dynamics there but
> this seems suboptimal as it makes the typesetting separate from the
> notes _and_ as far as I understand it, doesn't affect MIDI - and the
> first solution does.
> Is there a better solution to this?

What I do is have a separate dynamics variable, then include that
variable in both staves of the piano staff in the midi block.  Then I
switch the dynamic performer to the staff level.  It looks like this
(for only one staff):

\version "2.25.2"

music = { c''4 4 4 4 }

dyn = { s4\f s\mf s\mp s\p }

\score {
  <<
\new Staff \music
\new Dynamics \dyn
  >>
  \layout {}
}

\score {
  \new Staff << \music \dyn >>
  \midi {
  \context {
  \Staff
  \consists "Dynamic_performer"
}
\context {
  \Voice
  \remove "Dynamic_performer"
}
  }
}

-- 
Knute Snortum

Re: dynamics: sf vs sfz

[Michael Käppler]

Am 06.01.2022 um 18:09 schrieb Kenneth Wolcott:

Thank you for your elaboration on the dynamics; much appreciated.

On Thu, Jan 6, 2022 at 6:11 AM Kieren MacMillan
 wrote:

Hi all,

As composer, pianist, and conductor, I can offer that the consensus among most of the 
musicians I know is that sfz is [in modern practice] considered different from sf, 
especially with respect to the envelope of the note: in "equation" terms, one 
might write sfz = sf + >. An analogous difference distinguishes fz as different from both 
sf and sfz.

In performance of more "historical" music (say, Beethoven and before), these 
distinctions are not as widely or faithfully observed.

For an excellent overview regarding dynamic specifications (and many
other topics that are connected to performance indications) in the 19th
century, see
Clive Brown: Classical and Romantic Performing Practice 1750-1900 .
This book is marvellous!


Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: dynamics: sf vs sfz

[Kenneth Wolcott]

Thank you for your elaboration on the dynamics; much appreciated.

On Thu, Jan 6, 2022 at 6:11 AM Kieren MacMillan
 wrote:
>
> Hi all,
>
> As composer, pianist, and conductor, I can offer that the consensus among 
> most of the musicians I know is that sfz is [in modern practice] considered 
> different from sf, especially with respect to the envelope of the note: in 
> "equation" terms, one might write sfz = sf + >. An analogous difference 
> distinguishes fz as different from both sf and sfz.
>
> In performance of more "historical" music (say, Beethoven and before), these 
> distinctions are not as widely or faithfully observed.
>
> Cheers,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info
>

Re: dynamics: sf vs sfz

[Kieren MacMillan]

Hi all,

As composer, pianist, and conductor, I can offer that the consensus among most 
of the musicians I know is that sfz is [in modern practice] considered 
different from sf, especially with respect to the envelope of the note: in 
"equation" terms, one might write sfz = sf + >. An analogous difference 
distinguishes fz as different from both sf and sfz.

In performance of more "historical" music (say, Beethoven and before), these 
distinctions are not as widely or faithfully observed.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: dynamics: sf vs sfz

[Valentin Petzel]

Hi Ken,

sfz is sforzando, sometimes also fz (forzando) or sforzato or forzato or 
whatever.

sf can be used as sforzando, but sometimes you find sf and sp also for subito 
forte and subito piano.

Cheers,
Valentin

Am Donnerstag, 6. Jänner 2022, 04:19:58 CET schrieb Kenneth Wolcott:
> Hi;
> 
>   Musical question here, not specific to Lilypond.
> 
>   I have an excerpt that I am engraving as a sample which uses the dynamic
> "sf".
> 
>   In the Wikipedia article
> 
> https://en.wikipedia.org/wiki/List_of_musical_symbols
> 
> "sfz" is mentioned but not "sf".
> 
>   Ah, I see in my printed Norton/Grove Concise Encyclopedia of Music
> that "sf" and "sfz" are both the abbreviations of sforzando and/or
> sforzato.
> 
>   Answered my own question :-(
> 
> Thanks,
> Ken Wolcott

signature.asc
Description: This is a digitally signed message part.

Re: Dynamics and tempo alignment?

[Kevin Cole]

On Thu, Nov 4, 2021 at 2:31 PM Mark Knoop  wrote:

> \tempo is not a postfix command like dynamics and markups. Just put it before 
> the g2.

I do so love the simple fixes. Thanks!

Re: Dynamics and tempo alignment?

[Mark Knoop]

At 14:16 on 04 Nov 2021, Kevin Cole wrote:

Hi,

I think I'm making great strides with my wee little transcriptions,
but here's my latest puzzle:

I have the following measure:

  g2^\>\tempo \markup { \italic "Slower." } 4 = 65
  <<
{ \voiceOne fs8\!\p([ g8]) }
\new Voice
{ \voiceTwo fs8 g8 }
  >>
  \oneVoice  | %  20

I want the "Slower (♩= 65)" to appear above and at the start of the
decrescendo. But instead it appears to the right of it. (See attached
PNG.)  There seem to be a lot of different -- and to me -- overly
complicated -- ways of doing this. Is there a "recommended" way
without trying to give relative coordinates to move to?


\tempo is not a postfix command like dynamics and markups. Just put it before 
the g2.

--
Mark Knoop

Re: Dynamics line above staff

[Bernhard Kleine]

Am 21.05.2021 um 21:37 schrieb Jean Abou Samra:
>
>
> Le 21/05/2021 à 21:15, Bernhard Kleine a écrit :
>> The dynamic line ist above the text (snippet) for the soprano. I would
>> like to see it below the text, but on top of the staff that the "Mädel
>> gib acht" is on top. I hope this is better phrased.
>>
>> KR Bernhard
>
> I see. How about this?
>
> ...
> Best,
> Jean

For the records: the solution Jean offered work for a single stanza. For
multiple stanze I had to place the stanze on top of the dynamics, i.e.
the other way wound. The original error "with" instead of "\with" will
be chiselled in my brain.

Thanks for all contributions

Bernhard

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics line above staff

[Jean Abou Samra]

Le 21/05/2021 à 21:15, Bernhard Kleine a écrit :

The dynamic line ist above the text (snippet) for the soprano. I would
like to see it below the text, but on top of the staff that the "Mädel
gib acht" is on top. I hope this is better phrased.

KR Bernhard


I see. How about this?

\version "2.23.3"

\version "2.20.0"
\language "deutsch"
\header {
  title = "Ländler"
  tagline = "Bernhard Kleine 2021"
}
\paper {
  #(set-paper-size "a4")
}
global = {
  \key d \major
  \numericTimeSignature
  \time 3/4
}
soprano = \relative c'' {
  \global
  % Die Noten folgen hier.
  d4^\rfz^- fis,8 ([g]) fis ([g])| h4^^ a^. a^. | d^. d,8 ([e]) d ([e])
| g4^^ fis^. fis^.
}
dynamicI = {
%1
s8\mf s8\< s4. s8\! | s4 s4\> s8 s \! | s4\f  s4\< s8 s\! | s4 s4\> s8
s\! | s8^"cresc. poco a poco"\< s s4
  s8. s16\! s2.
}
sopranoVoice = \relative c' {
  \global
  \dynamicUp
  % Die Noten folgen hier.
  s2. s2. s2. s2. h4^.^^ d^. e^. | fis2^- r4 |
}
alto = \relative c' {
  \global
  % Die Noten folgen hier.
  fis4 d8 ([e]) d ([e]) | g4 fis fis | 4 h h|  e d d | h r r
    ais_._^ h_.\< cis_.\!
}
tenor = \relative c' {
  \global
  % Die Noten folgen hier.
  a4 a a | d d d  |fis, fis8 ([g]) fis ([g]) | h4 h h8 ([a])| g4 r r|
    cis,4. fis8 fis4 |
}
bass = \relative c {
  \global
  % Die Noten folgen hier.
  d4 d d | d d d8 ([cis]) | h4 h h | h h' h| R2. |
    fis,4 gis ais |
}
altoVerseOne = \lyricmode {
  \set stanza = "1."
  % Liedtext folgt hier.
  Mä -- del, der Lenz ist da, Mä -- del der Lenz ist da, la
  Mä -- del, gib acht!
}
verseSopranoVoiceOne = \lyricmode {
  % Liedtext folgt hier.
  Mä -- del gib acht!
}
choirPartI = \new ChoirStaff <<
  \new Dynamics = "page1" \with {
    alignAboveContext = "sopranolyrics"
  }
  \new Staff = "sa" \with {
    instrumentName = \markup \center-column { "Sopran" "Alt" }
  } <<
    \dynamicI
    \new Voice = "soprano" { \voiceOne \soprano }
    \new Voice = "ssoprano" { \voiceOne \sopranoVoice }
    \new Voice = "alto" { \voiceTwo \alto }
  >>
  \new Lyrics \lyricsto "alto" \altoVerseOne
  \new Lyrics = "sopranolyrics" \with {
    alignAboveContext = "sa"
  } \lyricsto "ssoprano" \verseSopranoVoiceOne

  \new Staff = "tb" \with {
    instrumentName = \markup \center-column { "Tenor" "Bass" }
  } <<
    \clef bass
    \new Voice = "tenor" { \voiceOne \tenor }
    \new Voice = "bass" { \voiceTwo \bass }
  >>
>>

\score {
  \choirPartI
  \layout { }
}

Best,
Jean

Re: Dynamics line above staff

[Bernhard Kleine]

The dynamic line ist above the text (snippet) for the soprano. I would
like to see it below the text, but on top of the staff that the "Mädel
gib acht" is on top. I hope this is better phrased.

KR Bernhard

Am 21.05.2021 um 17:47 schrieb Jean Abou Samra:
>
>
> Le 21/05/2021 à 16:19, Bernhard Kleine a écrit :
>> By the way, would it be possible to have the
>> dynamics the single soprano text .
>
> Sorry, I don't understand the question. Could you rephrase it, please?
>
> Best,
> Jean

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics line above staff

[Jean Abou Samra]

Le 21/05/2021 à 16:19, Bernhard Kleine a écrit :

By the way, would it be possible to have the
dynamics the single soprano text .


Sorry, I don't understand the question. Could you rephrase it, please?

Best,
Jean

Re: Dynamics line above staff

[Bernhard Kleine]

Am 21.05.2021 um 16:19 schrieb Bernhard Kleine:
> Am 21.05.2021 um 14:40 schrieb Jean Abou Samra:
>> \new Dynamics = "page1" \with {
>>   alignAboveContext = "sa"
>>     }
> The error was the "with" instead of "\with.
>
> Thank you for analysing. By the way, would it be possible to have the
> dynamics the single soprano text . That would be very much appreciated.
below the soprano line
> Kind regards Bernhard
>
-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics line above staff

[Bernhard Kleine]

Am 21.05.2021 um 14:40 schrieb Jean Abou Samra:
> \new Dynamics = "page1" \with {
>   alignAboveContext = "sa"
>     }

The error was the "with" instead of "\with.

Thank you for analysing. By the way, would it be possible to have the
dynamics the single soprano text . That would be very much appreciated.

Kind regards Bernhard

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics line above staff

[Jean Abou Samra]

Le 21/05/2021 à 14:23, Bernhard Kleine a écrit :

here is the MWE:

\version "2.21.1"
\language "deutsch"
\header {
   title = "Ländler"
   tagline = "Bernhard Kleine 2021"
}
\paper {
   #(set-paper-size "a4")
}
global = {
   \key d \major
   \numericTimeSignature
   \time 3/4
}
soprano = \relative c'' {
   \global
   % Die Noten folgen hier.
   d4^\rfz^- fis,8 ([g]) fis ([g])| h4^^ a^. a^. | d^. d,8 ([e]) d ([e])
| g4^^ fis^. fis^.
}
dynamicI = {
%1
s8\mf s8\< s4. s8\! | s4 s4\> s8 s \! | s4\f  s4\< s8 s\! | s4 s4\> s8
s\! | s8^"cresc. poco a poco"\< s s4
   s8. s16\! s2.
}
sopranoVoice = \relative c' {
   \global
   \dynamicUp
   % Die Noten folgen hier.
   s2. s2. s2. s2. h4^.^^ d^. e^. | fis2^- r4 |
}
alto = \relative c' {
   \global
   % Die Noten folgen hier.
   fis4 d8 ([e]) d ([e]) | g4 fis fis | 4 h h|  e d d | h r r
     ais_._^ h_.\< cis_.\!
}
tenor = \relative c' {
   \global
   % Die Noten folgen hier.
   a4 a a | d d d  |fis, fis8 ([g]) fis ([g]) | h4 h h8 ([a])| g4 r r|
     cis,4. fis8 fis4 |
}
bass = \relative c {
   \global
   % Die Noten folgen hier.
   d4 d d | d d d8 ([cis]) | h4 h h | h h' h| R2. |
     fis,4 gis ais |
}
altoVerseOne = \lyricmode {
   \set stanza = "1."
   % Liedtext folgt hier.
   Mä -- del, der Lenz ist da, Mä -- del der Lenz ist da, la
   Mä -- del, gib acht!
}
verseSopranoVoiceOne = \lyricmode {
   % Liedtext folgt hier.
   Mä -- del gib acht!
}
choirPartI = \new ChoirStaff <<
   \new Staff = "sa" \with {
     instrumentName = \markup \center-column { "Sopran" "Alt" }
   } <<
     \new Dynamics = "page1"  \dynamicI
     \new Voice = "soprano" { \voiceOne \soprano }
     \new Voice = "ssoprano" { \voiceOne \sopranoVoice }
     \new Voice = "alto" { \voiceTwo \alto }
   >>
   \new Lyrics \lyricsto "alto" \altoVerseOne
   \new Lyrics \with {
     alignAboveContext = "sa"
   } \lyricsto "ssoprano" \verseSopranoVoiceOne
  
   \new Staff = "tb" \with {

     instrumentName = \markup \center-column { "Tenor" "Bass" }
   } <<
     \clef bass
     \new Voice = "tenor" { \voiceOne \tenor }
     \new Voice = "bass" { \voiceTwo \bass }
   >>

\score {
   \choirPartI
   \layout { }
}

Am 21.05.2021 um 11:46 schrieb Bernhard Kleine:

Am 21.05.2021 um 11:09 schrieb Bernhard Kleine:

Hi,

this snippet raises an error


\new Dynamics = "page1" with {
   alignAboveContext = "sa"
     } \dynamicI


while this does not:


\new Dynamics = "page1" \dynamicI


What is the proper was to place the dynamic line above the staff?

The proper way!

BTW I googled for it and could not find it.


Hello,

This works over here:

\version "2.20.0"
\language "deutsch"
\header {
  title = "Ländler"
  tagline = "Bernhard Kleine 2021"
}
\paper {
  #(set-paper-size "a4")
}
global = {
  \key d \major
  \numericTimeSignature
  \time 3/4
}
soprano = \relative c'' {
  \global
  % Die Noten folgen hier.
  d4^\rfz^- fis,8 ([g]) fis ([g])| h4^^ a^. a^. | d^. d,8 ([e]) d ([e])
| g4^^ fis^. fis^.
}
dynamicI = {
%1
s8\mf s8\< s4. s8\! | s4 s4\> s8 s \! | s4\f  s4\< s8 s\! | s4 s4\> s8
s\! | s8^"cresc. poco a poco"\< s s4
  s8. s16\! s2.
}
sopranoVoice = \relative c' {
  \global
  \dynamicUp
  % Die Noten folgen hier.
  s2. s2. s2. s2. h4^.^^ d^. e^. | fis2^- r4 |
}
alto = \relative c' {
  \global
  % Die Noten folgen hier.
  fis4 d8 ([e]) d ([e]) | g4 fis fis | 4 h h|  e d d | h r r
    ais_._^ h_.\< cis_.\!
}
tenor = \relative c' {
  \global
  % Die Noten folgen hier.
  a4 a a | d d d  |fis, fis8 ([g]) fis ([g]) | h4 h h8 ([a])| g4 r r|
    cis,4. fis8 fis4 |
}
bass = \relative c {
  \global
  % Die Noten folgen hier.
  d4 d d | d d d8 ([cis]) | h4 h h | h h' h| R2. |
    fis,4 gis ais |
}
altoVerseOne = \lyricmode {
  \set stanza = "1."
  % Liedtext folgt hier.
  Mä -- del, der Lenz ist da, Mä -- del der Lenz ist da, la
  Mä -- del, gib acht!
}
verseSopranoVoiceOne = \lyricmode {
  % Liedtext folgt hier.
  Mä -- del gib acht!
}
choirPartI = \new ChoirStaff <<
  \new Staff = "sa" \with {
    instrumentName = \markup \center-column { "Sopran" "Alt" }
  } <<
    \new Dynamics = "page1" \with {
  alignAboveContext = "sa"
    }
    \dynamicI
    \new Voice = "soprano" { \voiceOne \soprano }
    \new Voice = "ssoprano" { \voiceOne \sopranoVoice }
    \new Voice = "alto" { \voiceTwo \alto }
  >>
  \new Lyrics \lyricsto "alto" \altoVerseOne
  \new Lyrics \with {
    alignAboveContext = "sa"
  } \lyricsto "ssoprano" \verseSopranoVoiceOne

  \new Staff = "tb" \with {
    instrumentName = \markup \center-column { "Tenor" "Bass" }
  } <<
    \clef bass
    \new Voice = "tenor" { \voiceOne \tenor }
    \new Voice = "bass" { \voiceTwo \bass }
  >>
>>

\score {
  \choirPartI
  \layout { }
}


Could you post a (small) code example that shows the failure? What is 
the error message? Did you try updating to the latest stable version 2.22.1?


Regards,
Jean

Re: Dynamics line above staff

[Bernhard Kleine]

here is the MWE:

\version "2.21.1"
\language "deutsch"
\header {
  title = "Ländler"
  tagline = "Bernhard Kleine 2021"
}
\paper {
  #(set-paper-size "a4")
}
global = {
  \key d \major
  \numericTimeSignature
  \time 3/4
}
soprano = \relative c'' {
  \global
  % Die Noten folgen hier.
  d4^\rfz^- fis,8 ([g]) fis ([g])| h4^^ a^. a^. | d^. d,8 ([e]) d ([e])
| g4^^ fis^. fis^.
}
dynamicI = {
%1
s8\mf s8\< s4. s8\! | s4 s4\> s8 s \! | s4\f  s4\< s8 s\! | s4 s4\> s8
s\! | s8^"cresc. poco a poco"\< s s4
  s8. s16\! s2.
}
sopranoVoice = \relative c' {
  \global
  \dynamicUp
  % Die Noten folgen hier.
  s2. s2. s2. s2. h4^.^^ d^. e^. | fis2^- r4 |
}
alto = \relative c' {
  \global
  % Die Noten folgen hier.
  fis4 d8 ([e]) d ([e]) | g4 fis fis | 4 h h|  e d d | h r r
    ais_._^ h_.\< cis_.\! 
}
tenor = \relative c' {
  \global
  % Die Noten folgen hier.
  a4 a a | d d d  |fis, fis8 ([g]) fis ([g]) | h4 h h8 ([a])| g4 r r|
    cis,4. fis8 fis4 | 
}
bass = \relative c {
  \global
  % Die Noten folgen hier.
  d4 d d | d d d8 ([cis]) | h4 h h | h h' h| R2. |
    fis,4 gis ais |  
}
altoVerseOne = \lyricmode {
  \set stanza = "1."
  % Liedtext folgt hier.
  Mä -- del, der Lenz ist da, Mä -- del der Lenz ist da, la
  Mä -- del, gib acht!
}
verseSopranoVoiceOne = \lyricmode {
  % Liedtext folgt hier.
  Mä -- del gib acht! 
}
choirPartI = \new ChoirStaff <<
  \new Staff = "sa" \with {
    instrumentName = \markup \center-column { "Sopran" "Alt" }
  } <<
    \new Dynamics = "page1"  \dynamicI
    \new Voice = "soprano" { \voiceOne \soprano }
    \new Voice = "ssoprano" { \voiceOne \sopranoVoice }
    \new Voice = "alto" { \voiceTwo \alto }
  >>
  \new Lyrics \lyricsto "alto" \altoVerseOne
  \new Lyrics \with {
    alignAboveContext = "sa" 
  } \lyricsto "ssoprano" \verseSopranoVoiceOne
 
  \new Staff = "tb" \with {
    instrumentName = \markup \center-column { "Tenor" "Bass" }
  } <<
    \clef bass
    \new Voice = "tenor" { \voiceOne \tenor }
    \new Voice = "bass" { \voiceTwo \bass }
  >>
>>


\score {
  \choirPartI
  \layout { }
}

Am 21.05.2021 um 11:46 schrieb Bernhard Kleine:
> Am 21.05.2021 um 11:09 schrieb Bernhard Kleine:
>> Hi,
>>
>> this snippet raises an error
>>
>>> \new Dynamics = "page1" with {
>>>   alignAboveContext = "sa"
>>>     } \dynamicI
>>>
>> while this does not:
>>
>>> \new Dynamics = "page1" \dynamicI
>>>
>> What is the proper was to place the dynamic line above the staff?
> The proper way!
>
> BTW I googled for it and could not find it.
>
-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics line above staff

[Bernhard Kleine]

Am 21.05.2021 um 11:09 schrieb Bernhard Kleine:
> Hi,
>
> this snippet raises an error
>
>> \new Dynamics = "page1" with {
>>   alignAboveContext = "sa"
>>     } \dynamicI
>>
> while this does not:
>
>> \new Dynamics = "page1" \dynamicI
>>
> What is the proper was to place the dynamic line above the staff?

The proper way!

BTW I googled for it and could not find it.

-- 

spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
Ich darf auf mein neues Buch "670 Falterarten im Hochschwarzwald" aufmerksam 
machen 
(Infos bei mir)
-
thunderbird
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




OpenPGP_signature
Description: OpenPGP digital signature

Re: Dynamics context doesn't work with polyphony(?)

[Martín Rincón Botero]

Hi Aaron,

thank you for your reply. I’ll try that later. Perhaps I should consider
having a separate dynamics variable in the long run though. Potential
issues like this could be so avoided by simply changing the problematic
line of code. That would also allow me to have both the “normal” dynamics
and the vertical aligned ones as needed, as suggested by other members in
my other threads.

Cheers
Martín.

On Fri 11. Sep 2020 at 12:25 Aaron Hill  wrote:

> On 2020-09-11 1:56 am, Martín Rincón Botero wrote:
>
> > Hello,
>
> >
>
> > sorry to bother again. I've been further exploring the Dynamics
>
> > context. I
>
> > just noticed that when there's a polyphonic passage, not only dynamics
>
> > don't align anymore, but also \remove engravers fails to do its job. Is
>
> > this a bug or is there any other engraver I should remove from the
>
> > Dynamics
>
> > context so that notes and text are not duplicated in polyphonic
>
> > passages?
>
>
>
> The issue seems to be with the << \\ >> construct implicitly referencing
>
> named Voice contexts.  Events within the Dynamics context are
>
> unintentionally leaking into the existing contexts and doubling the
>
> notes.  Consider:
>
>
>
> 
>
> \version "2.20.0"
>
>
>
> musicI = << b'2\f \\ { g'4 4 } >>
>
> << \new Voice \musicI \new Dynamics \musicI >>
>
>
>
> musicII = << \context Voice = "1" { \voiceOne b'2\f }
>
>   \context Voice = "2" { \voiceTwo g'4 4 } >>
>
> << \new Voice \musicII \new Dynamics \musicII >>
>
> 
>
>
>
> While I may be overlooking some details, the above expressions are
>
> logically equivalent.  That makes the << \\ >> construct tricky when
>
> being reused for Dynamics.
>
>
>
> Stripping out the VoiceSeparator *might* work:
>
>
>
> 
>
> removeVoiceSeparator =
>
> #(define-music-function (music) (ly:music?)
>
>(define (not-music-separator? m) (not (music-separator? m)))
>
>(music-filter not-music-separator? music))
>
>
>
> << \new Voice \musicI
>
> \new Dynamics \removeVoiceSeparator \musicI >>
>
> 
>
>
>
> Whether this brings about new issues, I could not say.
>
>
>
>
>
> -- Aaron Hill
>
>
>
> --
www.martinrinconbotero.com

Re: Dynamics context doesn't work with polyphony(?)

[Aaron Hill]

On 2020-09-11 1:56 am, Martín Rincón Botero wrote:

Hello,

sorry to bother again. I've been further exploring the Dynamics 
context. I

just noticed that when there's a polyphonic passage, not only dynamics
don't align anymore, but also \remove engravers fails to do its job. Is
this a bug or is there any other engraver I should remove from the 
Dynamics
context so that notes and text are not duplicated in polyphonic 
passages?


The issue seems to be with the << \\ >> construct implicitly referencing 
named Voice contexts.  Events within the Dynamics context are 
unintentionally leaking into the existing contexts and doubling the 
notes.  Consider:



\version "2.20.0"

musicI = << b'2\f \\ { g'4 4 } >>
<< \new Voice \musicI \new Dynamics \musicI >>

musicII = << \context Voice = "1" { \voiceOne b'2\f }
 \context Voice = "2" { \voiceTwo g'4 4 } >>
<< \new Voice \musicII \new Dynamics \musicII >>


While I may be overlooking some details, the above expressions are 
logically equivalent.  That makes the << \\ >> construct tricky when 
being reused for Dynamics.


Stripping out the VoiceSeparator *might* work:


removeVoiceSeparator =
#(define-music-function (music) (ly:music?)
  (define (not-music-separator? m) (not (music-separator? m)))
  (music-filter not-music-separator? music))

<< \new Voice \musicI
   \new Dynamics \removeVoiceSeparator \musicI >>


Whether this brings about new issues, I could not say.


-- Aaron Hill

Re: Dynamics context

[Knute Snortum]

Here is an example of using custom dynamic spanners in the Dynamic Context:

%%%
\version "2.20.0"

rh = \relative c' {
  c4 c c c|
  d4^\mf d d d|
}

lh = \relative c {
  \clef bass
  f4_\mp f f f |
  g4 g g g |
}

dyn = \relative {
  s4\ff s s s\pp |
  \override TextSpanner.bound-details.left.text = "rit."
  s4\startTextSpan s s s\stopTextSpan |
}

\score {
  <<
\new Staff \rh
\new Dynamics \dyn
\new Staff \lh
  >>
}
%%%

It also shows my take on how to use dynamics, with some of them being
on the Dynamic Context and the others, if needed, on the Staff.  I
transcribe mostly piano music and this works well for me, but YMMV.
---
Knute Snortum
(via Gmail)


---
Knute Snortum
(via Gmail)


On Tue, Sep 8, 2020 at 12:16 PM Martín Rincón Botero
 wrote:
>
> Hey Ben,
>
> good question. I write contemporary classical music. In my score, for 
> example, I have an independent tempo variable as a workaround for the current 
> Lilypond lack of "tempo spanners" like rit., accel., etc. I merge this 
> together in the score, and in the parts. Though not ideal, this is a minor 
> inconvenience, since tempi are not something that changes so often, not even 
> in CCM. But dynamics are something that changes very quickly. In my music, 
> it's not seldom to see four dynamics in one measure. An independent dynamics 
> variable full of spacers is thus cumbersome, since the variable where the 
> actual music is, would have to be stripped of dynamics information, or I 
> would have to remove the dynamics engraver and duplicate the corresponding 
> dynamics to the variable full of spacers. With whatever option, when writing 
> a new phrase, I would have to write everything in the music variable and then 
> go to the dynamics variable, count the rhythms (which often includes tuplets) 
> and add the dynamics. This is not really an efficient way to compose! :-). 
> The music variable wouldn't look as readable to me without the dynamics. 
> Lilypond's syntax is basically its "interface", and an independent dynamics 
> variable, if not used as such (see the case of band music above), reduces 
> "usability", in my opinion. So I would say the only pro of using a separate 
> dynamic variable is that you can reuse a dynamic variable. The same can be 
> said of basically every variable. For the sake of keeping a more readable 
> syntax, though, in case I would really need to call the same dynamics (even 
> in concert band music!), I would rather put my music with its normal syntax, 
> make it into a section variable and call the section variables from a 
> dynamics context, using the technique described by Xavier. That way the 
> Lilypond syntax can remain unaffected.
>
> As for what I started using the dynamics context, yes, it is alignment 
> concerns. Lilypond's default behavior of making dynamics only aware of 
> crescendi/decrescendi is not ideal.
>
> Cheers,
> Martín.
>
> Am Di., 8. Sept. 2020 um 20:52 Uhr schrieb Ben :
>>
>> On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:
>>
>> Hi Wol,
>>
>> yes, what you mention is indeed a good case for using dynamics in their own 
>> variable. The problem comes when using a Dynamics context from an 
>> independent dynamics variable for music that by its own nature is not really 
>> compatible with that approach, or for which the resulting code looks/feels 
>> clumsy. Btw. if you have your dynamics already in a different variable, 
>> maybe you could give the Dynamics context a shot! ;-).
>>
>> Cheers,
>> Martín.
>>
>> Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists 
>> :
>>>
>>> On 07/09/2020 17:01, Martín Rincón Botero wrote:
>>> > I wanted to ask if using the Dynamics context is the simplest way
>>> > available in Lilypond for achieving this kind of vertically aligned
>>> > dynamics. The huge drawback of the Dynamics context is that it disrupts
>>> > the syntax, since dynamics can’t be used next to the first note they’re
>>> > attached to, but instead they need a separate variable, reducing
>>> > readability of the actual “music”.
>>>
>>> Just to throw my two-pennorth in, while I didn't know about the dynamics
>>> context, I've started separating dynamics out ...
>>>
>>> I do band parts, and if the dynamics are replicated across, say, all
>>> trombones I find it easier to have the notes in one variable, the
>>> dynamics in another, and to merge them for each part. Especially as,
>>> although I haven't really been doing scores, I can then merge all the
>>> trombone parts, and the dynamics, to put them on one line of the score.
>>>
>>> It's not unusual for different instruments to have different dynamics,
>>> as usually the cornets have the melody in the first section, then the
>>> bass instruments in the trio, often with the middle instruments such as
>>> trombones and euphs having a middle section. So whoever's got the melody
>>> might be ff, with the others p underneath.
>>>
>>> At the end of the day, horses for courses and if it doesn't work for you
>>> then fine. But it does 

Re: Dynamics context

[Martín Rincón Botero]

Hey Ben,

good question. I write contemporary classical music. In my score, for
example, I have an independent tempo variable as a workaround for the
current Lilypond lack of "tempo spanners" like rit., accel., etc. I merge
this together in the score, and in the parts. Though not ideal, this is a
minor inconvenience, since tempi are not something that changes so often,
not even in CCM. But dynamics are something that changes very quickly. In
my music, it's not seldom to see four dynamics in one measure. An
independent dynamics variable full of spacers is thus cumbersome, since the
variable where the actual music is, would have to be stripped of dynamics
information, or I would have to remove the dynamics engraver and duplicate
the corresponding dynamics to the variable full of spacers. With whatever
option, when writing a new phrase, I would have to write everything in the
music variable and then go to the dynamics variable, count the rhythms
(which often includes tuplets) and add the dynamics. This is not really an
efficient way to compose! :-). The music variable wouldn't look as readable
to me without the dynamics. Lilypond's syntax is basically its "interface",
and an independent dynamics variable, if not used as such (see the case of
band music above), reduces "usability", in my opinion. So I would say the
only pro of using a separate dynamic variable is that you can reuse a
dynamic variable. The same can be said of basically every variable. For the
sake of keeping a more readable syntax, though, in case I would really need
to call the same dynamics (even in concert band music!), I would rather put
my music with its normal syntax, make it into a section variable and call
the section variables from a dynamics context, using the technique
described by Xavier. That way the Lilypond syntax can remain unaffected.

As for what I started using the dynamics context, yes, it is alignment
concerns. Lilypond's default behavior of making dynamics only aware of
crescendi/decrescendi is not ideal.

Cheers,
Martín.

Am Di., 8. Sept. 2020 um 20:52 Uhr schrieb Ben :

> On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:
>
> Hi Wol,
>
> yes, what you mention is indeed a good case for using dynamics in their
> own variable. The problem comes when using a Dynamics context from an
> independent dynamics variable for music that by its own nature is not
> really compatible with that approach, or for which the resulting code
> looks/feels clumsy. Btw. if you have your dynamics already in a different
> variable, maybe you could give the Dynamics context a shot! ;-).
>
> Cheers,
> Martín.
>
> Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <
> antli...@youngman.org.uk>:
>
>> On 07/09/2020 17:01, Martín Rincón Botero wrote:
>> > I wanted to ask if using the Dynamics context is the simplest way
>> > available in Lilypond for achieving this kind of vertically aligned
>> > dynamics. The huge drawback of the Dynamics context is that it disrupts
>> > the syntax, since dynamics can’t be used next to the first note they’re
>> > attached to, but instead they need a separate variable, reducing
>> > readability of the actual “music”.
>>
>> Just to throw my two-pennorth in, while I didn't know about the dynamics
>> context, I've started separating dynamics out ...
>>
>> I do band parts, and if the dynamics are replicated across, say, all
>> trombones I find it easier to have the notes in one variable, the
>> dynamics in another, and to merge them for each part. Especially as,
>> although I haven't really been doing scores, I can then merge all the
>> trombone parts, and the dynamics, to put them on one line of the score.
>>
>> It's not unusual for different instruments to have different dynamics,
>> as usually the cornets have the melody in the first section, then the
>> bass instruments in the trio, often with the middle instruments such as
>> trombones and euphs having a middle section. So whoever's got the melody
>> might be ff, with the others p underneath.
>>
>> At the end of the day, horses for courses and if it doesn't work for you
>> then fine. But it does work for people like me :-)
>>
>> Cheers,
>> Wol
>>
>>
>
> --
> www.martinrinconbotero.com
>
> Martín,
>
> I'm curious: what would you say the pros/cons are for using a dynamics
> context vs. a separate dynamics variable in your input files? (which
> scenario to use which, etc) -- is it alignment concerns?
>
>
>

-- 
www.martinrinconbotero.com

Re: Dynamics context

[Paul Scott]

> On Sep 8, 2020, at 11:50 AM, Ben  wrote:
> 
> On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:

(snip)

>> 
>> 
>> -- 
>> www.martinrinconbotero.com 
> Martín,
> 
> I'm curious: what would you say the pros/cons are for using a dynamics 
> context vs. a separate dynamics variable in your input files? (which scenario 
> to use which, etc) -- is it alignment concerns?
> 

This may have been said but I believe a dynamic variable can be in a dynamic 
context.

Paul

Re: Dynamics context

[Ben]

On 9/8/2020 2:05 PM, Martín Rincón Botero wrote:

Hi Wol,

yes, what you mention is indeed a good case for using dynamics in 
their own variable. The problem comes when using a Dynamics context 
from an independent dynamics variable for music that by its own nature 
is not really compatible with that approach, or for which the 
resulting code looks/feels clumsy. Btw. if you have your dynamics 
already in a different variable, maybe you could give the Dynamics 
context a shot! ;-).


Cheers,
Martín.

Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists 
mailto:antli...@youngman.org.uk>>:


On 07/09/2020 17:01, Martín Rincón Botero wrote:
> I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics. The huge drawback of the Dynamics context is that it
disrupts
> the syntax, since dynamics can’t be used next to the first note
they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.

Just to throw my two-pennorth in, while I didn't know about the
dynamics
context, I've started separating dynamics out ...

I do band parts, and if the dynamics are replicated across, say, all
trombones I find it easier to have the notes in one variable, the
dynamics in another, and to merge them for each part. Especially as,
although I haven't really been doing scores, I can then merge all the
trombone parts, and the dynamics, to put them on one line of the
score.

It's not unusual for different instruments to have different
dynamics,
as usually the cornets have the melody in the first section, then the
bass instruments in the trio, often with the middle instruments
such as
trombones and euphs having a middle section. So whoever's got the
melody
might be ff, with the others p underneath.

At the end of the day, horses for courses and if it doesn't work
for you
then fine. But it does work for people like me :-)

Cheers,
Wol



--
www.martinrinconbotero.com 


Martín,

I'm curious: what would you say the pros/cons are for using a dynamics 
context vs. a separate dynamics variable in your input files? (which 
scenario to use which, etc) -- is it alignment concerns?

Re: Dynamics context

[Paul Scott]

> On Sep 8, 2020, at 9:03 AM, antlists  wrote:
> 
> On 07/09/2020 17:01, Martín Rincón Botero wrote:
>> I wanted to ask if using the Dynamics context is the simplest way available 
>> in Lilypond for achieving this kind of vertically aligned dynamics. The huge 
>> drawback of the Dynamics context is that it disrupts the syntax, since 
>> dynamics can’t be used next to the first note they’re attached to, but 
>> instead they need a separate variable, reducing readability of the actual 
>> “music”.
> 
> Just to throw my two-pennorth in, while I didn't know about the dynamics 
> context, I've started separating dynamics out ...
> 
> I do band parts, and if the dynamics are replicated across, say, all 
> trombones I find it easier to have the notes in one variable, the dynamics in 
> another, and to merge them for each part. Especially as, although I haven't 
> really been doing scores, I can then merge all the trombone parts, and the 
> dynamics, to put them on one line of the score.
> 
> It's not unusual for different instruments to have different dynamics, as 
> usually the cornets have the melody in the first section, then the bass 
> instruments in the trio, often with the middle instruments such as trombones 
> and euphs having a middle section. So whoever's got the melody might be ff, 
> with the others p underneath.
> 
> At the end of the day, horses for courses and if it doesn't work for you then 
> fine. But it does work for people like me :-)

I do a separate dynamics variables also.  Sometimes there is a complicated 
sequence of spacings shared between my global and dynamics variables which I 
put in a separate variable to save typoing.

Stay safe all,

Paul

Re: Dynamics context

[Martín Rincón Botero]

Hi Wol,

yes, what you mention is indeed a good case for using dynamics in their own
variable. The problem comes when using a Dynamics context from an
independent dynamics variable for music that by its own nature is not
really compatible with that approach, or for which the resulting code
looks/feels clumsy. Btw. if you have your dynamics already in a different
variable, maybe you could give the Dynamics context a shot! ;-).

Cheers,
Martín.

Am Di., 8. Sept. 2020 um 18:06 Uhr schrieb antlists <
antli...@youngman.org.uk>:

> On 07/09/2020 17:01, Martín Rincón Botero wrote:
> > I wanted to ask if using the Dynamics context is the simplest way
> > available in Lilypond for achieving this kind of vertically aligned
> > dynamics. The huge drawback of the Dynamics context is that it disrupts
> > the syntax, since dynamics can’t be used next to the first note they’re
> > attached to, but instead they need a separate variable, reducing
> > readability of the actual “music”.
>
> Just to throw my two-pennorth in, while I didn't know about the dynamics
> context, I've started separating dynamics out ...
>
> I do band parts, and if the dynamics are replicated across, say, all
> trombones I find it easier to have the notes in one variable, the
> dynamics in another, and to merge them for each part. Especially as,
> although I haven't really been doing scores, I can then merge all the
> trombone parts, and the dynamics, to put them on one line of the score.
>
> It's not unusual for different instruments to have different dynamics,
> as usually the cornets have the melody in the first section, then the
> bass instruments in the trio, often with the middle instruments such as
> trombones and euphs having a middle section. So whoever's got the melody
> might be ff, with the others p underneath.
>
> At the end of the day, horses for courses and if it doesn't work for you
> then fine. But it does work for people like me :-)
>
> Cheers,
> Wol
>
>

-- 
www.martinrinconbotero.com

Re: Dynamics context

[Martín Rincón Botero]

Dear Xavier,

thank you very much again. This works as expected! I also find this
solution more powerful than the one suggested in the Snippet Repository
http://lsr.di.unimi.it/LSR/Item?id=450. This last command however, preceded
with \once, is the one I normally use when manually positioning a dynamic.
This command doesn't work anymore if dynamics are sent to the dynamics
context. This is something I can live with, since the Dynamics context
already provides the result I want for the majority of cases, but I wonder
if it's possible to use a similar override/tweak for the one case where a
dynamic is not placed to my taste.

Best regards,
Martín.

Am Di., 8. Sept. 2020 um 11:58 Uhr schrieb Xavier Scheuer <
x.sche...@gmail.com>:

> On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <
> martinrinconbot...@gmail.com> wrote:
> >
> > For I which I get the attached result. Weirdly, with this minimal
> example I'm also getting a bunch of "script direction not yet known". I
> don't think that was happening before. Anyways, the visual result is the
> same I was getting with the full code, with duplicated articulations and
> text.
>
> Hello Martin,
>
> Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
> You might also want to remove "Text_spanner_engraver" if you have
> TextSpanners in your music.
>
>  \layout {
> \context {
>   \Dynamics
>   \override
> VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
>   \remove "Script_engraver"
>   \remove "Text_engraver"
>   % \remove "Text_spanner_engraver"
> }
>   }
>
> The list of engravers the Dynamics is built from is documented in the
> Internals Reference manual.
> IR 2.1.7 Dynamics
> http://lilypond.org/doc/v2.20/Documentation/internals/dynamics
>
> Cheers,
> Xavier
>
> --
> Xavier Scheuer 
>
>

-- 
www.martinrinconbotero.com

Re: Dynamics context

[antlists]

On 07/09/2020 17:01, Martín Rincón Botero wrote:
I wanted to ask if using the Dynamics context is the simplest way 
available in Lilypond for achieving this kind of vertically aligned 
dynamics. The huge drawback of the Dynamics context is that it disrupts 
the syntax, since dynamics can’t be used next to the first note they’re 
attached to, but instead they need a separate variable, reducing 
readability of the actual “music”.


Just to throw my two-pennorth in, while I didn't know about the dynamics 
context, I've started separating dynamics out ...


I do band parts, and if the dynamics are replicated across, say, all 
trombones I find it easier to have the notes in one variable, the 
dynamics in another, and to merge them for each part. Especially as, 
although I haven't really been doing scores, I can then merge all the 
trombone parts, and the dynamics, to put them on one line of the score.


It's not unusual for different instruments to have different dynamics, 
as usually the cornets have the melody in the first section, then the 
bass instruments in the trio, often with the middle instruments such as 
trombones and euphs having a middle section. So whoever's got the melody 
might be ff, with the others p underneath.


At the end of the day, horses for courses and if it doesn't work for you 
then fine. But it does work for people like me :-)


Cheers,
Wol

Re: Dynamics context

[Martín Rincón Botero]

Thank you very much, Xavier. I’ll try that!

On Tue 8. Sep 2020 at 11:58 Xavier Scheuer  wrote:

> On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <
> martinrinconbot...@gmail.com> wrote:
> >
> > For I which I get the attached result. Weirdly, with this minimal
> example I'm also getting a bunch of "script direction not yet known". I
> don't think that was happening before. Anyways, the visual result is the
> same I was getting with the full code, with duplicated articulations and
> text.
>
> Hello Martin,
>
> Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
> You might also want to remove "Text_spanner_engraver" if you have
> TextSpanners in your music.
>
>  \layout {
> \context {
>   \Dynamics
>   \override
> VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
>   \remove "Script_engraver"
>   \remove "Text_engraver"
>   % \remove "Text_spanner_engraver"
> }
>   }
>
>
>
> The list of engravers the Dynamics is built from is documented in the
> Internals Reference manual.
> IR 2.1.7 Dynamics
> http://lilypond.org/doc/v2.20/Documentation/internals/dynamics
>
>
>
>
>
> Cheers,
> Xavier
>
>
> --
> Xavier Scheuer 
>
>
>
> --
www.martinrinconbotero.com

Re: Dynamics context

[Xavier Scheuer]

On Tue, 8 Sep 2020 at 11:18, Martín Rincón Botero <
martinrinconbot...@gmail.com> wrote:
>
> For I which I get the attached result. Weirdly, with this minimal example
I'm also getting a bunch of "script direction not yet known". I don't think
that was happening before. Anyways, the visual result is the same I was
getting with the full code, with duplicated articulations and text.

Hello Martin,

Remove "Script_engraver" and "Text_engraver" from the Dynamics context.
You might also want to remove "Text_spanner_engraver" if you have
TextSpanners in your music.

 \layout {
\context {
  \Dynamics
  \override
VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
  \remove "Script_engraver"
  \remove "Text_engraver"
  % \remove "Text_spanner_engraver"
}
  }

The list of engravers the Dynamics is built from is documented in the
Internals Reference manual.
IR 2.1.7 Dynamics
http://lilypond.org/doc/v2.20/Documentation/internals/dynamics

Cheers,
Xavier

-- 
Xavier Scheuer 

Re: Dynamics context

[Martín Rincón Botero]

Hi Kieren,

thank you for your answer. Here a MWE:

\version "2.20.0"

scoreAViolinI = \relative c'' {
r2 r4 d,16-.\p\< dis'-. e-. g-.
fis,4:32->\ff\>^"sul pont." r\! r2
}

\score {
  <<
  \new Voice \with { \remove "Dynamic_engraver" } \scoreAViolinI
\new Dynamics \scoreAViolinI  >>

 \layout {
 \context {
\Dynamics
\override
VerticalAxisGroup.nonstaff-relatedstaff-spacing.basic-distance = #0
  }
  }
}

For I which I get the attached result. Weirdly, with this minimal example
I'm also getting a bunch of "script direction not yet known". I don't think
that was happening before. Anyways, the visual result is the same I was
getting with the full code, with duplicated articulations and text.

Am Mo., 7. Sept. 2020 um 18:27 Uhr schrieb Kieren MacMillan <
kieren_macmil...@sympatico.ca>:

> Hi Martín,
>
> > I wanted to ask if using the Dynamics context is the simplest way
> available in Lilypond for achieving this kind of vertically aligned
> dynamics.
>
> I believe so.
>
> > The huge drawback of the Dynamics context is that it disrupts the
> syntax, since dynamics can’t be used next to the first note they’re
> attached to, but instead they need a separate variable, reducing
> readability of the actual “music”.
>
> I imagine three possible ways to solve this problem, while being able to
> enter all input (notes, dynamics, etc.) in a single variable:
>
> 1. Send the variable into two different contexts, one (the "Staff") which
> strips all dynamic events, and one (the "Dynamics") which contains only
> dynamic events. It seems like this is what you tried to do, but failed at —
> perhaps if you include a MWE, we can all work with it and see how it can be
> improved.
>
> 2. Have a mechanism like "\change Staff" which allows you to "push"
> dynamic events into a separate context (the way that staff changes "pushes"
> notes into a different staff context).
>
> 3. Write an engraver that does the extraction/removal/addition
> automagically.
>
> I have not put a lot of effort (or even thought) into seeing which of
> these is even possible in Lilypond… but maybe this thread will inspire the
> community (including me) to do so?
>
> Best,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info
>
>

-- 
www.martinrinconbotero.com

Re: Dynamics context

[Kieren MacMillan]

Hi Martín,

> I wanted to ask if using the Dynamics context is the simplest way available 
> in Lilypond for achieving this kind of vertically aligned dynamics.

I believe so.

> The huge drawback of the Dynamics context is that it disrupts the syntax, 
> since dynamics can’t be used next to the first note they’re attached to, but 
> instead they need a separate variable, reducing readability of the actual 
> “music”.

I imagine three possible ways to solve this problem, while being able to enter 
all input (notes, dynamics, etc.) in a single variable:

1. Send the variable into two different contexts, one (the "Staff") which 
strips all dynamic events, and one (the "Dynamics") which contains only dynamic 
events. It seems like this is what you tried to do, but failed at — perhaps if 
you include a MWE, we can all work with it and see how it can be improved.

2. Have a mechanism like "\change Staff" which allows you to "push" dynamic 
events into a separate context (the way that staff changes "pushes" notes into 
a different staff context).

3. Write an engraver that does the extraction/removal/addition automagically.

I have not put a lot of effort (or even thought) into seeing which of these is 
even possible in Lilypond… but maybe this thread will inspire the community 
(including me) to do so?

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Dynamics offset suddenly changes

[David Nalesnik]

Hi Andrew,

I couldn't answer that question without some sort of code example.

Best,
David

On Tue, 26 Mar 2019, 5:24 p.m. Andrew Bernard, 
wrote:

> Hi David,
>
> Why does \alterBroken move some and not others?
>
> Andrew
>
>
> On Wed, 27 Mar 2019 at 02:18, David Nalesnik 
> wrote:
>
>>
>> But you are applying alterBroken to the Hairpin, not to the
>> DynamicLineSpanner, so of course the Hairpin will be moved
>> independently.
>>
>>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi David,

Why does \alterBroken move some and not others?

Andrew


On Wed, 27 Mar 2019 at 02:18, David Nalesnik 
wrote:

>
> But you are applying alterBroken to the Hairpin, not to the
> DynamicLineSpanner, so of course the Hairpin will be moved
> independently.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[David Nalesnik]

On Tue, Mar 26, 2019 at 8:38 AM Andrew Bernard  wrote:
>
> Hi David,
>
> What I mean is that I thought alterBroken just affected the single shot 
> hairpin (wrong). In my score I have about 200 pages where there are hairpins 
> ending on dynamics on the next page, and after the erroneous call to 
> \alterBroken to adjust Y-offset, only some hairpins 80 pages or so away were 
> affected (and no wonder I had forgotten about the alterBroken in the 
> meantime).
>
> It's not a suspect, it's the perpetrator beyond doubt. The issue is resolved 
> for my practical purposes, but I still wonder is this is a bug. Maybe I can 
> cook up an MWE now.
>
> Andrew

But you are applying alterBroken to the Hairpin, not to the
DynamicLineSpanner, so of course the Hairpin will be moved
independently.

David

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

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi David,

What I mean is that I thought alterBroken just affected the single shot
hairpin (wrong). In my score I have about 200 pages where there are
hairpins ending on dynamics on the next page, and after the erroneous call
to \alterBroken to adjust Y-offset, only some hairpins 80 pages or so away
were affected (and no wonder I had forgotten about the alterBroken in the
meantime).

It's not a suspect, it's the perpetrator beyond doubt. The issue is
resolved for my practical purposes, but I still wonder is this is a bug.
Maybe I can cook up an MWE now.

Andrew


On Wed, 27 Mar 2019 at 00:16, David Nalesnik 
wrote:

> On Tue, Mar 26, 2019 at 8:07 AM Andrew Bernard 
> wrote:
> >
> > Hi David,
> >
> > Aha! But it's funny that it only affects some down the line, with many
> of the same case not being affected.
> >
> > Andrew
> >
>
> I'm not clear what you mean here.  But, if you suspect \alterBroken,
> you could retool the code given at
> http://lilypond.org/doc/v2.19/Documentation/extending/difficult-tweaks
> to suit your Hairpins.  This "difficult tweak," after all, is the
> technique that \alterBroken elaborates on.
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi David,

Aha! But it's funny that it only affects some down the line, with many of
the same case not being affected.

Andrew


On Tue, 26 Mar 2019 at 23:40, David Nalesnik 
wrote:

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

Re: Dynamics offset suddenly changes

[David Nalesnik]

On Tue, Mar 26, 2019 at 8:07 AM Andrew Bernard  wrote:
>
> Hi David,
>
> Aha! But it's funny that it only affects some down the line, with many of the 
> same case not being affected.
>
> Andrew
>

I'm not clear what you mean here.  But, if you suspect \alterBroken,
you could retool the code given at
http://lilypond.org/doc/v2.19/Documentation/extending/difficult-tweaks
to suit your Hairpins.  This "difficult tweak," after all, is the
technique that \alterBroken elaborates on.

David


>
> On Tue, 26 Mar 2019 at 23:40, David Nalesnik  wrote:
>>
>>
>> \once \alterBroken ...
>>

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

Re: Dynamics offset suddenly changes

[David Nalesnik]

On Tue, Mar 26, 2019 at 6:07 AM Andrew Bernard  wrote:
>
> Hi All,
>
> Thanks to Aaron's wonderful hairpin colouring function I have been able to 
> really focus in on the hairpin behaviour.
>
> I found the issue with my score. I am somewhat dumbstruck by this. There is a 
> call as follows at one and only point point in the score:
>
> \alterBroken Y-offset #'(0 4) Hairpin
>
> This makes the misalignment problem arise at quite a few places, but 80-90 
> pages later.
>
> I have recollection from somewhere that using alterBroken can have some 
> downsides, but I do not know what.
>
> However, would this not be classified as a bug?

\once \alterBroken ...

>
> Andrew
>
>
>
> On Tue, 26 Mar 2019 at 13:13, Aaron Hill  wrote:
>>
>> Sorry, Andrew.  I've been buried in work for my choir.  Allow me to try
>> to address the questions/comments in a single mail to catch up.
>>
>> 
>>
>> On 2019-03-25 5:04 pm, Andrew Bernard wrote:
>> > The pink arrow lines - how does lilypond work out this distance? It
>> > seems
>> > to be that that is jumping around. Can you help me understand that?
>>
>> The pink lines are hard-coded as part of my demonstration of using a
>> specific value for minimum-space.  It was meant only to visually depict
>> the offset, as it can be hard to count staff spaces outside the staff
>> itself.
>>
>> What I could have done was this:
>>
>> 
>>%% Overlay reference lines.
>>\override Hairpin.stencil =
>>  #(grob-transformer 'stencil (lambda (grob orig)
>>(let* ((p (ly:grob-object grob 'axis-group-parent-Y))
>>   (y (ly:grob-property p 'minimum-space)))
>>  (grob-interpret-markup grob #{
>>\markup \with-dimensions-from \stencil $orig \overlay {
>>  \with-color #(rgb-color 0.4 0.7 1.0)
>>  \path #0.2 #'((moveto -8 0) (lineto 8 0))
>>  \with-color #(rgb-color 1.0 0.4 0.7)
>>  \path #0.2 #`((moveto 0 0) (lineto 0 ,y)
>>(moveto -2 ,y) (lineto 2 ,y)
>>(moveto -1 ,(- y 1.5)) (lineto 0 ,y)
>>(lineto 1 ,(- y 1.5)))
>>  \stencil $orig } #}
>> 
>>
>> NOTE: I omitted the \once so this will draw on all Hairpins.  As such, I
>> shortened the blue line.
>>
>> Here this is only just for visualizing minimum-space, but it does not
>> account for all of the possible factors that affect vertical
>> positioning.  Again note that in my other example, I zeroed out several
>> of the padding properties to make things work.
>>
>> 
>>
>> On 2019-03-25 4:42 pm, Andrew Bernard wrote:
>> > Hi Aaron,
>> >
>> > Thank you for looking into this. As mentioned in my original post, I am
>> > not
>> > using a Dynamics context as this New Complexity score is very, very
>> > complex
>> > rhythmically, and it would tale a month to go back and figure out all
>> > the
>> > spacer rests to use a dynamics context. I'd rather not do that, but I
>> > can
>> > see where this is going.
>>
>> As I showed in my prior email, you do not technically need to do
>> anything a second time.  You should be able to instanciate your music
>> twice: once for the \Staff and a second time for \Dynamics.  It should
>> only then be a matter of \omitting any dynamics-related grobs from the
>> Staff.  Of course, this tactic may not work depending on how "dirty"
>> your music variables are.  If they are pretty clean and just represent
>> pitches and durations with dynamics attached, it should work as I
>> showed.
>>
>> For cases when the music is muddled with things that the \Dynamics
>> context is not by default ignoring, it would fall to the task of using
>> map-some-music and a suitable procedure for extracting only the elements
>> you want.  Basically, I agree that you should not have to do extra work.
>>   You have already indicated the dynamics you want and when.  The tactic
>> now is to leverage the power of the computer to split out the things you
>> want in \Dynamics apart from the things you want on the \Staff.
>>
>> Unfortunately, I am running a bit out of time to dig into this further.
>> And it could very well have already come up before, so I'd encourage a
>> thorough search through the archives and the LSR.
>>
>> > This was all fine until the score reached a certain number of pages. I
>> > suppose I can go chopping pages out to see what may be going on there.
>> > I
>> > tried 2.19.82 and 2.19.83, so I don't think there is an issue with the
>> > version.
>> >
>> > I mention again that this started happening as the score grew large,
>> > making
>> > me think there is some kind of memory management issue lurking around.
>> > I am
>> > completely unable to prove this.
>>
>> I would expect memory bugs to result in crashes rather than simple and
>> consistent misalignment of elements.  But stranger things have happened.
>>
>> You may have another strategy here.  You mention that problems happen at
>> scale, so would it make sense to break up the piece into smaller
>> sections that 

Re: Dynamics offset suddenly changes

[David Kastrup]

Andrew Bernard  writes:

> Hi Aaron,
>
> Thank you for looking into this. As mentioned in my original post, I am not
> using a Dynamics context as this New Complexity score is very, very complex
> rhythmically, and it would tale a month to go back and figure out all the
> spacer rests to use a dynamics context. I'd rather not do that, but I can
> see where this is going.

You can just use the same content but remove the pertinent engravers for
dynamics in your main staves and just use the dynamics-relevant
engravers in the dynamics staff.

> This was all fine until the score reached a certain number of pages. I
> suppose I can go chopping pages out to see what may be going on
> there. I tried 2.19.82 and 2.19.83, so I don't think there is an issue
> with the version.
>
> I mention again that this started happening as the score grew large,
> making me think there is some kind of memory management issue lurking
> around. I am completely unable to prove this.

That may well be, and using a Dynamics context is likely to change
behavior (whether for the better or the worse is a matter of luck, but
if you start out bad, where else would you have to go?) since it is an
invasive restructuring of content.

-- 
David Kastrup

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

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi All,

Thanks to Aaron's wonderful hairpin colouring function I have been able to
really focus in on the hairpin behaviour.

I found the issue with my score. I am somewhat dumbstruck by this. There is
a call as follows at one and only point point in the score:

\alterBroken Y-offset #'(0 4) Hairpin

This makes the misalignment problem arise at quite a few places, but 80-90
pages later.

I have recollection from somewhere that using alterBroken can have some
downsides, but I do not know what.

However, would this not be classified as a bug?

Andrew



On Tue, 26 Mar 2019 at 13:13, Aaron Hill  wrote:

> Sorry, Andrew.  I've been buried in work for my choir.  Allow me to try
> to address the questions/comments in a single mail to catch up.
>
> 
>
> On 2019-03-25 5:04 pm, Andrew Bernard wrote:
> > The pink arrow lines - how does lilypond work out this distance? It
> > seems
> > to be that that is jumping around. Can you help me understand that?
>
> The pink lines are hard-coded as part of my demonstration of using a
> specific value for minimum-space.  It was meant only to visually depict
> the offset, as it can be hard to count staff spaces outside the staff
> itself.
>
> What I could have done was this:
>
> 
>%% Overlay reference lines.
>\override Hairpin.stencil =
>  #(grob-transformer 'stencil (lambda (grob orig)
>(let* ((p (ly:grob-object grob 'axis-group-parent-Y))
>   (y (ly:grob-property p 'minimum-space)))
>  (grob-interpret-markup grob #{
>\markup \with-dimensions-from \stencil $orig \overlay {
>  \with-color #(rgb-color 0.4 0.7 1.0)
>  \path #0.2 #'((moveto -8 0) (lineto 8 0))
>  \with-color #(rgb-color 1.0 0.4 0.7)
>  \path #0.2 #`((moveto 0 0) (lineto 0 ,y)
>(moveto -2 ,y) (lineto 2 ,y)
>(moveto -1 ,(- y 1.5)) (lineto 0 ,y)
>(lineto 1 ,(- y 1.5)))
>  \stencil $orig } #}
> 
>
> NOTE: I omitted the \once so this will draw on all Hairpins.  As such, I
> shortened the blue line.
>
> Here this is only just for visualizing minimum-space, but it does not
> account for all of the possible factors that affect vertical
> positioning.  Again note that in my other example, I zeroed out several
> of the padding properties to make things work.
>
> 
>
> On 2019-03-25 4:42 pm, Andrew Bernard wrote:
> > Hi Aaron,
> >
> > Thank you for looking into this. As mentioned in my original post, I am
> > not
> > using a Dynamics context as this New Complexity score is very, very
> > complex
> > rhythmically, and it would tale a month to go back and figure out all
> > the
> > spacer rests to use a dynamics context. I'd rather not do that, but I
> > can
> > see where this is going.
>
> As I showed in my prior email, you do not technically need to do
> anything a second time.  You should be able to instanciate your music
> twice: once for the \Staff and a second time for \Dynamics.  It should
> only then be a matter of \omitting any dynamics-related grobs from the
> Staff.  Of course, this tactic may not work depending on how "dirty"
> your music variables are.  If they are pretty clean and just represent
> pitches and durations with dynamics attached, it should work as I
> showed.
>
> For cases when the music is muddled with things that the \Dynamics
> context is not by default ignoring, it would fall to the task of using
> map-some-music and a suitable procedure for extracting only the elements
> you want.  Basically, I agree that you should not have to do extra work.
>   You have already indicated the dynamics you want and when.  The tactic
> now is to leverage the power of the computer to split out the things you
> want in \Dynamics apart from the things you want on the \Staff.
>
> Unfortunately, I am running a bit out of time to dig into this further.
> And it could very well have already come up before, so I'd encourage a
> thorough search through the archives and the LSR.
>
> > This was all fine until the score reached a certain number of pages. I
> > suppose I can go chopping pages out to see what may be going on there.
> > I
> > tried 2.19.82 and 2.19.83, so I don't think there is an issue with the
> > version.
> >
> > I mention again that this started happening as the score grew large,
> > making
> > me think there is some kind of memory management issue lurking around.
> > I am
> > completely unable to prove this.
>
> I would expect memory bugs to result in crashes rather than simple and
> consistent misalignment of elements.  But stranger things have happened.
>
> You may have another strategy here.  You mention that problems happen at
> scale, so would it make sense to break up the piece into smaller
> sections that each independently render as expected?  It is not elegant
> for sure; but if the approach unblocks you, I would say elegance should
> not matter.
>
>
> -- Aaron Hill
>
> ___
> 

Re: Dynamics offset suddenly changes

[Aaron Hill]

Sorry, Andrew.  I've been buried in work for my choir.  Allow me to try 
to address the questions/comments in a single mail to catch up.




On 2019-03-25 5:04 pm, Andrew Bernard wrote:
The pink arrow lines - how does lilypond work out this distance? It 
seems

to be that that is jumping around. Can you help me understand that?


The pink lines are hard-coded as part of my demonstration of using a 
specific value for minimum-space.  It was meant only to visually depict 
the offset, as it can be hard to count staff spaces outside the staff 
itself.


What I could have done was this:


  %% Overlay reference lines.
  \override Hairpin.stencil =
#(grob-transformer 'stencil (lambda (grob orig)
  (let* ((p (ly:grob-object grob 'axis-group-parent-Y))
 (y (ly:grob-property p 'minimum-space)))
(grob-interpret-markup grob #{
  \markup \with-dimensions-from \stencil $orig \overlay {
\with-color #(rgb-color 0.4 0.7 1.0)
\path #0.2 #'((moveto -8 0) (lineto 8 0))
\with-color #(rgb-color 1.0 0.4 0.7)
\path #0.2 #`((moveto 0 0) (lineto 0 ,y)
  (moveto -2 ,y) (lineto 2 ,y)
  (moveto -1 ,(- y 1.5)) (lineto 0 ,y)
  (lineto 1 ,(- y 1.5)))
\stencil $orig } #}


NOTE: I omitted the \once so this will draw on all Hairpins.  As such, I 
shortened the blue line.


Here this is only just for visualizing minimum-space, but it does not 
account for all of the possible factors that affect vertical 
positioning.  Again note that in my other example, I zeroed out several 
of the padding properties to make things work.




On 2019-03-25 4:42 pm, Andrew Bernard wrote:

Hi Aaron,

Thank you for looking into this. As mentioned in my original post, I am 
not
using a Dynamics context as this New Complexity score is very, very 
complex
rhythmically, and it would tale a month to go back and figure out all 
the
spacer rests to use a dynamics context. I'd rather not do that, but I 
can

see where this is going.


As I showed in my prior email, you do not technically need to do 
anything a second time.  You should be able to instanciate your music 
twice: once for the \Staff and a second time for \Dynamics.  It should 
only then be a matter of \omitting any dynamics-related grobs from the 
Staff.  Of course, this tactic may not work depending on how "dirty" 
your music variables are.  If they are pretty clean and just represent 
pitches and durations with dynamics attached, it should work as I 
showed.


For cases when the music is muddled with things that the \Dynamics 
context is not by default ignoring, it would fall to the task of using 
map-some-music and a suitable procedure for extracting only the elements 
you want.  Basically, I agree that you should not have to do extra work. 
 You have already indicated the dynamics you want and when.  The tactic 
now is to leverage the power of the computer to split out the things you 
want in \Dynamics apart from the things you want on the \Staff.


Unfortunately, I am running a bit out of time to dig into this further.  
And it could very well have already come up before, so I'd encourage a 
thorough search through the archives and the LSR.



This was all fine until the score reached a certain number of pages. I
suppose I can go chopping pages out to see what may be going on there. 
I

tried 2.19.82 and 2.19.83, so I don't think there is an issue with the
version.

I mention again that this started happening as the score grew large, 
making
me think there is some kind of memory management issue lurking around. 
I am

completely unable to prove this.


I would expect memory bugs to result in crashes rather than simple and 
consistent misalignment of elements.  But stranger things have happened.


You may have another strategy here.  You mention that problems happen at 
scale, so would it make sense to break up the piece into smaller 
sections that each independently render as expected?  It is not elegant 
for sure; but if the approach unblocks you, I would say elegance should 
not matter.



-- Aaron Hill

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

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi Aaron,

The pink arrow lines - how does lilypond work out this distance? It seems
to be that that is jumping around. Can you help me understand that?

Andrew


On Tue, 26 Mar 2019 at 08:18, Aaron Hill  wrote:

>
>
> Consider the following:
>
> 
> \version "2.19.82"
> \paper { indent = 0 line-width = 5\in ragged-right = ##f }
> \layout { \omit Staff.TimeSignature }
>
> test = {
>%% Overlay reference lines.
>\once \override Hairpin.stencil =
>  #(grob-transformer 'stencil (lambda (grob orig)
>(grob-interpret-markup grob #{
>  \markup \with-dimensions-from \stencil $orig \overlay {
>\with-color #(rgb-color 0.4 0.7 1.0)
>\path #0.2 #'((moveto -2 0) (lineto 66 0))
>\with-color #(rgb-color 1.0 0.4 0.7)
>\path #0.2 #'((moveto 0 0) (lineto 0 7) (moveto -2 7)
>  (lineto 2 7) (moveto -1 5.5) (lineto 0 7) (lineto 1 5.5))
>\stencil $orig } #})))
>| g4\p\< g'2.\!
>| g4\p g4\< g'2\!
>| g4\p g'4\< g'2\!
>| g'2.\< g4\!\f
>| g'2\< g4\! g4\f
>| g'2\< g'4\! g4\f \break
> }
> {
>\test
>\override DynamicLineSpanner.minimum-space = #7
>\override DynamicLineSpanner.padding = #0
>\override DynamicLineSpanner.staff-padding = #0
>\test
> }
> 
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hello Aaron,

Your hairpin marker code is astounding.

Does this attached image from my score indicate anything awry?

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

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi Harm,

My issue can't be related to stopping and starting staves, as that does not
occur in my score. But it has a hint of being somehow related.

Andrew


On Tue, 26 Mar 2019 at 07:20, Thomas Morley 
wrote:

>
> A minimal triggering the problem (\break\stopStaff \startStaff needed)
> and showing not aligning dynamics (\new Voice needed):
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi Aaron,

Thank you for looking into this. As mentioned in my original post, I am not
using a Dynamics context as this New Complexity score is very, very complex
rhythmically, and it would tale a month to go back and figure out all the
spacer rests to use a dynamics context. I'd rather not do that, but I can
see where this is going.

This was all fine until the score reached a certain number of pages. I
suppose I can go chopping pages out to see what may be going on there. I
tried 2.19.82 and 2.19.83, so I don't think there is an issue with the
version.

I mention again that this started happening as the score grew large, making
me think there is some kind of memory management issue lurking around. I am
completely unable to prove this.

Andrew


On Tue, 26 Mar 2019 at 08:18, Aaron Hill  wrote:

>
> At the end of the day, if you absolutely need perfect alignment, the
> \Dynamics context really is the way to go.  Consider this usage:
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi Harm,

I am critically aware of the need to provide MWE's. I spent all yesterday
trying to write one, and all works fine. It's only in the context of my
large score that it shows up. What's more, it only just started happening,
and all used to be fine.

I raised the post to see if anybody has has encountered the same issue,
more than anything.


Andrew


On Tue, 26 Mar 2019 at 07:20, Thomas Morley 
wrote:

>
> without an example to reproduce the problem it's close to impossible
> to say anything reasonable...
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi Aaron,

Thanks you. But the hairpins in question in my code all end on dynamics
such as p or f, and were working fine up until a couple of days ago. I
can't see what has changed, except the quartey score is now 110 pages. I am
very sorry I cannot stimulate this in a small MWE.

I am using 2.19.83. Now I wonder if that's the issue. I will revert to
2.19.82 to try.

Andrew


On Tue, 26 Mar 2019 at 08:18, Aaron Hill  wrote:

> On 2019-03-25 2:42 am, Andrew Bernard wrote:
> > Anybody?
> >
> > I have tried experimenting with large values of \override
> > DynamicLineSpanner.staff-padding to no avail. I am stumped. Is it a
> > bug?
>
> While it may not be ideal, to me this is not a bug.  DynamicLineSpanners
> behave differently when not started or terminated on the same note as a
> corresponding DynamicText.  Because otherwise, the two dynamic items
> have no knowledge of each other and ultimately have to fend for
> themselves amongst the rest of the "outside-staff" items.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics offset suddenly changes

[Aaron Hill]

On 2019-03-25 2:15 pm, Aaron Hill wrote:

On 2019-03-25 2:42 am, Andrew Bernard wrote:

Anybody?

I have tried experimenting with large values of \override
DynamicLineSpanner.staff-padding to no avail. I am stumped. Is it a 
bug?


While it may not be ideal, to me this is not a bug.
**DynamicLineSpanners** behave differently when not started or 
terminated

on the same note as a corresponding DynamicText.


Sorry, I meant to type Hairpins there instead of DynamicLineSpanners.


-- Aaron Hill

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

Re: Dynamics offset suddenly changes

[Aaron Hill]

On 2019-03-25 2:42 am, Andrew Bernard wrote:

Anybody?

I have tried experimenting with large values of \override
DynamicLineSpanner.staff-padding to no avail. I am stumped. Is it a 
bug?


While it may not be ideal, to me this is not a bug.  DynamicLineSpanners 
behave differently when not started or terminated on the same note as a 
corresponding DynamicText.  Because otherwise, the two dynamic items 
have no knowledge of each other and ultimately have to fend for 
themselves amongst the rest of the "outside-staff" items.


Even within a \Dynamics context it is not so much that items are aligned 
to each other but rather to a common reference point that just so 
happens to make it *look* like they know about each other.


Consider the following:


\version "2.19.82"
\paper { indent = 0 line-width = 5\in ragged-right = ##f }
\layout { \omit Staff.TimeSignature }

test = {
  %% Overlay reference lines.
  \once \override Hairpin.stencil =
#(grob-transformer 'stencil (lambda (grob orig)
  (grob-interpret-markup grob #{
\markup \with-dimensions-from \stencil $orig \overlay {
  \with-color #(rgb-color 0.4 0.7 1.0)
  \path #0.2 #'((moveto -2 0) (lineto 66 0))
  \with-color #(rgb-color 1.0 0.4 0.7)
  \path #0.2 #'((moveto 0 0) (lineto 0 7) (moveto -2 7)
(lineto 2 7) (moveto -1 5.5) (lineto 0 7) (lineto 1 5.5))
  \stencil $orig } #})))
  | g4\p\< g'2.\!
  | g4\p g4\< g'2\!
  | g4\p g'4\< g'2\!
  | g'2.\< g4\!\f
  | g'2\< g4\! g4\f
  | g'2\< g'4\! g4\f \break
}
{
  \test
  \override DynamicLineSpanner.minimum-space = #7
  \override DynamicLineSpanner.padding = #0
  \override DynamicLineSpanner.staff-padding = #0
  \test
}


The first system demonstrates the default vertical alignment.  Note that 
the only time the hairpins and dynamics line up "properly" is when they 
start and stop together.


The second system shows that by adjusting some variables you can 
essentially request all of the dynamic items to be a certain distance 
away from the staff.  Note that this is simply a request, and that other 
"outside-staff" items can shift the final positioning.


At the end of the day, if you absolutely need perfect alignment, the 
\Dynamics context really is the way to go.  Consider this usage:



\version "2.19.82"
test = {
  | g4\p\< g'2.\! | g4\p g4\< g'2\! | g4\p g'4\< g'2\!
  | g'2.\< g4\!\f | g'2\< g4\! g4\f | g'2\< g'4\! g4\f
}
<<
  \new Staff \with { \omit Hairpin \omit DynamicText } \test
  \new Dynamics \test





This is a cheap way to avoid duplicating effort on the \Dynamics 
context.


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

Re: Dynamics offset suddenly changes

[Thomas Morley]

Am Mo., 25. März 2019 um 10:42 Uhr schrieb Andrew Bernard
:
>
> Anybody?
>
> I have tried experimenting with large values of \override 
> DynamicLineSpanner.staff-padding to no avail. I am stumped. Is it a bug?
>
> Andrew
>
>
> On Sun, 24 Mar 2019 at 20:48, Andrew Bernard  wrote:
>>
>> I have a score with a lot of dynamics, a string quartet. There is more or 
>> less a continuum of dynamics and hairpins for each instrument. I am not 
>> using a dynamics context as the complexity of the music and rhythms makes it 
>> very tedious to figure out all the spacer rests that would be need. It's 
>> more pragmatic to attach the dynamics to the notes for this particular work. 
>> Generally in the score all the dynamics and hairpins line up nicely without 
>> me having to adjust them, only occasionally. But now that I have over 100 
>> pages, more and more often hairpins that go over the page break and should 
>> join to a \p or \f etc on the next page are completely out of alignment. 
>> It's as though the hairpin cannot see the ending dynamic indication.
>>
>> is there a reason for this, and is there a fix?
>>
>> Refer to the attached image for an example.
>>
>> Andrew
>>

Hi Andrew,

without an example to reproduce the problem it's close to impossible
to say anything reasonable...

_Maybe_ you stumbled across a problem recently reported:
http://lilypond.1069038.n5.nabble.com/Bug-restarting-staff-destroys-DynamicLineSpanner-staff-padding-after-line-break-td220605.html

A minimal triggering the problem (\break\stopStaff \startStaff needed)
and showing not aligning dynamics (\new Voice needed):

\new Staff {
  \override Staff.DynamicLineSpanner.staff-padding = 5
  c'1\f\>
  \break
  \stopStaff \startStaff
  e' <>\!
  \new Voice { d'\p\< e'\! }
}

Also, see my attempt of an workaround there.

HTH a bit,
  Harm

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

Re: Dynamics offset suddenly changes

[Andrew Bernard]

Anybody?

I have tried experimenting with large values of \override
DynamicLineSpanner.staff-padding to no avail. I am stumped. Is it a bug?

Andrew


On Sun, 24 Mar 2019 at 20:48, Andrew Bernard 
wrote:

> I have a score with a lot of dynamics, a string quartet. There is more or
> less a continuum of dynamics and hairpins for each instrument. I am not
> using a dynamics context as the complexity of the music and rhythms makes
> it very tedious to figure out all the spacer rests that would be need. It's
> more pragmatic to attach the dynamics to the notes for this particular
> work. Generally in the score all the dynamics and hairpins line up nicely
> without me having to adjust them, only occasionally. But now that I have
> over 100 pages, more and more often hairpins that go over the page break
> and should join to a \p or \f etc on the next page are completely out of
> alignment. It's as though the hairpin cannot see the ending dynamic
> indication.
>
> is there a reason for this, and is there a fix?
>
> Refer to the attached image for an example.
>
> Andrew
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: dynamics and pedal as separate "voices"

[Robert Blackstone]

Hi Kieren,

Many thanks for your advice.
This is a new LilyPond-terrain for me and It will certainly take me some time 
to implement it. 

Best regards,
Robert Blackstone


On 2 Nov 2018, at 14:24 , Kieren MacMillan  
wrote:

> Hi Robert,
> 
>> For my pianoscores I use a "dynamics voice" (\new Dynamics = "dynamics" 
>> \dynamics) and a "pedal voice" (\new Dynamics = "pedal" \pedal).
> 
> An excellent design choice!
> 
>> On the whole they work perfectly but compared to dynamic marks attached to 
>> notes I find their possiblities a bit limited. The same goes for the pedal 
>> marks.
> 
> Really? I’ve never run into any limitations versus "embedding" the pedal 
> markings (except of course the obvious extra typing required)…?
> 
>> As for the dynamics I would like to use it also for other expressive 
>> “instructions” like “p dolce” but I have no idea how to accomplish this in 
>> \new Dynamics = "dynamics" \dynamics.
> 
> There are many different ways to do this, and many functions (of varying 
> complexity and flexibility) to help make the job easier — you can search the 
> usual locations (official docs, lists, LSR) for examples, especially Janek’s 
> function (which Harm later improved).
> 
>> As for the pedal marks I would like to use the “mixed” style and 
>> occasionally the “bracket” -style but again I have no idea how I can make 
>> “\new Dynamics = "pedal" \pedal” do it.
> 
> Same as you would in any context: set the appropriate parameter!  =)
> 
> In case it’s helpful: I have a PianoStaff.ily include file, in which I define 
> a bunch of custom contexts including one for pedalling:
> 
>  \context {
>\name PianoPedals
>\type "Engraver_group"
>\alias Staff
>\consists "Text_engraver"
>\consists "Piano_pedal_engraver"
>\consists "Piano_pedal_align_engraver"
>\consists "Axis_group_engraver"
>pedalSustainStrings = #'("Ped." "*Ped." "*")
>pedalSustainStyle = #'mixed
>pedalSostenutoStrings = #'("Sost. Ped." "*Sost. Ped." "*")
>pedalSostenutoStyle = #'mixed
>pedalUnaCordaStrings = #'("una corda" "" "tre corde")
>pedalUnaCordaStyle = #'text
>\override SustainPedal.X-offset = #-0.25
>\override SustainPedal.extra-offset = #'(0 . -0.05)
>\override VerticalAxisGroup.staff-affinity = #UP
>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing =
>  #'((basic-distance . 2) (minimum-distance . 1.5) (padding . 1) 
> (stretchability . 0))
>\override VerticalAxisGroup.nonstaff-unrelatedstaff-spacing =
>#'((basic-distance . 8) (minimum-distance . 4) (padding . 4) 
> (stretchability . 10))
>\override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #1
>  }
> 
> Then I use
> 
>   \new PianoPedals \mypedalstuff
> 
> and everything works "automagically". You might consider defining your own 
> custom pedal context, to make your engraving life easier!
> 
> Hope that helps,
> 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: dynamics and pedal as separate "voices"

[Kieren MacMillan]

Hi Robert,

> For my pianoscores I use a "dynamics voice" (\new Dynamics = "dynamics" 
> \dynamics) and a "pedal voice" (\new Dynamics = "pedal" \pedal).

An excellent design choice!

> On the whole they work perfectly but compared to dynamic marks attached to 
> notes I find their possiblities a bit limited. The same goes for the pedal 
> marks.

Really? I’ve never run into any limitations versus "embedding" the pedal 
markings (except of course the obvious extra typing required)…?

> As for the dynamics I would like to use it also for other expressive 
> “instructions” like “p dolce” but I have no idea how to accomplish this in 
> \new Dynamics = "dynamics" \dynamics.

There are many different ways to do this, and many functions (of varying 
complexity and flexibility) to help make the job easier — you can search the 
usual locations (official docs, lists, LSR) for examples, especially Janek’s 
function (which Harm later improved).

> As for the pedal marks I would like to use the “mixed” style and occasionally 
> the “bracket” -style but again I have no idea how I can make “\new Dynamics = 
> "pedal" \pedal” do it.

Same as you would in any context: set the appropriate parameter!  =)

In case it’s helpful: I have a PianoStaff.ily include file, in which I define a 
bunch of custom contexts including one for pedalling:

  \context {
\name PianoPedals
\type "Engraver_group"
\alias Staff
\consists "Text_engraver"
\consists "Piano_pedal_engraver"
\consists "Piano_pedal_align_engraver"
\consists "Axis_group_engraver"
pedalSustainStrings = #'("Ped." "*Ped." "*")
pedalSustainStyle = #'mixed
pedalSostenutoStrings = #'("Sost. Ped." "*Sost. Ped." "*")
pedalSostenutoStyle = #'mixed
pedalUnaCordaStrings = #'("una corda" "" "tre corde")
pedalUnaCordaStyle = #'text
\override SustainPedal.X-offset = #-0.25
\override SustainPedal.extra-offset = #'(0 . -0.05)
\override VerticalAxisGroup.staff-affinity = #UP
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing =
  #'((basic-distance . 2) (minimum-distance . 1.5) (padding . 1) 
(stretchability . 0))
\override VerticalAxisGroup.nonstaff-unrelatedstaff-spacing =
#'((basic-distance . 8) (minimum-distance . 4) (padding . 4) 
(stretchability . 10))
\override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #1
  }

Then I use

   \new PianoPedals \mypedalstuff

and everything works "automagically". You might consider defining your own 
custom pedal context, to make your engraving life easier!

Hope that helps,
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: dynamics and line spanning

[David Kastrup]

Reilly Farrell  writes:

> Hi All,
>
> Is there an easy way to configure dynamics and markup text so that they
> occupy they share the same vertical alignment relative to the staff?  My
> hope is that I can align regular dynamic marks with special dynamic
> instructions (\cresc won't cut it in this case) as seamlessly as possible.
> Example below:
>
> c1\p c1 c1\markup{\italic { cresc. poco a poco } } c1
>
> Any assistance is appreciated.  Thank you!

{
  c1\p c1 c1$(make-dynamic-script #{ \markup \normal-text \italic \line { 
cresc. poco a poco } #})
  c1
}

-- 
David Kastrup

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

Re: dynamics and line spanning

[Pierre Perol-Schneider]

Hi Reilly,

How about :

\version "2.19"
<<
  \new Staff { c1 1 1 1 }
  \new Dynamics { s1\p s s-\markup { cresc. poco a poco } s }
>>

Cheers,
Pierre

2018-06-20 6:24 GMT+02:00 Reilly Farrell :

> Hi All,
>
> Is there an easy way to configure dynamics and markup text so that they
> occupy they share the same vertical alignment relative to the staff?  My
> hope is that I can align regular dynamic marks with special dynamic
> instructions (\cresc won't cut it in this case) as seamlessly as possible.
> Example below:
>
> c1\p c1 c1\markup{\italic { cresc. poco a poco } } c1
>
> Any assistance is appreciated.  Thank you!
>
> -Reilly
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics not centered

[Ben]

On 6/16/2018 3:21 PM, Torsten Hämmerle wrote:

SoundsFromSound wrote

Can someone tell me why the dynamics marking is not centered (like the
default) when using it as a 'compound' command/variable markup?

Hi Ben,

That's because your declaration is a TextScript markup, and by default, a
TextScript will be set flush left-aligned.

"Real" dynamics will be defined by make-dynamic-script, like in

ppdolce =
#(make-dynamic-script
   (markup #:line
   (#:dynamic "pp"
#:normal-text #:italic "dolce")))

or
ppdolce =
  #(make-dynamic-script
   #{ \markup { \line { \dynamic "pp"
\normal-text \italic "dolce" } }
   #})


Positioning isn't quite easy if additional texts as "dolce" or "sempre" or
"poco a poco" are there (just centering will move the pp too far away from
where it should start.
Several possibilities and examples can be found in snippet
http://lsr.di.unimi.it/LSR/Item?id=393


HTH,
Torsten





Thank you, that is exactly what I was after - now it makes sense.


On 6/16/2018 4:00 PM, Thomas Morley wrote:

2018-06-16 21:21 GMT+02:00 Torsten Hämmerle :

SoundsFromSound wrote

Can someone tell me why the dynamics marking is not centered (like the
default) when using it as a 'compound' command/variable markup?

Hi Ben,

That's because your declaration is a TextScript markup, and by default, a
TextScript will be set flush left-aligned.

"Real" dynamics will be defined by make-dynamic-script, like in

ppdolce =
#(make-dynamic-script
   (markup #:line
   (#:dynamic "pp"
#:normal-text #:italic "dolce")))

or
ppdolce =
  #(make-dynamic-script
   #{ \markup { \line { \dynamic "pp"
\normal-text \italic "dolce" } }
   #})


Positioning isn't quite easy if additional texts as "dolce" or "sempre" or
"poco a poco" are there (just centering will move the pp too far away from
where it should start.
Several possibilities and examples can be found in snippet
http://lsr.di.unimi.it/LSR/Item?id=393


HTH,
Torsten


Here a longish thread which discusses it in depth, some code of mine
trying to deal with the problems there as well.
http://lilypond.1069038.n5.nabble.com/improving-Janek-s-dynamic-function-for-combo-dynamics-td205071.html

Cheers,
   Harm



Harm,

Thank you for the thread, lots of great info in there!

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

Re: Dynamics not centered

[Thomas Morley]

2018-06-16 21:21 GMT+02:00 Torsten Hämmerle :
> SoundsFromSound wrote
>> Can someone tell me why the dynamics marking is not centered (like the
>> default) when using it as a 'compound' command/variable markup?
>
> Hi Ben,
>
> That's because your declaration is a TextScript markup, and by default, a
> TextScript will be set flush left-aligned.
>
> "Real" dynamics will be defined by make-dynamic-script, like in
>
> ppdolce =
> #(make-dynamic-script
>   (markup #:line
>   (#:dynamic "pp"
>#:normal-text #:italic "dolce")))
>
> or
> ppdolce =
>  #(make-dynamic-script
>   #{ \markup { \line { \dynamic "pp"
>\normal-text \italic "dolce" } }
>   #})
>
>
> Positioning isn't quite easy if additional texts as "dolce" or "sempre" or
> "poco a poco" are there (just centering will move the pp too far away from
> where it should start.
> Several possibilities and examples can be found in snippet
> http://lsr.di.unimi.it/LSR/Item?id=393
>
>
> HTH,
> Torsten


Here a longish thread which discusses it in depth, some code of mine
trying to deal with the problems there as well.
http://lilypond.1069038.n5.nabble.com/improving-Janek-s-dynamic-function-for-combo-dynamics-td205071.html

Cheers,
  Harm

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

Re: Dynamics not centered

[Torsten Hämmerle]

SoundsFromSound wrote
> Can someone tell me why the dynamics marking is not centered (like the 
> default) when using it as a 'compound' command/variable markup?

Hi Ben,

That's because your declaration is a TextScript markup, and by default, a
TextScript will be set flush left-aligned.

"Real" dynamics will be defined by make-dynamic-script, like in

ppdolce =
#(make-dynamic-script
  (markup #:line
  (#:dynamic "pp"
   #:normal-text #:italic "dolce")))

or
ppdolce =
 #(make-dynamic-script
  #{ \markup { \line { \dynamic "pp"
   \normal-text \italic "dolce" } }
  #})


Positioning isn't quite easy if additional texts as "dolce" or "sempre" or
"poco a poco" are there (just centering will move the pp too far away from
where it should start.
Several possibilities and examples can be found in snippet
http://lsr.di.unimi.it/LSR/Item?id=393


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: Dynamics within divisi

[Heikki Tauriainen]

Hi,

On Fri, 2017-09-15 at 09:42 -0700, SoundsFromSound wrote:
> Alistair Millar wrote
> > When I use the following divisi, I get the error message:
> > "(De)crescendo
> > with
> > unspecified starting volume in MIDI." A \f is set a couple of bars
> > before
> > the
> > divisi bar. 
> > 
> > <<
> > {r8\< c'4-.\> c8-.\!}
> > \\
> > {g4-. c,-.}
> > > > 
> > 
> > How do I overcome this? Thanks
> > 
> > Alistair
> > ___
> > lilypond-user mailing list
> > lilypond-user@
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> Hello,
> 
> Perhaps it's related to this?
> https://code.google.com/archive/p/lilypond/issues/3945

A more up-to date link for this issue [1] shows that this warning was
removed in version 2.19.44, so probably the easiest way to just get rid
of the warning without modifying the input would be to install and use
a newer version in case you don't care about the precise volume of the
divisi notes in MIDI output.  (If you do, read on.)

Even though the warning has been removed, the handling of MIDI volume
at the beginning of new Voice contexts (implicitly created by the \\
construct in the above code) remains the same even in 2.19 versions,
however: without adding explicit initial dynamics to every new Voice,
each new Voice – whose MIDI volume is by default independent of the
MIDI volume of all other voices – will start with the default MIDI
volume.  This means that “[setting] \f [...] a couple of bars before
the divisi bar” has actually no relevance in the above code because
that \f applies to a different Voice, and not any of the Voices created
for the divisi notes.  (Also, \< and \> in the upper divisi notes will
change the MIDI volume only for the upper notes, and not the lower
notes because the upper and lower notes are in two separate Voices.)

(For more details, see comment [2] in the mailing list thread linked to
in the issue – I believe the example about the behavior of MIDI volume
at Voice boundaries is still valid, as are all workarounds suggested in
the comments that follow.)

[1] https://sourceforge.net/p/testlilyissues/issues/3945/
[2] http://lists.gnu.org/archive/html/lilypond-user/2014-05/msg00429.ht
ml

-- 
Heikki Tauriainen


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

Re: Dynamics within divisi

[SoundsFromSound]

Alistair Millar wrote
> When I use the following divisi, I get the error message: "(De)crescendo
> with
> unspecified starting volume in MIDI." A \f is set a couple of bars before
> the
> divisi bar. 
> 
> <<
> {r8\< c'4-.\> c8-.\!}
> \\
> {g4-. c,-.}
>>>
> 
> How do I overcome this? Thanks
> 
> Alistair

---

Hello Alistair,

Not 100% sure, but perhaps it's related to this link:
https://code.google.com/archive/p/lilypond/issues/3945



-
composer | sound designer | asmr artist 
lilypond video tutorials --> http://bit.ly/bcl-lilypond
--
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: Dynamics within divisi

[SoundsFromSound]

Alistair Millar wrote
> When I use the following divisi, I get the error message: "(De)crescendo
> with
> unspecified starting volume in MIDI." A \f is set a couple of bars before
> the
> divisi bar. 
> 
> <<
> {r8\< c'4-.\> c8-.\!}
> \\
> {g4-. c,-.}
>>>
> 
> How do I overcome this? Thanks
> 
> Alistair
> ___
> lilypond-user mailing list

> lilypond-user@

> https://lists.gnu.org/mailman/listinfo/lilypond-user

Hello,

Perhaps it's related to this?
https://code.google.com/archive/p/lilypond/issues/3945




-
composer | sound designer | asmr artist 
lilypond video tutorials --> http://bit.ly/bcl-lilypond
--
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: Dynamics inside a chord?

[Robert Schmaus]

Not sure if that's also acceptable, but what *does* work is use of 
simultaneous voices:


\version "2.19.44"
\new Voice <<
  { a }
  { b\p }
>>



Am 14/09/16 um 14:49 schrieb David Kastrup:

Menu Jacques  writes:


Hello folks,

Just for a try:

\version "2.19.44"

\relative {  }

runs fine without any message, but also without displaying the \p mark:


Not supported.



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

Re: Dynamics inside a chord?

[Simon Albrecht]

On 14.09.2016 13:27, Menu Jacques wrote:

Hello folks,

Just for a try:

\version "2.19.44"

\relative {  }

runs fine without any message, but also without displaying the \p mark.


A valid request, I think, so: 



Best, Simon


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

Re: Dynamics inside a chord?

[Menu Jacques]

Thanks David.

JM

> Le 14 sept. 2016 à 14:49, David Kastrup  a écrit :
> 
> Menu Jacques  writes:
> 
>> Hello folks,
>> 
>> Just for a try:
>> 
>>  \version "2.19.44"
>> 
>>  \relative {  }
>> 
>> runs fine without any message, but also without displaying the \p mark:
> 
> Not supported.
> 
> -- 
> David Kastrup
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

Re: Dynamics inside a chord?

[David Kastrup]

Menu Jacques  writes:

> Hello folks,
>
> Just for a try:
>
>   \version "2.19.44"
>
>   \relative {  }
>
> runs fine without any message, but also without displaying the \p mark:

Not supported.

-- 
David Kastrup

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

Re: Dynamics & simultaneous notes yield "programming error"

[Simon Albrecht]

Hi Joel,

it looks like this hasn’t been answered yet. I can’t reproduce the bug 
on Ubuntu, but could you make a minimal example 
 and report on the bug list? 
There was recent development in that field, so it would be perfect if 
you could narrow down around which version the problem first occurred.


Best, Simon

On 28.08.2016 17:52, Joel C. Salomon wrote:

Compiling the attached file yields errors of the sort


programming error: asked to compute volume at +1.00 for dynamic span of 
duration 1.00 starting at 1
continuing, cross fingers

If I replace the construct

 << { \voiceOne
 a1 |
 } \new Voice { \voiceTwo
 a,1 |
 } >> \oneVoice |

with

 << {a1} \\ {a,1} >>

this error goes away.

Can someone please explain what I’m doing wrong here?

—Joel C. Salomon


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



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

Re: Dynamics & simultaneous notes yield "programming error"

[Joel C. Salomon]

Yesterday, I wrote:
> Compiling the attached file (Lilypond 2.19.46, Windows 10) yields errors of 
> the sort
>
>> programming error: asked to compute volume at +1.00 for dynamic span of 
>> duration 1.00 starting at 1
>> continuing, cross fingers

Okay, this is interesting. If I replace

dynamics = {
s1\p|
s1*2
\bar "|."
}

(slightly simplified from my example, but still displaying the problem) with

dynamics = {
s1\p|
s1  |
s1\f|
\bar "|."
}

then the “programming error:” message goes away.

—Joel C. Salomon

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

Re: Dynamics & simultaneous notes yield "programming error"

[Anders Eriksson]

On 2016-08-28 17:52, Joel C. Salomon wrote:

Compiling the attached file yields errors of the sort


programming error: asked to compute volume at +1.00 for dynamic span of 
duration 1.00 starting at 1
continuing, cross fingers



Don't know why but the error occurs when the midi is created!

MIDI output to `programming_error.mid'...Track...

[0]

[1

programming error: asked to compute volume at +1.00 for dynamic span 
of duration 1.00 starting at 1


continuing, cross fingers

programming error: asked to compute volume at +1.00 for dynamic span 
of duration 1.00 starting at 1


continuing, cross fingers

]


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

Re: Dynamics & simultaneous notes yield "programming error"

[Joel C. Salomon]

On Aug 28, 2016 12:07 PM, "Phil Holmes"  wrote:
> Which version of Lilypond, which operating system?

2.19.46 on Windows 10.

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

Re: Dynamics & simultaneous notes yield "programming error"

[Phil Holmes]

Which version of Lilypond, which operating system?

--
Phil Holmes


- Original Message - 
From: "Joel C. Salomon" 

To: "LilyPond Users" 
Sent: Sunday, August 28, 2016 4:52 PM
Subject: Dynamics & simultaneous notes yield "programming error"


Compiling the attached file yields errors of the sort

programming error: asked to compute volume at +1.00 for dynamic span 
of duration 1.00 starting at 1

continuing, cross fingers


If I replace the construct

   << { \voiceOne
   a1 |
   } \new Voice { \voiceTwo
   a,1 |
   } >> \oneVoice |

with

   << {a1} \\ {a,1} >>

this error goes away.

Can someone please explain what I’m doing wrong here?

—Joel C. Salomon







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




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

Re: Dynamics to the left of the note

[Abraham Lee]

On Thursday, August 25, 2016, Evan O'Dorney  wrote:

> Glad I could brighten your day. For the record, it's simply
>
> \once \override DynamicText.X-offset = -3
>
> for dynamics attached to a note.
>

Ah, yes. No need for the initial Dynamics context. Good catch.

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

Re: Dynamics to the left of the note

[Evan O'Dorney]

Glad I could brighten your day. For the record, it's simply

\once \override DynamicText.X-offset = -3

for dynamics attached to a note.

Best,
Evan

On Thu, Aug 25, 2016 at 4:38 PM, Abraham Lee 
wrote:

>
>
> On Thursday, August 25, 2016, Evan O'Dorney  wrote:
>
>> Hi all,
>>
>> Could someone please remind me how to print a dynamic mark to the left of
>> a (ledger-line) note, instead of above or below it? I know it's in the
>> manual, but Google is not being merciful to me today.
>>
>> MWE:
>>
>> d\f
>>
>
> Fantastic MWE (except it should be in braces ;)
>
> Try this:
>
> \once \override Dynamics.DynamicText.X-offset = -3
>
> And tailor that number to your liking.
>
> HTH,
> Abraham
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics to the left of the note

[Abraham Lee]

On Thursday, August 25, 2016, Evan O'Dorney  wrote:

> Hi all,
>
> Could someone please remind me how to print a dynamic mark to the left of
> a (ledger-line) note, instead of above or below it? I know it's in the
> manual, but Google is not being merciful to me today.
>
> MWE:
>
> d\f
>

Fantastic MWE (except it should be in braces ;)

Try this:

\once \override Dynamics.DynamicText.X-offset = -3

And tailor that number to your liking.

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

Re: Dynamics placement

[Graham King]

On Wed, 2016-03-23 at 11:47 +0100, Xavier Scheuer wrote:

> I use Graham (Percival)'s "make-dynamic-extra", which has two main
> advantages :
> 1. The dynamic only, and not the whole "dynamic + text", is centered
> on the note (i.e. like a "normal" dynamic).
> 2. The dynamic is affecting the MIDI.
> 
> 
> http://lists.gnu.org/archive/html/lilypond-user/2011-06/msg00335.html
> 
> 
> IIRC it did not have any drawbacks, but I haven't tried it recently
> (maybe new versions of LilyPond brought some internal changes
> unsuitable to "make-dynamic-extra").

Thanks Xavier,
the code seems to work with 2.19.35, but it has no effect on the
original problem.  Nevertheless it is good to know of its existence.  
There are so many approaches to creating dynamics with text, and so much
skill and inventiveness has been applied to them over the years, that it
seems a pity that none has been internalised by lilypond.  

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

Re: Dynamics placement

[Thomas Morley]

2016-03-23 13:21 GMT+01:00 Graham King :
> (bug-lilypond: a regression with note-spacing in proximity to dynamic
> text.)
>
> On Wed, 2016-03-23 at 11:38 +0100, Thomas Morley wrote:
>
>
>> a minimal example would have been:
>>
>> \version "2.19.38"
>>
>> music = { g'8(\p f'!) s2. }
>> \new StaffGroup \new Staff \music
>
> Wow.  To get to that, I think I would have needed to know the cause of
> the problem already.

Nope.
I simply commented code-fragments and tried out several things.
But yes, creating minimal examples _is_ difficult sometimes and takes
some time and effort.
But if you finally managed to spot a bug, you didn't waste the time of
a developer, who already may have started to research the bug-cause or
even fixing it.

Btw, better to write a new mail to the bug-list, instead of just cc-ing them.
It makes life a little bit easier for our bug-squad-members.

Cheers,
  Harm

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

Re: Dynamics placement

[Graham King]

(bug-lilypond: a regression with note-spacing in proximity to dynamic
text.)

On Wed, 2016-03-23 at 11:38 +0100, Thomas Morley wrote:


> a minimal example would have been:
> 
> \version "2.19.38"
> 
> music = { g'8(\p f'!) s2. }
> \new StaffGroup \new Staff \music

Wow.  To get to that, I think I would have needed to know the cause of
the problem already.

> 
> 
> The code from the lsr-snippet has nothing to do with it.
> 
> Below a little longer commented example.
> 
> 
> Clearly a bug, please report.

Copied to bug-lilypond.

> 
> %% Following note is moved away by DynamicText
> %%
> %% Bad behaviour goes away if the second note has no Accidental 
> %% or \voiceTwo is used
> %% or if \new StaffGroup is deleted or replaced by \new ChoirStaff 
> %% \new GrandStaff does not work as well, though
> %%
> %% Worked fine with "2.18.2"
> 
> \version "2.19.38"
> 
> music = {
> %% bad:
> g'8(\p f'!) s2.
> %% good:
> %\voiceTwo
> %g'8(\p f'!) s2.
> }
> 
> \new StaffGroup
>   \new Staff \music
>   
> %% Not required to trigger bad behaviour
> %% Better visible, though
> \layout { \override DynamicText.self-alignment-X = #LEFT }
> 
> 
> Cheers,
> 
>   Harm
> 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics placement

[Graham King]

On Tue, 2016-03-22 at 22:18 -0400, Kieren MacMillan wrote:

> Hi Graham,
> 
> > The unwelcome spacing between the 4th and 5th notes goes away if one:
> 
> … uses
> 
> mpdolce = -\tweak X-extent #empty-interval #(make-dynamic-atr-script "mp" 
> "dolce”)
> 

Thanks Kieran,
that's very helpful.  I've added

 (ly:music-set-property! dynamic 'tweaks (acons 'X-extent 0
(ly:music-property dynamic 'tweaks)))

in the appropriate place in the snippet.  I noted some fiddling with
X-extent in one of the snippets, but didn't understand it, and got a bit
confused by thinking that it was already set to zero (well, negative
infinity) according to the discussion of grob sizing in the Learning
Manual (section 4.4.3).

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

Re: Dynamics placement

[Xavier Scheuer]

On 22 March 2016 at 23:41, Graham King  wrote:
>
> I've adopted Simon Albrecht's excellent suggestion in an earlier
> thread [1], and am now using code based on snippet 739 [2] to typeset
> some long dynamic markings.  This has solved a host of layout problems;
> however, it has introduced this nasty spacing issue:
>
>
> r2 r8 bes8(\mfdolce a bes) | g'4-.( f-.)
>
> where \mfdolce is the result of snippet 739's make-dynamic-script.
>
> Since the dynamic applies to the phrase rather than just the first
> note, is there a way to prevent it pushing the second note to the right?
> I would like it to overlap the second (and, if necessary, subsequent)
> note(s) of this phrase.  I've looked at section 4.4.3 of the Learning
> Manual [3] and things don't appear promising.

Hi,

I use Graham (Percival)'s "make-dynamic-extra", which has two main
advantages :
1. The dynamic only, and not the whole "dynamic + text", is centered
on the note (i.e. like a "normal" dynamic).
2. The dynamic is affecting the MIDI.

http://lists.gnu.org/archive/html/lilypond-user/2011-06/msg00335.html

IIRC it did not have any drawbacks, but I haven't tried it recently
(maybe new versions of LilyPond brought some internal changes
unsuitable to "make-dynamic-extra").

Cheers,
Xavier

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

Re: Dynamics placement

[Thomas Morley]

2016-03-23 2:56 GMT+01:00 Graham King :

> Here is a compilable example.  It is a bit long, but I think it is pretty
> close to minimal.
>
> In its defence: the first 32 lines are, effectively, snippet 739 modified
> to produce "dynamic text" instead of "text dynamic" (in this case, "mp
> dolce" instead of, say, "meno f").
> 
>
> Hi Graham,

a minimal example would have been:

\version "2.19.38"

music = { g'8(\p f'!) s2. }
\new StaffGroup \new Staff \music

The code from the lsr-snippet has nothing to do with it.
Below a little longer commented example.

Clearly a bug, please report.

%% Following note is moved away by DynamicText
%%
%% Bad behaviour goes away if the second note has no Accidental
%% or \voiceTwo is used
%% or if \new StaffGroup is deleted or replaced by \new ChoirStaff
%% \new GrandStaff does not work as well, though
%%
%% Worked fine with "2.18.2"

\version "2.19.38"

music = {
%% bad:
g'8(\p f'!) s2.
%% good:
%\voiceTwo
%g'8(\p f'!) s2.
}

\new StaffGroup
  \new Staff \music

%% Not required to trigger bad behaviour
%% Better visible, though
\layout { \override DynamicText.self-alignment-X = #LEFT }

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

Re: Dynamics placement

[Kieren MacMillan]

Hi Graham,

> The unwelcome spacing between the 4th and 5th notes goes away if one:

… uses

mpdolce = -\tweak X-extent #empty-interval #(make-dynamic-atr-script "mp" 
"dolce”)

=)

Hope this helps!
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: Dynamics placement

[Graham King]

Here is a compilable example.  It is a bit long, but I think it is
pretty close to minimal.

In its defence: the first 32 lines are, effectively, snippet 739
modified to produce "dynamic text" instead of "text dynamic" (in this
case, "mp dolce" instead of, say, "meno f").

The remaining few lines are one part from a very heavily redacted
movement of a quintet.



The unwelcome spacing between the 4th and 5th notes goes away if one:

  * transposes the second bar up an octave; or
  * comments out the key signature; or
  * comments out \new StaffGroup; or
  * uncomments the line containing DynamicLineSpanner.staff-padding

I think I can live with the final option, assuming I can localise the
staff-padding change when I apply it to the big score.  Problem solved;
sorry for the noise.

Here's the code, attached, in case either I'm missing something obvious,
or the modified snippet 739 is useful to someone.

-- Graham
\version "2.19.35"

%% The relevant parts of my modified version of snippet 739 %%
% calculate x-alignment based on attribute text + dynamic text
% this has to be a markup-command to get stencil-extent based on 
(interpret-markup layout props ...)
#(define-markup-command (center-dynatr layout props atr-text dyn)(markup? 
string?)
   "x-align on center of dynamic"
   (let* (
   (text (string-append " " atr-text ))
   (atr-stencil (interpret-markup layout props (markup #:normal-text 
#:italic text)))
   (dyn-stencil (interpret-markup layout props (markup #:dynamic dyn)))
   (atr-x-ext (ly:stencil-extent atr-stencil X))
   (dyn-x-ext (ly:stencil-extent dyn-stencil X))
   (atr-x (- (cdr atr-x-ext)(car atr-x-ext)))
   (dyn-x (- (cdr dyn-x-ext)(car dyn-x-ext)))
   (x-align
(* (-
(/ (/ dyn-x 2) (+ atr-x dyn-x) )
0.5) 2)
)
   )
 (interpret-markup layout props (markup #:halign x-align #:concat 
(#:dynamic dyn #:normal-text #:italic text)))
 ))
% define a 'new' attributed dynamic script
#(define (make-dynamic-atr-script dyn atr)
   (let ((dynamic (make-dynamic-script (markup #:center-dynatr atr dyn
 (ly:music-set-property! dynamic 'tweaks (acons 'X-offset 0 
(ly:music-property dynamic 'tweaks)))
 dynamic))

% define some attributed dynamics
mpdolce = #(make-dynamic-atr-script "mp" "dolce")
%% Modified version of snippet 739 (ends) %%

music = \new Voice {
  \relative {
\clef bass
\key es \major
r2 r8 f8(\mpdolce e f) |
%\override DynamicLineSpanner.staff-padding = #2.5
r2 r8 bes,8(\mpdolce a bes) |
  }
}

\score {
  \new StaffGroup
  \new Staff {
\music
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics placement

[Graham King]

Ah yes, a minimal compilable example.  This is going to be tough,
especially as I've just noticed that some
_functionally_indistinguishable_code_ a few bars earlier yields this:


which is precisely the behaviour I'm after.

Nevertheless, I'll try to produce a minimal compilable example.  It
might take a while...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Dynamics placement

[Thomas Morley]

Hi Graham,

you did a nice and good job listing all the links:

2016-03-22 23:41 GMT+01:00 Graham King :

> [...]
> Notes:
> [1] https://lists.gnu.org/archive/html/lilypond-user/2016-03/msg00556.html
> [2] http://lsr.di.unimi.it/LSR/Item?id=739
> [3]
> http://www.lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects
>

but the one over all important thing is missing.
A compilable, tiny example. ;)
Please understand: conditio sine qua non

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