On Thu, 20 Jun 2013 00:36:22 +0200
David Kastrup wrote:
> A story is not an example.
I misunderstood you. I finally realized that you meant using
Staff.middleCClefPosition. Yes, it allows me to do what I did with
KeySignature.c0-position without any tricks in Scheme. I checked it
extensively w
Pavel Roskin writes:
> On Wed, 19 Jun 2013 18:00:09 +0200
> David Kastrup wrote:
>
>> Pavel Roskin writes:
>>
>> > Quoting David Kastrup :
>> >
>> >> Pavel Roskin writes:
>> >>
>> >>> I just hope you won't take away the ability to adjust the key
>> >>> signature without placing the accidental
On Wed, 19 Jun 2013 18:00:09 +0200
David Kastrup wrote:
> Pavel Roskin writes:
>
> > Quoting David Kastrup :
> >
> >> Pavel Roskin writes:
> >>
> >>> I just hope you won't take away the ability to adjust the key
> >>> signature without placing the accidentals manually.
> >>
> >> It would appea
Pavel Roskin writes:
> Quoting David Kastrup :
>
>> Pavel Roskin writes:
>>
>>> I just hope you won't take away the ability to adjust the key
>>> signature without placing the accidentals manually.
>>
>> It would appear that you can adjust the key signature just fine by using
>> the _intended_ c
Quoting David Kastrup :
Pavel Roskin writes:
I just hope you won't take away the ability to adjust the key
signature without placing the accidentals manually.
It would appear that you can adjust the key signature just fine by using
the _intended_ context variables for that.
If you mean so
Pavel Roskin writes:
> Quoting David Kastrup :
>
>> Pavel Roskin writes:
>>
>>> By the way, setting KeySignature.c0-position with \override doesn't
>>> work. I had to resort to setting it in Scheme:
>>
>> Given the analysis in a longer mail, I revert my opinion that we need to
>> do something
Quoting David Kastrup :
Pavel Roskin writes:
By the way, setting KeySignature.c0-position with \override doesn't
work. I had to resort to setting it in Scheme:
Given the analysis in a longer mail, I revert my opinion that we need to
do something here. c0-position for the relevant grobs _c
Pavel Roskin writes:
> Quoting David Kastrup :
>
>> Small wonder. I thought our default use of symbols matched our naming
>> rules, but that one's an exception.
>>
>> We can make an exception for convert-ly here, but that's not a
>> satisfactorily final solution.
>>
>> I propose renaming it. Su
Pavel Roskin writes:
> Quoting David Kastrup :
>
>> Small wonder. I thought our default use of symbols matched our naming
>> rules, but that one's an exception.
>>
>> We can make an exception for convert-ly here, but that's not a
>> satisfactorily final solution.
>>
>> I propose renaming it. Su
Quoting David Kastrup :
Small wonder. I thought our default use of symbols matched our naming
rules, but that one's an exception.
We can make an exception for convert-ly here, but that's not a
satisfactorily final solution.
I propose renaming it. Suggestions?
I'm fine with renaming. We ha
Pavel Roskin writes:
> Hello!
>
> I'm using the current lilypond from git. This is what I have before
> the conversion:
>
> \version "2.16.0"
> {
> \override KeySignature #'c0-position = #6
> }
>
> convert-ly turns it into:
>
> \version "2.17.20"
> {
> \override KeySignature.c0-position = #6
Hello!
I'm using the current lilypond from git. This is what I have before
the conversion:
\version "2.16.0"
{
\override KeySignature #'c0-position = #6
}
convert-ly turns it into:
\version "2.17.20"
{
\override KeySignature.c0-position = #6
}
The original file can be processed by lil
12 matches
Mail list logo
