lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 4936: look up "mf" for default initial volume (issue 308890043


From: ht . lilypond . development
Subject: Re: Issue 4936: look up "mf" for default initial volume (issue 308890043 by address@hidden)
Date: Sat, 06 Aug 2016 03:43:16 -0700

On 2016/08/04 23:30:17, Dan Eble wrote:
On 2016/08/04 21:23:12, ht wrote:
> (define-public dynamic-default-volume 0.71)
>
> I wonder whether this (possibly obsolete, "git grep" doesn't show it
being
> currently referenced from anywhere, certainly not from
Dynamic_performer)
> definition could (or should) be removed as part of this change?

I just said I would be happy to delete this, but now I'm wondering,
even if it
doesn't break Lilypond per se, is removing this going to break user
code?  If
it's "public" that means people might be using it, right?

This may of course be true; maybe this is just another case of it being
impossible to remove any of the old and undocumented functionality (even
though it's useless from the LilyPond point of view) just in case
someone may have started to depend on it...

In this particular case, the definition has been in actual use (in
lily/dynamic-performer.cc) only in the year 2000 between LilyPond
1.3.31, for which the definition was added in commit
4990a43304a74ffe431951798e9d674101f09278, and LilyPond 1.3.93, where the
only reference to the Scheme definition was removed (commit
f988425624a6f6d1a48aea0ac0c1c84ff0857e56).  "git log
-Sdynamic-default-volume" doesn't show any new references having been
introduced since.  Considering that the variable doesn't have any
behavioral meaning in LilyPond, the only place where I could imagine any
direct use for the variable is in the definition of a custom absolute
volume function... so I'd still be in favor of removing the definition
to remove an unnecessary point of confusion for understanding the source
code.

To better cater for Carl's suggestions, there could be the possibility
(after removing this unused definition) of extending the default
absolute volume function with a new "default" entry and use this special
key instead of "mf" to look up the default volume in Dynamic_performer
(making it possible to customize the default initial volume
independently of the other predefined dynamics via a custom absolute
volume function).  However, having any kind of Scheme definition for the
default initial volume feels like overkill to me as well - as Dan wrote,
users who wish to use a custom initial dynamic level in a Voice can
always do so by specifying the dynamic explicitly (which is usually
necessary anyway at the beginning of each Voice to protect against any
changes in the MIDI dynamic level which are not visible in the typeset
output).


https://codereview.appspot.com/308890043/



reply via email to

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