Re: Doc: Add a section about handling MIDI dynamics with multiple voices (issue 302930043 by ht.lilypond.developm...@gmail.com)

2016-07-12 Thread 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/

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


Re: additional entry in lilypond.org/productions.html?

2016-07-12 Thread Marc Hohl

Am 10.07.2016 um 19:11 schrieb Federico Bruni:

Il giorno ven 8 lug 2016 alle 12:36, Marc Hohl  ha
scritto:

I have written some musicals for children and adolescents in the past
and have two more musicals in the pipeline, to be released at the end
of 2016.

The sheets are done with LilyPond and LaTeX and available for free,
but the musicals are only available in German language.

You can see my work at

http://www.singspielschmiede.de

All musicals were shown on stage at the local music school where I work.

I don't know whether this stuff is good/suitable enough to get mentioned
on the Productions site under lilypond.org. What do you think?


I think that it should be definitely added.


Thank you!


Is the LilyPond source available and hosted somewhere?


Of course one can get the LP source from me, but it is not hosted anywhere.

The same holds for the sheets. There are excepts free for download, and 
if anyone is interested, he or she can contact me to get a link to the 
full stuff. I decided to use this "strategy" to get in touch with the 
potential users and to see how much people are interested in my projects.


The Productions page has now a long column of concerts on the left and a
short column of published sheet music on the right. I think that
"published" in this case means just publicly available? I mean, Mutopia
is not a publishing company.


Yes, probably ...


So I would add links to Lilypond source
projects, like:
https://github.com/nsceaux/nenuvar

and others...


+1

Marc



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


Re: additional entry in lilypond.org/productions.html?

2016-07-12 Thread Urs Liska


Am 12.07.2016 um 10:00 schrieb Marc Hohl:
>> The Productions page has now a long column of concerts on the left and a
>> short column of published sheet music on the right. I think that
>> "published" in this case means just publicly available? I mean, Mutopia
>> is not a publishing company.
>
> Yes, probably ...
>

"Published" also means "freely available", possibly together with the
sources. Commercial and/or closed source editions are not eligible to be
listed there.
[Note that this does *not* express any opinion on my behalf, it's just
the official policy]

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


Re: Doc: Add a section about handling MIDI dynamics with multiple voices (issue 302930043 by ht.lilypond.developm...@gmail.com)

2016-07-12 Thread Dan Eble
> 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).

As I mentioned, I already have a private branch that removes the mess from 
Staff_performer and lets Dynamic_performer link notes to their dynamic.  I 
haven’t tested it with your example, but I expect it to work more sensibly.  
Dynamics shouldn’t affect notes outside of the dynamic performer’s context.

> 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).

If this plan is accepted, you could conscientiously document “mf” as the 
default now.

I volunteer to make the change.  If someone would create a ticket and assign it 
to me, it would help me remember.  
— 
Dan


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


Re: Issue 4048: Improve crescendo performance with unspecified dynamics (issue 302910043 by nine.fierce.ball...@gmail.com)

2016-07-12 Thread ht . lilypond . development

In short: LGTM.  The rest of this comment is just continuing discussion
on some of the points in your previous response.

On 2016/07/12 05:01:16, Dan Eble wrote:

> What are the main user-level justifications for increasing the
> complexity of the Dynamic_performer



It also improves an example I saw elsewhere recently (I don't remember
where, but I think it was yours), something like
mf < ... < ... < ... < ... f.  The volume no longer saturates early.


Sorry about this, that example was not really meant as something that I
suggested as a problem that I'd wish to have fixed (the example was only
there to show how a previous patch of yours to "add \!'s" to all dynamic
span boundaries already improved the behavior from what it used to be) -
and the new behavior is even better since it avoids saturating the
volume altogether.


The regression tests show no differences.


I wasn't thinking about regression tests here, but rather about the
existing input files that a user might have that could start behaving
differently from what they used to (for example, that the volume level
at the end of a sequence of crescendos followed by a sequence of
descrendos, all with unspecified volumes, will now always return to the
starting level regardless of the number of crescendo and descrendo
spans).  I'm not arguing for or against any particular heuristic of
handling unspecified (de)crescendos, only that any changes in behavior
might be seen differently by different users, and whatever heuristics
there are should preferably be documented in a detailed enough level so
that the intended behavior becomes clear.

I'm of course speaking strictly from the mindset of a (likely a very
small group of) users who have (due to the lack of reference
documentation) gone through the trouble of trying to learn the rules
about how LilyPond handles MIDI dynamics by studying the source code.
While such users might be annoyed about the changes in the rules if
there's nothing mentioned about the changes anywhere, they have only
themselves to blame for relying on undocumented behavior in the
first place...  So I believe you can safely ignore my concerns about
missing user-level documentation about the changes - I don't think
there will be any users that are going to complain about the changes.


Well, the level of detail in the documentation should depend on the

use

case for MIDI output.


True - however, I'm not certain whether there's any clear consensus
among the user/developer base about what the use case for LilyPond's
MIDI output actually is, besides the obvious thing that in practice the
MIDI backend is considered to be of secondary importance to the majority
of people (at least to the core developers - since v2.14, which
introduced the "velocity as MIDI volume" interpretation of volume, I
think that the fixes and enhancements to the MIDI code have mostly come
from outside developers).


I've been told very clearly that "It can serve as a proofhearing
aid or a practice aid.  It is not intended to serve as a substitute
for a player when recording.  For that, LilyPond produces sheet music
fit for running through a human"


(http://lists.gnu.org/archive/html/lilypond-devel/2013-11/msg00194.html).

I think this is just the personal opinion of one of the core developers.
I can only symphathize with your sentiments in that discussion.

In my opinion, if the above really were the only accepted use case for
MIDI output, then I'm baffled about why the developers of the MIDI
backend ever bothered with handling MIDI dynamics in the first place,
and why, for example, the articulate.ly script (even though it was made
by an outside developer) got accepted into the official releases.
Funnily enough, had LilyPond not had any support for MIDI dynamics when
I started using it, I'd probably have never got involved with LilyPond
development at all myself, to try to work around or fix bugs where the
MIDI output backend "tried too much (performance-wise)" and failed.


I don't think that these minor changes to MIDI output in cases where
the user didn't care enough to specify a dynamic are much to brag
about.


I think that removing the internal programming errors in MIDI dynamic
handling is a good thing since these errors could have been a source of
user confusion.  Maybe this would be still worth mentioning?


https://codereview.appspot.com/302910043/diff/40001/lily/dynamic-performer.cc#newcode101

lily/dynamic-performer.cc:101: Real max_target_vol)
Assuming that context properties do not change in the course of the
performance does not seem very lilypondish.  It is true that I have
not tried to handle the possibility rigorously, but I thought it
better to write this interface this way.  It's small potatoes compared
to the rest.


OK, this was just a thought (possibly raised since the equalizer
settings remaining the same was mentioned in the code comments, so I
began to wonder how strongly this is actually assumed throughout the
implementation - in the c