Re: Tie shape inside chords: Inconsistent compilation
Great! Thank you very much Harm,
Cheers,
Pierre
Le ven. 26 oct. 2018 à 16:13, Thomas Morley a
écrit :
> Am Fr., 26. Okt. 2018 um 15:41 Uhr schrieb Pierre Perol-Schneider
> :
> >
> > Hi,
> > Please consider the following example:
> >
> > %%
> > \version "2.19.82"
> > music =
> > \fixed c' {
> > \time 3/8
> > \voiceOne
> > 4. q
> > }
> > { \music } { \music } { \music }
> > %%
> >
> > After trying several compilation, sometimes the shape command is
> applied, sometimes not.
> > I've found multiple workarounds in the past messages since this problem
> seems to be related to a known tie bug. However none of them seem to work
> in the piece I'm working on.
> > Any idea?
> > TIA, Cheers,
> > Pierre
>
> Hi Pierre,
>
> LilyPond puts in-chord Ties in a TieColumn and performs her own thingy
> according to the procedure 'positioning-done is set to, probably
> dropping a user input for \shape.
> Imho, best you can do is: set positioning-done #t, meaning: "Dear
> LilyPond, don't bother about positioning the Ties, _I_ will do it."
> Ofcourse you _should_ do then. :)
> I.e. the Ties needs a direction. In your example it's done by
> \voiceOne, you could use direction-modifiers ^/_ as well.
> Now apply \shape where you want.
>
> Example with some crazy values:
>
> music =
> \fixed c' {
> \time 3/8
> g'-\shape #'((0 . 0) (0 . 0) (1 . 0) (-2 . 2)) ^~
> >4.
> \once \override TieColumn.positioning-done = ##t
> q
> }
> { \music } { \music } { \music }
>
> HTH,
> Harm
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tie shape inside chords: Inconsistent compilation
Am Fr., 26. Okt. 2018 um 15:41 Uhr schrieb Pierre Perol-Schneider
:
>
> Hi,
> Please consider the following example:
>
> %%
> \version "2.19.82"
> music =
> \fixed c' {
> \time 3/8
> \voiceOne
> 4. q
> }
> { \music } { \music } { \music }
> %%
>
> After trying several compilation, sometimes the shape command is applied,
> sometimes not.
> I've found multiple workarounds in the past messages since this problem seems
> to be related to a known tie bug. However none of them seem to work in the
> piece I'm working on.
> Any idea?
> TIA, Cheers,
> Pierre
Hi Pierre,
LilyPond puts in-chord Ties in a TieColumn and performs her own thingy
according to the procedure 'positioning-done is set to, probably
dropping a user input for \shape.
Imho, best you can do is: set positioning-done #t, meaning: "Dear
LilyPond, don't bother about positioning the Ties, _I_ will do it."
Ofcourse you _should_ do then. :)
I.e. the Ties needs a direction. In your example it's done by
\voiceOne, you could use direction-modifiers ^/_ as well.
Now apply \shape where you want.
Example with some crazy values:
music =
\fixed c' {
\time 3/8
4.
\once \override TieColumn.positioning-done = ##t
q
}
{ \music } { \music } { \music }
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Tie shape inside chords: Inconsistent compilation
Hi,
Please consider the following example:
%%
\version "2.19.82"
music =
\fixed c' {
\time 3/8
\voiceOne
4. q
}
{ \music } { \music } { \music }
%%
After trying several compilation, sometimes the shape command is applied,
sometimes not.
I've found multiple workarounds in the past messages since this problem
seems to be related to a known tie bug. However none of them seem to work
in the piece I'm working on.
Any idea?
TIA, Cheers,
Pierre
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
shape and chords
Hello list, hello David,
I have two questions concerning the \shape command (2.15.40) created by
David Nalesnik:
1. Is it possible to shape ties in a chord?
{ \shape Tie #'(((0 . 0)(0 . 1)(0 . -1)(0 . 0))((0 . 0)(0 . 1)(0 . -1)(0
. 0))) c' e' g' b'1 ~ | q4 }
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?
Cheers,
Jan-Peter
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: shape and chords
Hi Jan-Peter,
On Tue, Jun 19, 2012 at 7:51 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:
Hello list, hello David,
I have two questions concerning the \shape command (2.15.40) created by
David Nalesnik:
1. Is it possible to shape ties in a chord?
{ \shape Tie #'(((0 . 0)(0 . 1)(0 . -1)(0 . 0))((0 . 0)(0 . 1)(0 . -1)(0 .
0))) c' e' g' b'1 ~ | q4 }
Unfortunately, no. It should be fairly straightforward to define a command
to operate on unbroken/broken stacks of ties, and I can look into this.
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!)
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: shape and chords
Hi David,
thanks for your reply!
Am 19.06.2012 um 19:20 schrieb David Nalesnik:
Hi Jan-Peter,
On Tue, Jun 19, 2012 at 7:51 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:
Hello list, hello David,
I have two questions concerning the \shape command (2.15.40) created by David
Nalesnik:
1. Is it possible to shape ties in a chord?
{ \shape Tie #'(((0 . 0)(0 . 1)(0 . -1)(0 . 0))((0 . 0)(0 . 1)(0 . -1)(0 .
0))) c' e' g' b'1 ~ | q4 }
Unfortunately, no. It should be fairly straightforward to define a command
to operate on unbroken/broken stacks of ties, and I can look into this.
that would be great! :-) I think two problems have to be solved:
1. Where is the stack of control-points found and how is it modified?
2. Howto define the offsets on this extra-dimension. If we have a stack of
broken ties, we have to define N x M x 4 offset-pairs:
{ c' e' g' b'1 ~ \break q4 } = 4 x 2 x 4 = 32 x '(dx . dy)
Earlier today I had a case, were I would have modified all 3 ties with the same
values. So this might be one option. But in many cases tie-direction is
opposite for a two-note-chord.
Hm, I think about this.
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.
For now, thanks again for this amazing helper :-)
Best Jan-Peter
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: shape and chords
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-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
