Re: Unwanted warnings/errors on pedals for multiple voices

[Paolo Prete]

On Mon, Apr 6, 2020 at 8:02 PM Carl Sorensen <address@hidden> wrote:

 

 

From: Paolo Prete <address@hidden>
Date: Monday, April 6, 2020 at 11:25 AM
To: Carl Sorensen <address@hidden>
Cc: Thomas Morley <address@hidden>, Kieren MacMillan <address@hidden>, Lilypond-User Mailing List <address@hidden>
Subject: Re: Unwanted warnings/errors on pedals for multiple voices

 

 

 

On Mon, Apr 6, 2020 at 6:17 PM Carl Sorensen <address@hidden> wrote:

 

 

It’s actually less effort to assign the performer by default to the Staff than to add a note in the documentation, so I think we should just fix the default assignment of the Piano_pedal_performer.  Both require a future release, but documenting a bug that has been fixed is a little strange, IMO.

 

We should get an issue on the bug list with a title like “Pedal_engraver_performer should be in Staff, not Voice”.  That will give people a place to look if they are struggling with the problem.

 

I would like to explain what happened to me and why I encourage to add a note in the documentation. I googled a lot with the following (or similar) key: "lilypond sustainpedal voice issue". This link appeared:

http://lilypond.1069038.n5.nabble.com/Sustain-pedal-problems-with-voices-staffs-td157131.html

... and few or nothing else. The thread, as you already noted some months ago, remained idle. After that, some months ago you gave a solution of the problem for the "\change staff" case; as you can see, it works for that case but it can't be applied for the just discussed case. Not only: placement of dynamics and pedals are encouraged (after a google search as well) to be separated with a \new Dynamics _expression_, so to solve all the previous issues. IMHO this solution (which is documented) is bad: it introduces time-consuming strong redundancy which can be avoided as well with Timothy's rule.

All this considered, IMHO (and considered that I really got crazy with this warnings for weeks):

1) The "Dynamics line" solution should be discouraged in the documentation. I can be wrong but I really don't understand in which cases it could be useful. And redundancy is always a disadvantage.
2) A "late" reply to the mentioned bug thread should be added because it will automatically be a first Google match (note that my thread of months ago, about the same problem, doesn't appear as a Google result). I don't know if this is yet possible, though.
3) A "known issues" section is already included in other pages of the documentation, so I think it could be applied to this case as well.

HTH
Best,
P