On 2016/06/05 18:18:23, ht wrote:
This looks great!
Even though this question has little relevance to these code changes,
I can't
resist asking whether you might have ideas about the best way to fix
the
"reverse" problem of ties attached to *individual notes of a chord*
ending up
ignored when processing articulations using the articulate.ly script:
----
\version "2.19.43"
\include "articulate.ly"
\score {
\relative c' {
<c e g c'>2~ <c e g c'> % OK
\articulate { <c e g c'>~ <c e g c'> } % OK
<c_~ e_~ g^~ c'^~>2 <c e g c'> % OK
\articulate { <c_~ e_~ g^~ c'^~>2 <c e g c'> } % ties are ignored!
}
\midi { }
}
----
The fix would in any case have to be made in the Scheme-level music
expression
transformation in the articulate function itself, right?
Well, this change here is basically minimally-invasive and only
concerned with LilyPond's default Midi generation. My involvement with
the articulate script has been minimal, mostly trying to keep it working
when music representation changed.
If articulate.ly is supposed to get along with LilyPond's Midi
generation in the long haul, it will probably want to remove all
articulations that it interprets in order to avoid having them
interpreted doubly. I have no idea whether it actually does that.
At any rate, this is an entirely different issue.
https://codereview.appspot.com/298330043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
