Re: Documentation Tweak: Octave Checks
Le 14/06/2021 à 08:53, 6d8fd379d7b54...@posteo.net a écrit : Hi, I got confused by the Octave Checks documentation: https://lilypond.org/doc/v2.22/Documentation/notation-big-page#octave-checks https://gitlab.com/lilypond/lilypond/-/blob/d408cdc68629ef6df72de0d0ace9c460016565f8/Documentation/en/notation/pitches.itely#L706 I thought the ='4 was some special notation to specify the 4th octave (rather than the octave and then also the duration). I guess, I could've realized that the duration needs to be specified somewhere, but to save other users from also being potentially confused by this, I would suggest changing it from: c''2 d='4 d to just: c''2 d=' That way it would also be more easily comparable to the \octaveCheck example right below it. Cheers! :) Thanks for the suggestion. Here you go: https://gitlab.com/lilypond/lilypond/-/merge_requests/797 Best regards, Jean ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Documentation Tweak: Octave Checks
Hi, I got confused by the Octave Checks documentation: https://lilypond.org/doc/v2.22/Documentation/notation-big-page#octave-checks https://gitlab.com/lilypond/lilypond/-/blob/d408cdc68629ef6df72de0d0ace9c460016565f8/Documentation/en/notation/pitches.itely#L706 I thought the ='4 was some special notation to specify the 4th octave (rather than the octave and then also the duration). I guess, I could've realized that the duration needs to be specified somewhere, but to save other users from also being potentially confused by this, I would suggest changing it from: c''2 d='4 d to just: c''2 d=' That way it would also be more easily comparable to the \octaveCheck example right below it. Cheers! :) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tweaked X-offset returns to the value it would have had without \tweak
Hi,
Take a look at the following code:
\version "2.23.1"
#(define ((note-head-info from) note-head)
(ly:message "From ~a: NoteHead.color = ~s NoteHead.X-offset = ~s"
from
(ly:grob-property note-head 'color)
(ly:grob-property note-head 'X-offset)))
\layout {
\context {
\Score
\consists
#(lambda (context)
(make-engraver
(acknowledgers
((note-head-interface engraver grob source-engraver)
((note-head-info "engraver") grob)
}
\context {
\Voice
\override NoteHead.stencil =
#(note-head-info "NoteHead.stencil")
\override NoteHead.after-line-breaking =
#(note-head-info "NoteHead.after-line-breaking")
\override NoteHead.before-line-breaking =
#(note-head-info "NoteHead.before-line-breaking")
}
}
{
\override NoteHead.color = "red"
\override NoteHead.X-offset = 3.14159
c
\tweak color "blue"
\tweak X-offset -1
e
}
This makes two overrides to NoteHead properties, one
to color and one to X-offset, and shows their values
at various stages of the typesetting process. The first
note takes its property from context defaults, the second
is tweaked.
The output is:
GNU LilyPond 2.23.1
Processing `tmp.ly'
Parsing...
Interpreting music...
From engraver: NoteHead.color = "red" NoteHead.X-offset = 3.14159
From engraver: NoteHead.color = "blue" NoteHead.X-offset = -1
Preprocessing graphical objects...
From NoteHead.before-line-breaking: NoteHead.color = "red"
NoteHead.X-offset = 3.14159
From NoteHead.before-line-breaking: NoteHead.color = "blue"
NoteHead.X-offset = -1
From NoteHead.stencil: NoteHead.color = "blue" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "red" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "red" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "blue" NoteHead.X-offset = 3.14159
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
From NoteHead.after-line-breaking: NoteHead.color = "red"
NoteHead.X-offset = 3.14159
From NoteHead.after-line-breaking: NoteHead.color = "blue"
NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "blue" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "red" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "blue" NoteHead.X-offset = 3.14159
From NoteHead.stencil: NoteHead.color = "red" NoteHead.X-offset = 3.14159
Converting to `tmp.pdf'...
Success: compilation successfully completed
In the translation phase and the before-line-breaking,
callback everything looks expected. The red note has the
X-offset given in the \override, and the blue one has
X-offset specified to the \tweak.
Then things become weird. For both note heads, the X-offset
is the value given to \override, as if \tweak has not
come in. Everything works for color, however.
To clarify, it is expected that grob properties can change
in the lifetime of a grob. Callbacks have calls to
ly:grob-set-property!, ly:grob-translate-axis!
and friends (and their C++ equivalents). It is unexpected
for me, however, that the value of X-offset here is mutated
during the pure phase before page breaking (as evidenced
by log messages). Even more surprising is that it returns
to the value that was the default in the context, even
though the context object is supposed to be long dead.
Thanks,
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
Le mar. 29 janv. 2019 à 21:26, David Kastrup a écrit :
> You are free to invent your own terminology but you cannot expect the
> manual to give authoritive answers according to what you choose to call
> things.
Ouch!
But thanks anyway for the clarification.
Le mar. 29 janv. 2019 à 21:29, Nikolai Hedler a écrit :
> I'm an outside party here, but I think you would find some answers by
> investigating LilyPond's definition of "music object" further; it sounds
> like you're being tripped up by that.
>
> - Nikolai
>
> On Tue, Jan 29, 2019, 15:07 Pierre Perol-Schneider <
> pierre.schneider.pa...@gmail.com wrote:
>
>> What I mean is that the manual does not says "music object".
>> What I mean is that "\tweak color #red \parenthesize c' " has the same
>> output than "\parenthesize \tweak color #red c'" -- weired to me.
>> What I mean is that in "c'-\tweak color #red -1", #1 is not a musical
>> object according to my eyes, it is a music function setting the fingering
>> property on the music
>> object.
>> So, another basic question: is there any technical limit so that \tweak
>> could be applied to \parenthesized ?
>>
>>
>> Le mar. 29 janv. 2019 à 20:33, David Kastrup a écrit :
>>
>> > Pierre Perol-Schneider writes:
>> >
>> > >> Le mar. 29 janv. 2019 à 17:57, David Kastrup a écrit:
>> > >>
>> > >>> Pierre Perol-Schneider writes:
>> > >>>
>> > >>> > Hi Bug Squad,
>> > >>> >
>> > >>> > %% Snippet:
>> > >>> > \version "2.19.82"
>> > >>> > {
>> > >>> > \tweak color #red \parenthesize c'
>> > >>> > %vs:
>> > >>> > \tweak ParenthesesItem.color #red \parenthesize c'
>> > >>> > }
>> > >>> > %%
>> > >>>
>> > >>> So? The color also does not affect Stem, LedgerLine or Flag by
>> > >>> default. Why should it affect the parentheses?
>> > >>
>> > >
>> > > So? Basically the manual says: " The \tweak command applies to the
>> music
>> > > object that immediately follows value in the music stream."
>> > > Considering your answer, do you mean that " \tweak color #red
>> > \parenthesize"
>> > > does not follow the value?
>> >
>> > It doesn't. It precedes the value which is c' .
>> >
>> > > Do you mean that parenthizes are no object?
>> >
>> > The music object is the c' . It is parenthesized, sure. But it also is
>> > stemmed. The parenthesization is not a music object of its own, it is a
>> > music function setting the parenthesize property on the following music
>> > object. Which results in the following music object additionally
>> > creating a ParenthesizeItem (or whatever it was called).
>> >
>> > > I've already asked myself about that before sending the bug report.
>> > > Your answer does not make any clarification, sorry.
>> >
>> > --
>> > David Kastrup
>> >
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
I'm an outside party here, but I think you would find some answers by
investigating LilyPond's definition of "music object" further; it sounds
like you're being tripped up by that.
- Nikolai
On Tue, Jan 29, 2019, 15:07 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com wrote:
> What I mean is that the manual does not says "music object".
> What I mean is that "\tweak color #red \parenthesize c' " has the same
> output than "\parenthesize \tweak color #red c'" -- weired to me.
> What I mean is that in "c'-\tweak color #red -1", #1 is not a musical
> object according to my eyes, it is a music function setting the fingering
> property on the music
> object.
> So, another basic question: is there any technical limit so that \tweak
> could be applied to \parenthesized ?
>
>
> Le mar. 29 janv. 2019 à 20:33, David Kastrup a écrit :
>
> > Pierre Perol-Schneider writes:
> >
> > >> Le mar. 29 janv. 2019 à 17:57, David Kastrup a écrit:
> > >>
> > >>> Pierre Perol-Schneider writes:
> > >>>
> > >>> > Hi Bug Squad,
> > >>> >
> > >>> > %% Snippet:
> > >>> > \version "2.19.82"
> > >>> > {
> > >>> > \tweak color #red \parenthesize c'
> > >>> > %vs:
> > >>> > \tweak ParenthesesItem.color #red \parenthesize c'
> > >>> > }
> > >>> > %%
> > >>>
> > >>> So? The color also does not affect Stem, LedgerLine or Flag by
> > >>> default. Why should it affect the parentheses?
> > >>
> > >
> > > So? Basically the manual says: " The \tweak command applies to the
> music
> > > object that immediately follows value in the music stream."
> > > Considering your answer, do you mean that " \tweak color #red
> > \parenthesize"
> > > does not follow the value?
> >
> > It doesn't. It precedes the value which is c' .
> >
> > > Do you mean that parenthizes are no object?
> >
> > The music object is the c' . It is parenthesized, sure. But it also is
> > stemmed. The parenthesization is not a music object of its own, it is a
> > music function setting the parenthesize property on the following music
> > object. Which results in the following music object additionally
> > creating a ParenthesizeItem (or whatever it was called).
> >
> > > I've already asked myself about that before sending the bug report.
> > > Your answer does not make any clarification, sorry.
> >
> > --
> > David Kastrup
> >
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
Pierre Perol-Schneider writes:
> What I mean is that the manual does not says "music object". What I
> mean is that "\tweak color #red \parenthesize c' " has the same output
> than "\parenthesize \tweak color #red c'" -- weired to me. What I
> mean is that in "c'-\tweak color #red -1", #1 is not a musical object
> according to my eyes, it is a music function setting the fingering
> property on the music object.
You are free to invent your own terminology but you cannot expect the
manual to give authoritive answers according to what you choose to call
things.
> So, another basic question: is there any technical limit so that \tweak
> could be applied to \parenthesized ?
\parenthesized is not an object. As it stands, color tweaks to notes do
not currently extend beyond the notehead and don't affect, say, Stem and
Flag .
If you want to change that relation for parentheses, you can specify
something like
\layout {
\context { \Score
\override ParenthesesItem.color
= #(grob::inherit-parent-property Y 'color) }
}
in which case the Score-wide default color will get taken from the
Y-parent of a ParenthesesItem, usually the item respective to which the
parentheses are placed.
This would cause both notehead and parens in
\tweak color #red \parenthesize c'
to be colored red. If you only want the parens, something like
\single \override ParenthesesItem.color = #red \parenthesize c'
will do the trick, changing only the paren color on the parentehsized c' .
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
What I mean is that the manual does not says "music object".
What I mean is that "\tweak color #red \parenthesize c' " has the same
output than "\parenthesize \tweak color #red c'" -- weired to me.
What I mean is that in "c'-\tweak color #red -1", #1 is not a musical
object according to my eyes, it is a music function setting the fingering
property on the music
object.
So, another basic question: is there any technical limit so that \tweak
could be applied to \parenthesized ?
Le mar. 29 janv. 2019 à 20:33, David Kastrup a écrit :
> Pierre Perol-Schneider writes:
>
> >> Le mar. 29 janv. 2019 à 17:57, David Kastrup a écrit:
> >>
> >>> Pierre Perol-Schneider writes:
> >>>
> >>> > Hi Bug Squad,
> >>> >
> >>> > %% Snippet:
> >>> > \version "2.19.82"
> >>> > {
> >>> > \tweak color #red \parenthesize c'
> >>> > %vs:
> >>> > \tweak ParenthesesItem.color #red \parenthesize c'
> >>> > }
> >>> > %%
> >>>
> >>> So? The color also does not affect Stem, LedgerLine or Flag by
> >>> default. Why should it affect the parentheses?
> >>
> >
> > So? Basically the manual says: " The \tweak command applies to the music
> > object that immediately follows value in the music stream."
> > Considering your answer, do you mean that " \tweak color #red
> \parenthesize"
> > does not follow the value?
>
> It doesn't. It precedes the value which is c' .
>
> > Do you mean that parenthizes are no object?
>
> The music object is the c' . It is parenthesized, sure. But it also is
> stemmed. The parenthesization is not a music object of its own, it is a
> music function setting the parenthesize property on the following music
> object. Which results in the following music object additionally
> creating a ParenthesizeItem (or whatever it was called).
>
> > I've already asked myself about that before sending the bug report.
> > Your answer does not make any clarification, sorry.
>
> --
> David Kastrup
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
Pierre Perol-Schneider writes:
>> Le mar. 29 janv. 2019 à 17:57, David Kastrup a écrit:
>>
>>> Pierre Perol-Schneider writes:
>>>
>>> > Hi Bug Squad,
>>> >
>>> > %% Snippet:
>>> > \version "2.19.82"
>>> > {
>>> > \tweak color #red \parenthesize c'
>>> > %vs:
>>> > \tweak ParenthesesItem.color #red \parenthesize c'
>>> > }
>>> > %%
>>>
>>> So? The color also does not affect Stem, LedgerLine or Flag by
>>> default. Why should it affect the parentheses?
>>
>
> So? Basically the manual says: " The \tweak command applies to the music
> object that immediately follows value in the music stream."
> Considering your answer, do you mean that " \tweak color #red \parenthesize"
> does not follow the value?
It doesn't. It precedes the value which is c' .
> Do you mean that parenthizes are no object?
The music object is the c' . It is parenthesized, sure. But it also is
stemmed. The parenthesization is not a music object of its own, it is a
music function setting the parenthesize property on the following music
object. Which results in the following music object additionally
creating a ParenthesizeItem (or whatever it was called).
> I've already asked myself about that before sending the bug report.
> Your answer does not make any clarification, sorry.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
So? Basically the manual says: " The \tweak command applies to the music
object that immediately follows value in the music stream."
Considering your answer, do you mean that " \tweak color #red \parenthesize"
does not follow the value? Do you mean that parenthizes are no object?
I've already asked myself about that before sending the bug report.
Your answer does not make any clarification, sorry.
Le mar. 29 janv. 2019 à 17:57, David Kastrup a écrit :
> Pierre Perol-Schneider writes:
>
> > Hi Bug Squad,
> >
> > %% Snippet:
> > \version "2.19.82"
> > {
> > \tweak color #red \parenthesize c'
> > %vs:
> > \tweak ParenthesesItem.color #red \parenthesize c'
> > }
> > %%
>
> So? The color also does not affect Stem, LedgerLine or Flag by
> default. Why should it affect the parentheses?
>
> --
> David Kastrup
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \parenthesize is not affected by \tweak
Pierre Perol-Schneider writes:
> Hi Bug Squad,
>
> %% Snippet:
> \version "2.19.82"
> {
> \tweak color #red \parenthesize c'
> %vs:
> \tweak ParenthesesItem.color #red \parenthesize c'
> }
> %%
So? The color also does not affect Stem, LedgerLine or Flag by
default. Why should it affect the parentheses?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
\parenthesize is not affected by \tweak
Hi Bug Squad,
%% Snippet:
\version "2.19.82"
{
\tweak color #red \parenthesize c'
%vs:
\tweak ParenthesesItem.color #red \parenthesize c'
}
%%
Cheers,
Pierre
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tweak on Clef’s X-extent influences on Beam’s vertical position
"Simon Albrecht" wrote in message
news:56536880.1060...@mail.de...
\version "2.19.31"
{
a'8
\once\override Staff.Clef.X-extent = #'(0 . .8)
\clef bass a, b, c
\clef treble a'8
\once\override Staff.Clef.X-extent = #'(0 . 0)
\clef bass a, b, c
}
%%
Yours, Simon
I presume that this is because you've set it's width to zero and there is
therefore nothing for the beam to avoid. Set its extent to a small positive
value (e.g. 0.001) and the beam is back where it was.
--
Phil Holmes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tweak on Clef’s X-extent influences on Beam’s vertical position
\version "2.19.31"
{
a'8
\once\override Staff.Clef.X-extent = #'(0 . .8)
\clef bass a, b, c
\clef treble a'8
\once\override Staff.Clef.X-extent = #'(0 . 0)
\clef bass a, b, c
}
%%
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tweak on clef spills over
Hello,
in the following example, the tweak on one clef spills over to the next:
%
\version "2.19.31"
{
\clef treble a'8
\tweak Clef.X-extent #'(0 . 0)
\clef bass a, b, c
\clef treble a'4
}
%
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tweak rest.staff-position fails with beam
<https://sourceforge.net/p/testlilyissues/issues/4657/>
On 30.10.2015 14:28, Simon Albrecht wrote:
Hello,
if a beam is present, tweaking rest.staff-position remains without
effect:
%%%
\version "2.19.28"
{
\voiceTwo
f'16[ \tweak staff-position 10 r16 16]
}
%%%
Output attached.
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tweak rest.staff-position fails with beam
On 30.10.2015 14:28, Simon Albrecht wrote:
Hello,
if a beam is present, tweaking rest.staff-position remains without effect:
Should’ve added that \once\override works fine.
%%%
\version "2.19.28"
{
\voiceTwo
f'16[ \tweak staff-position 10 r16 16]
}
%%%
Output attached.
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tweak rest.staff-position fails with beam
Hello,
if a beam is present, tweaking rest.staff-position remains without effect:
%%%
\version "2.19.28"
{
\voiceTwo
f'16[ \tweak staff-position 10 r16 16]
}
%%%
Output attached.
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \tweak fails on MultiMeasureRests
On 18/02/15 17:27, Simon Albrecht wrote:
Hello list,
it seems that the \tweak command does not have any effect on multi
measure rests, neither with nor without specifying the grob:
\version "2.19.8"
{ \tweak MultiMeasureRest.color #red R1 \tweak color #red R1 }
I couldn't find an entry in the issue tracker, nor any mention of this
in the docs. It should probably be mentioned in the Known issues and
warnings at the bottom of both
<http://lilypond.org/doc/v2.19/Documentation/notation/writing-rests#full-measure-rests>
and
<http://lilypond.org/doc/v2.19/Documentation/notation/the-tweak-command>.
Yours, Simon
Thank you.
Added as
https://code.google.com/p/lilypond/issues/detail?id=4295&thanks=4295
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
\tweak fails on MultiMeasureRests
Hello list,
it seems that the \tweak command does not have any effect on multi
measure rests, neither with nor without specifying the grob:
\version "2.19.8"
{ \tweak MultiMeasureRest.color #red R1 \tweak color #red R1 }
I couldn't find an entry in the issue tracker, nor any mention of this
in the docs. It should probably be mentioned in the Known issues and
warnings at the bottom of both
<http://lilypond.org/doc/v2.19/Documentation/notation/writing-rests#full-measure-rests>
and
<http://lilypond.org/doc/v2.19/Documentation/notation/the-tweak-command>.
Yours, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR and allocating tweak command to variable
David Kastrup writes:
> Nick Payne writes:
>
>> I was trying to allocate a tweak command to a variable and eventually
>> managed to get it to work after finding what I needed by a search of
>> the lilypond-user archives (
>> http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00279.html).
>>
>> However, I was initially misled by the NR having a section named
>> "Using variables for tweaks ":
>> http://www.lilypond.org/doc/v2.17/Documentation/learning/using-variables-for-tweaks,
>> but this actually deals with using variables for overrides, and should
>> maybe be renamed as "Using variables for overrides".
>>
>> The code that I got to work is below:
>>
>> \version "2.17.14"
>>
>> fia = #(define-music-function
>> (parser location grb)
>> (ly:music?)
>> #{
>> -\tweak script-priority #-199 -$grb
>> #})
>
> I'd use define-event-function instead, so that \fia can be used without
> a leading - before it. I'd also use an argument of type ly:event? in
> order to just allow articulations as an argument type (there is no sense
> in tweaking the script priority of a basic music expression like a
> note).
Thanks for the report, Nick, and the advice, David.
I've created a doc tracker for this:
https://code.google.com/p/lilypond/issues/detail?id=3280
Cheers,
Colin.
--
Colin Hall
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR and allocating tweak command to variable
Nick Payne writes:
> I was trying to allocate a tweak command to a variable and eventually
> managed to get it to work after finding what I needed by a search of
> the lilypond-user archives (
> http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00279.html).
>
> However, I was initially misled by the NR having a section named
> "Using variables for tweaks ":
> http://www.lilypond.org/doc/v2.17/Documentation/learning/using-variables-for-tweaks,
> but this actually deals with using variables for overrides, and should
> maybe be renamed as "Using variables for overrides".
>
> The code that I got to work is below:
>
> \version "2.17.14"
>
> fia = #(define-music-function
> (parser location grb)
> (ly:music?)
> #{
> -\tweak script-priority #-199 -$grb
> #})
I'd use define-event-function instead, so that \fia can be used without
a leading - before it. I'd also use an argument of type ly:event? in
order to just allow articulations as an argument type (there is no sense
in tweaking the script priority of a basic music expression like a
note).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
NR and allocating tweak command to variable
I was trying to allocate a tweak command to a variable and eventually
managed to get it to work after finding what I needed by a search of the
lilypond-user archives (
http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00279.html).
However, I was initially misled by the NR having a section named "Using
variables for tweaks ":
http://www.lilypond.org/doc/v2.17/Documentation/learning/using-variables-for-tweaks,
but this actually deals with using variables for overrides, and should
maybe be renamed as "Using variables for overrides".
The code that I got to work is below:
\version "2.17.14"
fia = #(define-music-function
(parser location grb)
(ly:music?)
#{
-\tweak script-priority #-199 -$grb
#})
\relative f'' {
\set fingeringOrientations = #'(left)
4
4
4
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Status: Verified Comment #7 on issue 2164 by elu...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Status: Fixed Labels: -Patch-push Comment #6 on issue 2164 by pkx1...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164 Wed, 4 Jan 2012 08:00:45 + (08:00 +) commit d7bf0e87283f48e945bc228b1ba79571d636a528 James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Labels: -Patch-countdown Patch-push Comment #5 on issue 2164 by colinpkc...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164 Counted down to 20120103, please push ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Labels: Patch-review Comment #3 on issue 2164 by lilypond...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164#c3 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Comment #2 on issue 2164 by pkx1...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164#c2 Doc: LM adjusted explanation for \once This is for Tracker issue 2164 As suggested by email on lilypond-user Updated example and text to show that after using \once, the 'revert' does not necessarily go back to the 'default' value as originally stated, if another \override is still in place. http://codereview.appspot.com/5489129 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Labels: Patch-new Comment #1 on issue 2164 by pkx1...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164#c1 Doc: LM adjusted explanation for \once This is for Tracker issue 2164 As suggested by email on lilypond-user Updated example and text to show that after using \once, the 'revert' does not necessarily go back to the 'default' value as originally stated, if another \override is still in place. http://codereview.appspot.com/5489129 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Status: Started Owner: pkx1...@gmail.com Labels: Type-Documentation New issue 2164 by pkx1...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164 Submitted by drippingtone+lilyp...@gmail.com The documentation for the \once prefix (both v2.14 and v2.15) at: http://lilypond.org/doc/v2.14/Documentation/learning/tweaking-methods says: [...] effective only during the current musical moment before the property reverts back to its default value. It should say something like : "reverts back to its current value (this can be different from the default if an \override is in effect)." Slightly changing the example in the documentation illustrates this: c4 d \override NoteHead #'color = #red e4 f | \once \override NoteHead #'color = #green g4 a \revert NoteHead #'color b c | A single note is green, then we continue with red notes until we use \revert to get the default color (black). I think the learning manual can fully explain this without becoming overly complicated (this is the natural expectation from the English keyword \once). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak does not work for changing control-points of any but the first tie in chorded notes
Updates: Status: Accepted Comment #6 on issue 1789 by philehol...@googlemail.com: \tweak does not work for changing control-points of any but the first tie in chorded notes http://code.google.com/p/lilypond/issues/detail?id=1789 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1751 in lilypond: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak
Updates: Status: Verified Comment #3 on issue 1751 by philehol...@googlemail.com: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak http://code.google.com/p/lilypond/issues/detail?id=1751 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak does not work for changing control-points of any but the first tie in chorded notes
Comment #5 on issue 1789 by k-ohara5...@oco.net: \tweak does not work for
changing control-points of any but the first tie in chorded notes
http://code.google.com/p/lilypond/issues/detail?id=1789
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.
{
q }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak does not work for changing control-points of any but the first tie in chorded notes
Comment #4 on issue 1789 by d...@gnu.org: \tweak does not work for changing control-points of any but the first tie in chorded notes http://code.google.com/p/lilypond/issues/detail?id=1789 Could you explain what you are trying to tell us? Tie directions are not the same as control points. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak does not work for changing control-points of any but the first tie in chorded notes
Comment #3 on issue 1789 by k-ohara5...@oco.net: \tweak does not work for
changing control-points of any but the first tie in chorded notes
http://code.google.com/p/lilypond/issues/detail?id=1789
Where is the bug?
{ < c'~ g'~ > q
< c'^~ g'_~ > q }
Attachments:
temp.png 5.1 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak does not work for changing control-points of any but the first tie in chorded notes
Updates: Summary: \tweak does not work for changing control-points of any but the first tie in chorded notes Comment #2 on issue 1789 by d...@gnu.org: \tweak does not work for changing control-points of any but the first tie in chorded notes http://code.google.com/p/lilypond/issues/detail?id=1789 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1789 in lilypond: \tweak is 'broken' when trying to tie chorded notes (other than the first note in the chord)
Comment #1 on issue 1789 by reinhold...@gmail.com: \tweak is 'broken' when
trying to tie chorded notes (other than the first note in the chord)
http://code.google.com/p/lilypond/issues/detail?id=1789
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 }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1789 in lilypond: \tweak is 'broken' when trying to tie chorded notes (other than the first note in the chord)
Status: New
Owner:
Labels: Type-Defect Priority-Low
New issue 1789 by pkx1...@gmail.com: \tweak is 'broken' when trying to tie
chorded notes (other than the first note in the chord)
http://code.google.com/p/lilypond/issues/detail?id=1789
Here is the main thread:
--snip--
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf
Of Jan Warchol
)Sent: 29 July 2011 08:11
)To: David Kastrup
)Cc: lilypond-de...@gnu.org
)Subject: Re: music function semantics
)
)David,
)
)2011/7/27 David Kastrup :
)> Neil Puttock writes:
)>
)>> On 26 July 2011 22:41, David Kastrup 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.
4
It's just the tweak that seems to be broken in your case... I would say
this is a bug, although of low priority.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
On 7/24/11 4:12 AM, "-Eluze" wrote:
>>
>> If I run the command above with 2.15.5, I get the output at the bottom.
>> I'm not convinced that's correct.
>>
>> Unbound variable: t
>> < \tweak #'transparent ## c e >
>>
> an old question: should it be ##t or just #t?
>
> a small example to illustrate the dilemma (from the NR) - emphasized by me:
>
> Controlling tuplet bracket visibility
> The default behavior of tuplet-bracket visibility is to print a bracket
> unless there is a beam
> of the same length as the tuplet. To control the visibility of tuplet
> brackets, set the property
> 'bracket-visibility to either #t (always print a bracket), #f (never print a
> bracket) or
> #'if-no-beam (only print a bracket if there is no beam).
IMO, we should probably not list these in the text, but rather just show
examples.
But if we do list them, they should be #t, #f, 'if-no-beam.
#'if-no-beam is the only value in that section that has the # used to
introduce a scheme variable.
> music = \relative c'' {
> \times 2/3 { c16[ d e } f8]
> \times 2/3 { c8 d e }
> \times 2/3 { c4 d e }
> }
> \new Voice {
> \relative c' {
> << \music s4^"default" >>
> \override TupletBracket #'bracket-visibility = #'if-no-beam
> << \music s4^"'if-no-beam" >>
> \override TupletBracket #'bracket-visibility = ##t
> << \music s4^"#t" >>
> \override TupletBracket #'bracket-visibility = ##f
> << \music s4^"#f" >>
> }
> }
The example is correct.
Thanks,
Carl
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Updates: Status: Verified Comment #7 on issue 1733 by philehol...@googlemail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
lilypond-4 wrote:
>
> If I run the command above with 2.15.5, I get the output at the bottom.
> I'm not convinced that's correct.
>
> Unbound variable: t
> < \tweak #'transparent ## c e >
>
an old question: should it be ##t or just #t?
a small example to illustrate the dilemma (from the NR) - emphasized by me:
Controlling tuplet bracket visibility
The default behavior of tuplet-bracket visibility is to print a bracket
unless there is a beam
of the same length as the tuplet. To control the visibility of tuplet
brackets, set the property
'bracket-visibility to either #t (always print a bracket), #f (never print a
bracket) or
#'if-no-beam (only print a bracket if there is no beam).
music = \relative c'' {
\times 2/3 { c16[ d e } f8]
\times 2/3 { c8 d e }
\times 2/3 { c4 d e }
}
\new Voice {
\relative c' {
<< \music s4^"default" >>
\override TupletBracket #'bracket-visibility = #'if-no-beam
<< \music s4^"'if-no-beam" >>
\override TupletBracket #'bracket-visibility = ##t
<< \music s4^"#t" >>
\override TupletBracket #'bracket-visibility = ##f
<< \music s4^"#f" >>
}
}
\displayLilyMusic also reacts differently on each.
Eluze
--
View this message in context:
http://old.nabble.com/Issue-1733-in-lilypond%3A-%5CdisplayLilyMusic-ignores-%5Ctweak-tp31983686p32125152.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Comment #6 on issue 1733 by d...@gnu.org: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 I don't see anything wrong with the reaction for this input. The input itself is nonsensical and should use ##t rather than #t. So I think the problem is rather with the report than with the fix. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Comment #5 on issue 1733 by philehol...@googlemail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 If I run the command above with 2.15.5, I get the output at the bottom. I'm not convinced that's correct. Processing `1733.ly' Parsing... 1733.ly:1:42: error: GUILE signaled an error for the expression beginning here \displayLilyMusic < \tweak #'transparent # t c e > Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `1733.ps'... Converting to `./1733.pdf'... error: failed files: "D:\\Music\\LilyPondDev\\BugSquad\\1733.ly" Unbound variable: t < \tweak #'transparent ## c e > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1751 in lilypond: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak
Updates: Labels: -backport backported fixed_2_14_2 Comment #2 on issue 1751 by carl.d.s...@gmail.com: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak http://code.google.com/p/lilypond/issues/detail?id=1751 Backported, with commits 58956ae1c085b14dbee58b2dd6abb4edd5d81890 and 11763dd1b3e6747cdbb8bfc196e5d045660f8da2 (The second commit is to add the lower version number to the snippet) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1751 in lilypond: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak
Updates: Status: Fixed Labels: fixed_2_15_5 backport Comment #1 on issue 1751 by n.putt...@gmail.com: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak http://code.google.com/p/lilypond/issues/detail?id=1751 704a0bcff798abdeabe103f874c4443f5f474b00 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Updates: Labels: -backport fixed_2_15_4 Comment #4 on issue 1733 by carl.d.s...@gmail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 Backported ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1751 in lilypond: Most analysis brackets get incorrect event-cause info, breaking point-and-click & \tweak
Status: Started
Owner: n.putt...@gmail.com
Labels: Type-Defect Priority-Medium
New issue 1751 by n.putt...@gmail.com: Most analysis brackets get incorrect
event-cause info, breaking point-and-click & \tweak
http://code.google.com/p/lilypond/issues/detail?id=1751
Since the Horizontal_bracket_engraver fails to reset event storage at each
timestep, when HorizontalBracket grobs are created they often get an
event-cause associated with an existing bracket.
In the following snippet, the second nested bracket gets the same
event-cause as the first, which means the line thickness tweak is applied
to both grobs:
\version "2.15.5"
\layout {
\context {
\Voice
\consists "Horizontal_bracket_engraver"
}
}
\relative c' {
c1-\tweak #'thickness #6 \startGroup
c1\startGroup
c1\stopGroup
c1\stopGroup
}
Attachments:
bracket-bug.png 2.4 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Updates: Status: Fixed Labels: -Patch-review fixed_2_15_5 backport Comment #3 on issue 1733 by n.putt...@gmail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 d5766025a1573c709dfa3c9663c1c6b903abec24 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Updates: Labels: -Patch-new Patch-review Comment #2 on issue 1733 by pkx1...@gmail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 Reg tests pass and no make problems. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Updates: Labels: Patch-new Comment #1 on issue 1733 by n.putt...@gmail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 http://codereview.appspot.com/4645077/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1733 in lilypond: \displayLilyMusic ignores \tweak
Status: Started Owner: n.putt...@gmail.com Labels: Type-Enhancement Priority-Medium New issue 1733 by n.putt...@gmail.com: \displayLilyMusic ignores \tweak http://code.google.com/p/lilypond/issues/detail?id=1733 \displayLilyMusic has no display method to accommodate \tweak; all \tweak invocations are silently ignored: \displayLilyMusic < \tweak #'transparent #t c e > -> < c e > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Updates: Status: Verified Comment #16 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #15 on issue 1180 by percival.music.ca: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Don't consider translations. If the English page is fixed, mark this verified. After 2.14, if there's a lot more bug squad members, and a lot more translators, we might consider formalizing some process for dealing with translations... but for now, I think that the existing translator policies are fine for the amount of effort we have directed at that task. As far as our issue tracker goes, though: ignore translations completely when considering documentation issues. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #14 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music
example needs additional tweak (plus explanation)
http://code.google.com/p/lilypond/issues/detail?id=1180
Sorry, this isn't fixed - at least on the translated versions of the page.
I don't know if these are translation kind of issues or if this current
issue has to be opened again - please someone consider what to do.
English - issue fixed.
French, Japanese - no line breaking but still collision of slur and beam.
Spanish - old line breaking and code, and therefore collision of slur and
beam
Dutch - issue fixed - but it is the English text also.
German - old line breaking and code with collision + new bug in last
example on the page:
in the last example on the German page the section:
--
\mergeDifferentlyDottedOn
<<
{ c,8 d fis bes
% Reposition the c2 to the right of the merged note
c,8~ \once \override NoteColumn #'force-hshift = #1.0
% Move the c2 out of the main note column so the merge will work
\shiftOnn c2
}
\\
--
has to be changed to:
--
\mergeDifferentlyDottedOn
<<
{ c,8 d fis bes a | }
\\
{
% Reposition the c2 to the right of the merged note
c,8~ \once \override NoteColumn #'force-hshift = #1.0
% Move the c2 out of the main note column so the merge will work
\shiftOnn c2
}
\\
--
If these are translation issues in their own right, the current issue can
be marked as verified.
- The example on the English page is correct.
- The example works without collision with and without line breaks (see
attachment
Attachments:
chopin-new.png 19.9 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #13 on issue 1180 by percival.music.ca: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Urs: you're not supposed to look at git stuff. Always wait until the next devel release. Trevor: I've added you as a project member, so you can now change issue statuses and stuff. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Updates: Status: Fixed Labels: fixed_2_13_29 Comment #12 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Having now seen the pdf output of the newest 2.13.29 doc I assume the issue is fixed. Please someone else verify after 2.13.29 is released. The interdependency with issue 1015 has to be reconsidered when working on 1015, but this has already been mentioned with this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
OK, then please change the status to fixed. I can't - I don't have sufficient permissions. Or is this impossible because of the 1015 issue? Maybe .. I don't know. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Am 15.07.2010 00:08, schrieb Trevor Daniels: When (and where) can I see these changes. So far I am only working with the binary releases, and I don't see this will be changing shortly ... The changes are in git for anyone who can build the docs and will appear in the documentation to 2.13.29 when that is released. I guess verification can wait until then. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond OK, then please change the status to fixed. Or is this impossible because of the 1015 issue? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
When (and where) can I see these changes. So far I am only working with the binary releases, and I don't see this will be changing shortly ... The changes are in git for anyone who can build the docs and will appear in the documentation to 2.13.29 when that is released. I guess verification can wait until then. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #11 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Sorry, I don't see how I can use these links. Probably it's sufficient to wait for a release to evaluate the changes? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #10 on issue 1180 by pkx1...@hotmail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=e3ae33d7fc91b79043ced4514a8670ce4d9ed2d0 for the main changes and http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=cf8dacf7b6462f9e750658621c15b9e781b82ed4 for the line length. James ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #9 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 When (and where) can I see these changes. So far I am only working with the binary releases, and I don't see this will be changing shortly ... ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #8 on issue 1180 by tdanielsmusic: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 I've just pushed two commits as fixes for this issue. The first commit changes the example to use explicitly instantiated voices which permits collision avoidance to work, resulting in a phrasing slur which now avoids the beam in measure 3, even with the line break at the end of measure 3. This is a beneficial change in its own right even without considering the line break. The second commit attempts to place the example on one line, as originally intended. The old code included an override to the lilypond command which changed the line-width to 5.5\in. This is too small to prevent a line break, so I've changed it to 6\in. This results in a much cleaner example. However this line-width override will need to reconsidered along with issue 1015. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #7 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Hi Trevor, good point. If I'll see something I'll have a new look at it. Best Urs ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #6 on issue 1180 by tdanielsmusic: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Thanks for the hint, Neil. This example would greatly benefit from being re-written to use explicitly instantiated voices anyway. It would not only fix the immediate problem (which appeared when the line length was reduced generally for the docs - previously it fitted on one line) but would also be a far better example to users by encouraging them to declare voices explicitly. As this approach is independent of 1015 and as I created the example in the first place I'll make a start on converting it tomorrow. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #5 on issue 1180 by n.puttock: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 If anybody still wants to work on this, it's a voicing issue: the example starts off in the main voice, creates several new voices for the polyphonic section, then returns to the main voice. This is problematic for slurs, since the objects they encompass must be visible (i.e., acknowledgable in the same context) for collision avoidance to work properly. There are two solutions: 1) Continue using polyphony shorthand, but name the main voice `1': this ensures that the implicit \voiceOne notes (which are currently invisible to the Phrasing_slur_engraver) are created in the same context as the earlier notes; 2) Use explicitly instantiated voices for the second, third and fourth voices. (alternatively, rewrite the whole section after the Mikuli edition :) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Updates: Blockedon: 1015 Comment #4 on issue 1180 by percival.music.ca: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 A link would help: http://lilypond.org/doc/v2.13/Documentation/learning/real-music-example 4.5.3 has at least one trivial doc policy violation, which James could hunt for and fix. Also, James had a point earlier when he suggested that 1015 was related; this section explicitly sets the [line-width] (also contrary to doc policy, and incidentally was one of the major reasons I added 1015 to the tracker). pngs are extremely recommended, since they will be displayed inline in the tracker, which makes it much easier for people to understand the comments at a glance. Other than minor doc policy stuff (mostly for practice), I don't see much point in seriously working on this until 1015 is done. The solution to 1015 might force us to rethink the music we use on this page, which in turn would change the possible/desirable tweaks. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Updates: Status: Accepted Comment #3 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #2 on issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Your tweak looks fine at first glance. But: As I mentioned here http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00214.html (now I realize that a forgot to mention it in the issue report, sorry!!!) there is a line break in the example on the website. If I add "ragged-right = ##t" in a \paper section and a manual \break before the last bar I get the attached output which is much worse than the original. Also if I change the horizontal spacing (by adding a right-margin of, say 9\cm the phrasingSlur doesn't fit anymore (because its extent is now hardcoded?). So I think we have a problem with this example. And I also think it is quite important to find a clear solution to this - as it is a point where a newcomer will end up when getting acquainted with LilyPond. (Now that I'm writing this I vaguely recall having already been annoyed by this phrasingSlur when I first met LilyPond. It didn't stop me from being interested, but it could well keep someone else from bothering more with LilyPond.) 1) If someone recreates the example and compiles it, it will look different than on the website because it won't have the line break in it. While this might seem to be neglectable it isn't really straightforward. 2) It becomes a problem because the phrasingSlur behaves quite differently with or without the line break - and needs (different) manual tweaking in both cases. 3) So it isn't clear which situation should be addressed by a tweak, the one on the website or the one a user would see if he compiles for himself. Both couldn't easily be explained in the text. Basically there would have to be a tweak for the version with line break and a comment going something like: "but if you compile it yourself you will have a different situation" ... Ideally the problem should be avoided in the first place, i.e. having the example fit onto one system on the website. If that's not possible one might have to suggest a completely new and shorter example for this chapter. I wouldn't want to demand such a major change (and couldn't contribute one neither). But I also think that a new user shouldn't be confronted with such a complicated situation. Or is this after all an issue with the phrasingSlur itself and should get a new issue on its own? So any opinions on the matter highly welcome. Urs P.S. When compiling the snippet I noticed another (minor) error in the example code: After the last g2. of rhMusic there is a bar check which obviously fails and should be removed. Attachments: LM-phrasingSlur.png 22.8 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Comment #1 on issue 1180 by pkx1...@hotmail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 This is the tweak needed after the first 'r2' but before the 'c4.\( ' \once \override PhrasingSlur #'control-points = #'((1 . 2.5) (2 . 3) (21 . 7.5) (47.3 . 2.85)) Attached is the PDF - I know we normally ask for png files but I think the PDF is more apt in this case so that someone else can check if the curve is smooth enough. Attachments: Example.pdf 36.5 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1180 in lilypond: LM 4.5.3 Real music example needs additional tweak (plus explanation)
Status: New Owner: Labels: Type-Documentation Priority-Low New issue 1180 by lilyli...@googlemail.com: LM 4.5.3 Real music example needs additional tweak (plus explanation) http://code.google.com/p/lilypond/issues/detail?id=1180 Chapter 4.5.3 of the LM demonstrates how to tweak a complex example. However there is one tweak missing: The collision of the right hand phrasingSlur with the beams in bar 3. Unfortunately I can't provide a concrete suggestion as it is still a little bit over my head. The change should go after the third music example, to the paragraph starting with "The first bar is now correct. " After this sentence you might include something like "But the phrasing slur needs further attention because it clashes with the right hand beams in bar 3. ...". If the collision is due to the line break (which I assume) this should also be mentioned/explained - would be also a valuable enhancenment of this page. This probably needs the inclusion of one more version of the example. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: tweak
The next time you send follow-ups to emails on the mailing list, please keep the same subject line. It takes some effort to figure out what problem you refer to. Great that you have figured out the solution yourself and thanks for sharing it to others on the mailing list. /Mats Alex Shanin wrote: I'm not top posting. Things look much better after issuing "\override Beam #'concaveness = #0" (or some mild value near zero - I use it \once). So the problem is gone. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond -- = Mats Bengtsson Signal Processing School of Electrical Engineering Royal Institute of Technology (KTH) SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
tweak
> I'm not top posting. Things look much better after issuing "\override Beam #'concaveness = #0" (or some mild value near zero - I use it \once). So the problem is gone. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
