Menu

#1789 \tweak does not work for changing control-points of any but the first tie in chorded notes

Accepted
nobody
None
Defect
2015-07-19
2011-07-30
Anonymous
No

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.

Discussion

  • Google Importer

    Google Importer - 2011-07-30

    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 }

     
  • Google Importer

    Google Importer - 2011-07-30

    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

     
  • Google Importer

    Google Importer - 2011-07-30

    Originally posted by: k-ohara5...@oco.net

    Where is the bug?

    { < c'~ g'~ > q
    < c'^~ g'_~ > q }

     
  • Google Importer

    Google Importer - 2011-07-30

    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.

     
  • Google Importer

    Google Importer - 2011-07-31

    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 }

     
  • Google Importer

    Google Importer - 2011-08-11

    Originally posted by: PhilEHol...@googlemail.com

    (No comment was entered for this change.)

    Status: Accepted

     
  • Google Importer

    Google Importer - 2015-06-07

    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 }

     
  • Google Importer

    Google Importer - 2015-07-19

    Originally posted by: simon.al...@mail.de

    (No comment was entered for this change.)

    Labels: -Priority-Low

     
MongoDB Logo MongoDB