2009/10/29 Frédéric Bron :
> So this would not be the case for voice style (apart from heriting the
> key signature) but for modern-voice it would be OK as the cancellation
> is at Staff context.
OK guys, you got me lost again.
(sigh) OK, let's try this on for size:
http://code.google.com/p/lilyp
> Under this premise, I think it makes sense to inherit the key signature.
> Now if we have _within_ a voice << { xxx } \\ { yyy } >>, what does this
> mean? Since the purpose of "voice" accidental style is to write stuff
> that several different people read, this corresponds to splitting a
> teno
Frédéric Bron writes:
>> Since the \key command still works at the Staff level (both
>> technically in LilyPond and musically, since there's no notation
>> available to specify separate key signatures for separate voices
>> within a stave), I clearly see it as a bug if the Staff key isn't
>> seen
> Since the \key command still works at the Staff level (both technically in
> LilyPond and musically, since there's no notation available to specify
> separate key signatures for separate voices within a stave), I clearly see
> it as a bug if the Staff key isn't seen by each Voice.
What if, at th
On Sun, Oct 25, 2009 at 2:16 PM, David Kastrup wrote:
> Is it necessary to ask for bug report database updates? I filed several
> bug reports to this list which as far as I can tell mostly got ignored,
> to the degree where they did not only not get an answer, but also were
> not filed into the d
> (display local-key-sig) will output the current value if you don't
> want to debug using guile-debugger.ly.
Thanks for that clue.
> The second voice appears, but localKeySignature returns an empty list.
> You can't set a context property on a child context that doesn't exist
> (i.e., the newly
On Mon, Oct 26, 2009 at 02:25:55PM +0100, David Kastrup wrote:
> Graham Percival writes:
>
> > On Mon, Oct 26, 2009 at 01:43:59PM +0100, David Kastrup wrote:
>
> > We *don't* have a response time of a week. Currently the only
> > person who has shown the slightest bit of interest doing this job
Graham Percival writes:
> On Mon, Oct 26, 2009 at 01:43:59PM +0100, David Kastrup wrote:
>> A response time of a week is a sign that the mechanism is not working
>> out.
>
> We *don't* have a response time of a week. Currently the only
> person who has shown the slightest bit of interest doing
On Mon, Oct 26, 2009 at 01:43:59PM +0100, David Kastrup wrote:
> Graham Percival writes:
>
> > It should not be necessary. The Bug Meister should respond within
> > a week, either asking for more information, or informing you of
> > the issue number. (ideally with a direct link, but a simple
>
Graham Percival writes:
> On Sun, Oct 25, 2009 at 02:16:27PM +0100, David Kastrup wrote:
>> Valentin Villenave writes:
>>
>> > 2009/10/24 Frédéric Bron :
>> >> 1. can somebody feed the bug tracker with this bug?
>> >
>> > Sorry, I got lost in the discussion. Can you help me updating the bug
>>
Trevor Daniels wrote:
This behaviour with an accidental style of 'voice is certainly
unexpected! The question is, should the accidental style of
'voice affect just cancellations or should it give every voice an
independent key? If the former, then there is indeed a bug. If the
latter, then t
Frédéric Bron wrote Monday, October 26, 2009 6:30 AM
Here it is not an accidental cancelation, it is just printing the
accidentals from the key!
I consider this as a bug because the new voices should inherit the
key
from the Staff context as it is what's the musician "think". No
musician
>> Here is my first post:
>>
>> In voice style, when switching from one voice to two voices, the
>> program writes too much accidentals.
>> This example demonstrates the problem (2.12.2 and 2.13.6): the second
>> bes should not have a written flat.
>>
>> \relative c'' {
>> #(set-accidental-sty
Frédéric Bron wrote Sunday, October 25, 2009 6:45 PM
Here is my first post:
In voice style, when switching from one voice to two voices, the
program writes too much accidentals.
This example demonstrates the problem (2.12.2 and 2.13.6): the
second
bes should not have a written flat.
\relati
> Sorry, I got lost in the discussion. Can you help me updating the bug report?
Here is my first post:
In voice style, when switching from one voice to two voices, the
program writes too much accidentals.
This example demonstrates the problem (2.12.2 and 2.13.6): the second
bes should not have a
2009/10/24 Frédéric Bron :
> 2. can somebody give me some clue to help me fix the bug, if I can...
> For example, I suspect that the following line returns the wrong key
> signature but how can I print what is in local-key-sig?
> (local-key-sig (ly:context-property context 'localKeySignature))
(d
On Sun, Oct 25, 2009 at 02:16:27PM +0100, David Kastrup wrote:
> Valentin Villenave writes:
>
> > 2009/10/24 Frédéric Bron :
> >> 1. can somebody feed the bug tracker with this bug?
> >
> > Sorry, I got lost in the discussion. Can you help me updating the bug
> > report?
>
> Is it necessary to a
Valentin Villenave writes:
> 2009/10/24 Frédéric Bron :
>> 1. can somebody feed the bug tracker with this bug?
>
> Sorry, I got lost in the discussion. Can you help me updating the bug
> report?
Is it necessary to ask for bug report database updates? I filed several
bug reports to this list whi
2009/10/24 Frédéric Bron :
> 1. can somebody feed the bug tracker with this bug?
Sorry, I got lost in the discussion. Can you help me updating the bug report?
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mai
1. can somebody feed the bug tracker with this bug?
2. can somebody give me some clue to help me fix the bug, if I can...
For example, I suspect that the following line returns the wrong key
signature but how can I print what is in local-key-sig?
(local-key-sig (ly:context-property context 'localKe
2009/10/20 Frédéric Bron :
> The patch below makes it work but breaks default style. I would like
> to replace (ly:context-parent context) by something that always
> returns the current Staff context
You can't do this, since it would break 'piano style.
Regards,
Neil
__
>> Hmm, forget this, since it doesn't make any sense. It seems the new
>> voice behaves as if there's no key signature, so there's still a
>> problem.
The patch below makes it work but breaks default style. I would like
to replace (ly:context-parent context) by something that always
returns the c
> Hmm, forget this, since it doesn't make any sense. It seems the new
> voice behaves as if there's no key signature, so there's still a
> problem.
Yes, because this does not work either:
\relative c'' {
#(set-accidental-style 'voice)
\key f \major
bes1
<<
{ \voiceOne d }
\new Voice { \v
> This snippet has three separate voices, so you'd expect to get a flat
> on the second B flat. Compare with the following, which has two
> voices:
>
> \relative c'' {
> #(set-accidental-style 'voice)
> \key f \major
> bes1
> << {
> \voiceOne
> bes
> }
> \new Voice {
> \vo
2009/10/17 Frédéric Bron :
> In voice style, when switching from one voice to two voices, the
> program writes too much accidentals.
> This example demonstrates the problem (2.12.2 and 2.13.6): the second
> bes should not have a written flat.
>
> \relative c'' {
> #(set-accidental-style 'voi
In voice style, when switching from one voice to two voices, the
program writes too much accidentals.
This example demonstrates the problem (2.12.2 and 2.13.6): the second
bes should not have a written flat.
\relative c'' {
#(set-accidental-style 'voice)
\key f \major
bes1
26 matches
Mail list logo
