Re: shape and chords

[Jan-Peter Voigt]

Hi David,

... moving this to devel ...
I had a look into "tie-column.cc":
In the scheme-callback "calc_positioning_done" all ties in a chord are 
assigned control-points in a loop. So it might be possible to define a 
scheme-callback "calc_control_point_column", that returns a list of a 
list of a list ... that returns all control-point-lists from the 
Tie_column. If it is not a column, say one tie, it might still return a 
list of this one tie.
This is just a thought - it might have implications or whatever fiddling 
with those files ...
My intention is: I would like to shape all ties in a chord.

Best, Jan-Peter

On 20.06.2012 01:27, David Nalesnik wrote:
> Hi Jan-Peter,
>
> >     It should be fairly straightforward to define a command to
> >     operate on unbroken/broken stacks of ties, and I can look into this.
>
>
> Oops, I spoke too soon!  There's a known issue about this 
> http://www.lilypond.org/doc/v2.15/Documentation/notation/modifying-shapes:
>
> It is not possible to modify shapes of ties or slurs by changing the 
> |control-points| property if there are multiple ties or slurs at the 
> same musical moment – the |\tweak| command will also not work in this 
> case. However, the |tie-configuration| property of |TieColumn| can be 
> overridden to set start line and direction as required.
>
> That's unfortunate :(
>
> >         2. In the development version warnings were given and a color
> >         was used to indicate a mismatch of offset count and number of
> >         curves in a broken one. What is the reason to not include
> >         that into the release?
> >
> >     My thinking here was to get the basic functionality into the code
> >     base, and these warnings are helpful but not strictly necessary.
> >       (They were designed to be part of a slur-editing tool and might
> >     be more suitable for now as an enhancement on the LSR--opinions
> >     welcome!)
>     That sounds reasonable. But probably there is room for a
>     "backdoor" to switch it on or plug in some kind of callback - a
>     context property(?) - so there's no need to copy the whole
>     function to LSR - now that it's already in the codebase ;-) ...
>     just a thought.
>
>
> I'll have to think about this some.  The issue I see is that the 
> version which reports mismatches depends on the location argument of 
> the music function for the error message.
>
>
>     For now, thanks again for this amazing helper :-)
>
>
> You're very welcome!  Thanks to everybody who helped get it to this stage!
> Best,
> David