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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel