Originally created by: *anonymous
Originally created by: pkx1...@gmail.com
Here is the main thread:
--snip--
)-----Original Message-----
)From: lilypond-devel-bounces+james.lowe=datacore.com@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore.com@gnu.org] On )Behalf Of Jan Warchol
)Sent: 29 July 2011 08:11
)To: David Kastrup
)Cc: lilypond-devel@gnu.org
)Subject: Re: music function semantics
)
)David,
)
)2011/7/27 David Kastrup <dak@gnu.org>:
)> Neil Puttock <n.puttock@gmail.com> writes:
)>
)>> On 26 July 2011 22:41, David Kastrup <dak@gnu.org> wrote:
)>>
)>>> So the question basically is: which of those mechanisms is actually )>>> being in use? Are there examples for existing music functions )>>> interpreting a postevent or a chord constituent?
)>>
)>> \tweak would be the most common usage for both of these cases:
)>>
)>> c1-\tweak #'color #red -\fermata
)>>
)>> and
)>>
)>> < \tweak #'color #red c>1
)>
)> So much for my "nobody needs that" theory. The problem I have is that )> accepting \transpose in all the same places as \tweak does not seem )> like a good idea.
)>
)> On the other hand, whether an error gets thrown by the parser or by )> the expression builder might not make that much of a difference to the )> end user than it feels like making to me.
if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. ...ah, so it is possible to modify ties in a chord separately! Do you realize that i didn't know about it?
--snip--
From Jan W
> Snippet for LSR?
I tried to write it, and do you know what? It doesn't work! Very stupid.
% if you apply this tweak to first note (c'), it works (tie gets weird). However, when applied to second note, it doesn't.
{ < c' ~ g'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
0.6) (14.5 . -1)) ~ > q }
--snip--
From David K
--snip--
If you take a look at the output of
\displayMusic { < c'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
0.6) (14.5 . -1)) ~ g'-\tweak #'control-points #'((1 . -1) (3 . 0.6) (12.5 .
0.6) (14.5 . -1)) ~ > q }
you'll see that it is not the fault of the parser. The music expression still carries the respective information.
--snip--
From Reinhold
--snip--
Hehe. What David wanted to say: The parser correctly interprets the syntax and properly sets the control-points for the TieEvent. So, his part of current interest (the parser) works just fine.
However, there might be a bug later on when the graphical tie object is actually created from the music expression. There, the control-points seem to be handled differently for the two notes, even though both ties have the same value assigned...
> So is this a bug or something else? (I.e do we need a tracker item or
> not?) and can we tie individual notes within in a chord or not?
Yes, we can tie individual notes within a chord.
<c~ e g~>4 <c e g c>
It's just the tweak that seems to be broken in your case... I would say this is a bug, although of low priority.
Originally posted by: reinhold...@gmail.com
This is really a bug with control-points, because changing the color of the two ties separately with a tweak works fine:
{ < c'-\tweak #'color #red ~ g'-\tweak #'color #blue ~ > q }
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Summary: \tweak does not work for changing control-points of any but the first tie in chorded notes
Originally posted by: k-ohara5...@oco.net
Where is the bug?
{ < c'~ g'~ > q
< c'^~ g'_~ > q }
Originally posted by: dak@gnu.org
Could you explain what you are trying to tell us? Tie directions are not the same as control points.
Originally posted by: k-ohara5...@oco.net
> Could you explain what you are trying to tell us?
That the control points looked good enough for those chords, that it was unclear what improvement the bug-request was asking for.
Now I re-read the title and I get the point. Lilypond ignores the tweak to control-points when she sets the second tie in the chord.
{ <c' ~
g' -\tweak #'control-points #'((0 . 2) (0 . 4) (5 . 4) (5 . 2)) ~ >
q }
Originally posted by: PhilEHol...@googlemail.com
(No comment was entered for this change.)
Status: Accepted
Originally posted by: k-ohara5...@oco.net
Workaround: set the directions explicitly so we don't need TieColumn.
The TieColumn code calls Tie::get_control_points(), which fails to check if we have made an override
{ < c'-\tweak color #red _~
e'-\shape #'((0 . 0)(-1 . 0)(1 . 0)(0 . 0)) ^~
g'-\tweak color #blue
-\tweak control-points #'((2 . 0)(3 . 2)(3 . 2)(4 . 0)) ^~
c''-\shape #'((0 . 0)(4 . 1)(-4 . 1)(0 . 0)) ^~
g'' ^~
>
% if we use \once, we have to put it at the time-step where the ties *complete#
\once\override TieColumn.positioning-done = #'()
q }
Originally posted by: simon.al...@mail.de
(No comment was entered for this change.)
Labels: -Priority-Low