|
From: | Auto mailings of changes to Lily Issues |
Subject: | [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4048 Is Dynamic_performer’s understanding of (de)crescendo too limited? |
Date: | Sat, 25 Jun 2016 01:17:48 +0000 |
I've gone a bit further and handled sequences of (de)crescendi, to an extent. I plan to test my work before posting a review, but here is the algorithm in case anyone would like to raise objections in the meantime.
The performer works on passages containing of the longest string of consecutive crescendi followed by a consecutive decrescendi (or vice versa) which are not interrupted by an absolute dynamic. For example, this passage has two crescendi and a decrescendo, as well as some spans of unchanging volume.
c\< c\! c c c\< c\! c c c\> c c c c c c c\! ...
The performer works it out so that at the end of the decrescendo, the volume has returned to the original volume before the first crescendo in the passasge began. The maximum (or minimum) volume is chosen as it was before. The change in volume of a particular (de)crescendo is proportional to its duration.
When an absolute dynamic appears, the performer terminates the group and uses the specified dynamic instead of the starting dynamic.
[issues:#4048] Is Dynamic_performer’s understanding of (de)crescendo too limited?
Status: Accepted
Created: Sat Aug 02, 2014 10:45 AM UTC by Anonymous
Last Updated: Sun Jun 05, 2016 01:27 PM UTC
Owner: Dan Eble
Originally created by: *anonymous
Originally created by: address@hidden
On 02/08/14 18:36, Knute Snortum wrote:> Something that is seen a lot in 19th and 20th century music is a crescendo
> or decrescendo without going to a specific dynamic. The performer is given
> the freedom to decide how much to change the dynamics. This causes an
> error message: "programming error: Impossible or ambiguous (de)crescendo in
> MIDI."
>
> %%% BEGIN
> \version "2.19.10"
>
> \score {
> \relative c' {
> c1 \p | c4 \< d e f | g \> f e d | c1 \p
> }
> \layout {}
> \midi {}
> }
> %%% END
>
> This error message should be a warning and give some line number to the
> offending code.
On 02/08/14 15:28, David Kastrup wrote:> Knute Snortum <address@hidden> writes:
...
>
> That's not an actual programming error in pretty much all cases but
> rather an input problem probably deserving a warning. That alone should
> warrant fixing.
>
Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape
_______________________________________________ Testlilyissues-auto mailing list address@hidden https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
[Prev in Thread] | Current Thread | [Next in Thread] |