Re: Doc: Add a section about handling MIDI dynamics with multiple voices (issue 302930043 by address@hidden)

[ht . lilypond . development]

On 2016/07/11 16:39:01, Carl wrote:
> I think the current behavior of changing dynamics
> in identically-named but distinct voices is flawed, so I think it
should be a
> known issue, not in the main documentation.

I agree that bugs should not be documented as the rules about the
behavior.  However, can it be definitely said in this case whether this
is actually a bug?  Without any specification available to compare the
implementation with, the answer to this question could differ between
people, each of whom has their own expectations about how they'd like
things to work.

For example, I'd say that the initialization of a new Dynamic_performer
at the start of every new Voice, which implicitly "resets" the MIDI
volume level to the default level, could equally well be considered a
bug (from the point of view of a *user* who'd prefer worrying as little
as possible about how contexts internally work) simply because this
makes it so much more difficult to write single-staff polyphony which
would produce MIDI output "matching" the typeset output, even though the
behavior makes perfect sense from an implementation point of view.  (It
is probably apparent at this point that this is the viewpoint that I had
in mind when I decided to write the patch to the documentation.)  It
could even be argued that sharing dynamics between identically named
Voices provides a workaround for this user problem, since by using
identically named Voices the shared dynamics do not need to be
duplicated in each separate Voice in the LilyPond input.

However, you could well be right that this sharing of dynamics between
identically named voices currently works only by accident (since the
initialization of a new Voice will still reset the dynamic level), just
like moving Dynamic_performer to the Staff context to make Voices within
the Staff share their dynamics works only for Voices without an explicit
name.

I suspect all of this behavior is due to the Staff_performer logic,
which tries to distribute notes and dynamics into separate classes by
the names of their associated Voices - maybe this should be done using
some other criterion (such as an internal Voice ID, unique to each Voice
instance).

> I think that it's useful to know what the default value is.  But I
also think we
> should have a comment that indicates it is defined in scm/midi.scm  It
would
> probably also be useful to give the name of the variable that holds
the default
> value, because the user can specify any desired default value by
changing the
> variable.

As Dan already commented, the default value is hard-coded in the C++
code - it doesn't come from any Scheme-level definition.  I fully agree
that instead of using a hard-coded default value which does not match
any of those defined in scm/midi.scm, the Dynamic_performer
implementation should simply be changed to query for the default value
from the default absolute volume map using one of the keys defined in
scm/midi.scm (and I agree that "mf" is probably a reasonable choice).

> I think that the behavior indicated in your example should be
documented as a
> Known Issue, which means we recognize it as a bug.  And we should have
an issue
> as well (MIDI volume levels leak between identically named voices).

So just to confirm, in your opinion the rule about how dynamics are (or
are not) shared between voices are better described just as a known
issue?  I guess it will then make sense to also simplify the example as
well to no longer demonstrate this corner case.


https://codereview.appspot.com/302930043/