automatic accidental style voice: too many written accidentals

[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 'voice)
        \key f \major
        bes1
        << { bes } \\ { g } >>
}

Frédéric


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Neil Puttock]

2009/10/17 Frédéric Bron <frederic.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 'voice)
>        \key f \major
>        bes1
>        << { bes } \\ { g } >>
> }

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 {
      \voiceTwo
      g
  } >>
}

Regards,
Neil


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Neil Puttock]

> 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 {
>      \voiceTwo
>      g
>  } >>
> }
>
> 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.


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Frédéric Bron]

> 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 { \voiceTwo bes }
 >>
}

Frédéric


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Frédéric Bron]

>> 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 current Staff context but the only thing I can do is to
get the string "Staff", not a context Staff object. Any idea?

Frédéric

diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index 324e5aa..b5ad273 100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -1065,8 +1065,8 @@ specifies whether accidentals should be canceled
in different octaves."
                               (ly:warning (_ "Unknown octaveness
type: ~S ") octaveness)
                               (ly:warning (_ "Defaulting to 'any-octave."))
                               #t)))
-        (key-sig (ly:context-property context 'keySignature))
-        (local-key-sig (ly:context-property context 'localKeySignature))
+        (key-sig (ly:context-property (ly:context-parent context)
'keySignature))
+        (local-key-sig (ly:context-property (ly:context-parent
context) 'localKeySignature))
         (notename (ly:pitch-notename pitch))
         (octave (ly:pitch-octave pitch))
         (pitch-handle (cons octave notename))


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Neil Puttock]

2009/10/20 Frédéric Bron <frederic.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


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Frédéric Bron]

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 'localKeySignature))

Frédéric


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Valentin Villenave]

2009/10/24 Frédéric Bron <frederic.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@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[David Kastrup]

Valentin Villenave <v.villenave@...> writes:

> 2009/10/24 Frédéric Bron <frederic.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 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 database.

It is demotivating to invest the work for boiling down a problem into a
small example, write up a good description for it, mail it to the list
and not even get it filed into the bug database, let alone deserve an
answer.

--
David Kastrup



_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Graham Percival-3]

On Sun, Oct 25, 2009 at 02:16:27PM +0100, David Kastrup wrote:

> Valentin Villenave <v.villenave@...> writes:
>
> > 2009/10/24 Frédéric Bron <frederic.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 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 database.

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
"thanks, added as 1234" is also ok)

Of course, as with everything else in open source projects, the
Bug Meister position is a volunteer job, so we take what we can
get.  If anybody thinks they can do a better job than the current
person (including any of my jobs), I would encourage them to offer
to take over the work.  Or at least to work as an assistant.

Cheers,
- Graham


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Neil Puttock]

2009/10/24 Frédéric Bron <frederic.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))

(display local-key-sig) will output the current value if you don't
want to debug using guile-debugger.ly.

Here's the output from your last snippet with a few comments:

((6 . -1/2))

The key signature from keySignature (i.e., 6 = B, -1/2 = FLAT).

(((0 . 6) -1/2 1 . #<Mom 1>) (6 . -1/2))

A B flat in the first bar, plus the key signature.

()

The second voice appears, but localKeySignature returns an empty list.
 The reason for this is that this voice doesn't exist when the key
signature is set, so can't cache its value.  Here's the relevant code
in accidental-engraver.cc (update_local_key_signature ()):

set_context_property_on_children (context (),
                                    ly_symbol2scm ("localKeySignature"),
                                     new_sig);

You can't set a context property on a child context that doesn't exist
(i.e., the newly instantiated voice), so a workaround would be to
explicitly instantiate all the voices at the point the key signature
is set.

\relative c'' {
  #(set-accidental-style 'voice)
  \key f \major
  <<
    { \voiceOne bes1 d }
    \new Voice { \voiceTwo s1 bes }
  >>
}

Regards,
Neil


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Frédéric Bron]

> 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 written flat.

\relative c'' {
       #(set-accidental-style 'voice)
       \key f \major
       bes1
       << { bes } \\ { g } >>
}


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Trevor Daniels]

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.
>
> \relative c'' {
>       #(set-accidental-style 'voice)
>       \key f \major
>       bes1
>       << { bes } \\ { g } >>
> }

This is not a bug.  The two voices in the <<  \\  >> construct are
distinct from the main voice.  This is explained in the Learning
Manual in section 3.2.1.   You have requested accidentals
to be cancelled only within a voice, and the second bes is in
a different voice to the first bes, so it should be given an
accidental.
The default accidental style will behave as you expect as this
cancels accidentals for all voices within a staff.

That probably explains why it wasn't added to the bug tracker
the first time around.

Trevor



_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Frédéric Bron]

>> 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-style 'voice)
>>      \key f \major
>>      bes1
>>      << { bes } \\ { g } >>
>> }
>
> This is not a bug.  The two voices in the <<  \\  >> construct are
> distinct from the main voice.  This is explained in the Learning
> Manual in section 3.2.1.   You have requested accidentals
> to be cancelled only within a voice,

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 will say: "warning this is a new voice, foget what's on the
key!). Look at that new example:

\relative c'' {
      #(set-accidental-style 'voice)
      \key f \major
      a1
      << { b } \\ { g } >>
}

The b is this time "natural" but it has no natural sign. How a
musician can imagine that is is not a b flat?

Frédéric


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Trevor Daniels]

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 will say: "warning this is a new voice, foget what's on
> the
> key!). Look at that new example:
>
> \relative c'' {
>      #(set-accidental-style 'voice)
>      \key f \major
>      a1
>      << { b } \\ { g } >>
> }
>
> The b is this time "natural" but it has no natural sign. How a
> musician can imagine that is is not a b flat?

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 the manual needs to explain it.  At presently coded,
an accidental style of 'voice gives every voice an independent
key, so is this intended?

Seems to me Frédéric is right - this is a bug.  What are others'
views?

Trevor






Frédéric



_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Mats Bengtsson-4]

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 the manual needs to explain it.  At presently coded,
> an accidental style of 'voice gives every voice an independent
> key, so is this intended?
>
> Seems to me Frédéric is right - this is a bug.  What are others'
> views?

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.

    /Mats


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[David Kastrup]

Graham Percival <graham@...> writes:

> On Sun, Oct 25, 2009 at 02:16:27PM +0100, David Kastrup wrote:
>> Valentin Villenave <v.villenave@...> writes:
>>
>> > 2009/10/24 Frédéric Bron <frederic.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 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 database.
>
> 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
> "thanks, added as 1234" is also ok)
>
> Of course, as with everything else in open source projects, the
> Bug Meister position is a volunteer job, so we take what we can
> get.  If anybody thinks they can do a better job than the current
> person (including any of my jobs), I would encourage them to offer
> to take over the work.  Or at least to work as an assistant.

The documentation states:

    If you have discovered a bug which is not listed, please help us by
    sending an input file which demonstrates the problem to the
    bug-lilypond list. Unfortunately there is a strict “no top-posting”
    check on gmane; to avoid this, add

    > I'm not top posting.

    (you must include the > ) to the top of your bug report.

    Please DO NOT add bug reports directly to the bug tracker. Once an
    issue has been added to the tracker, feel free to add more
    information to that report.

It also gives elaborate details about what constitutes a good bug
report.  There is no mention about what happens with bugs on the bug
report list.  A reasonable expectation is that an automatism or
moderation stage will pick up a good bug report within a day.  A
response time of a week is a sign that the mechanism is not working out.
Things like weeding out duplicates can happen at a slower time span.  It
is also possible to put a bug into a database with a state "pending",
"unverified" or similar.  That gives a better impression than a black
hole.

For one of the bugs I reported, a patch has been sent to the list
already by Patrick McCarty.  Neither the bug report nor the patch have
seemingly been registered.  The patch has not been merged or commented
on.

The exclusivity of bug tracker access does not apparently make a good
match with the current workflow of the development crew.

The results are not encouraging to contributors.

--
David Kastrup



_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Graham Percival-3]

On Mon, Oct 26, 2009 at 01:43:59PM +0100, David Kastrup wrote:

> Graham Percival <graham@...> 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
> > "thanks, added as 1234" is also ok)
> >
> > Of course, as with everything else in open source projects, the
> > Bug Meister position is a volunteer job, so we take what we can
> > get.  If anybody thinks they can do a better job than the current
> > person (including any of my jobs), I would encourage them to offer
> > to take over the work.  Or at least to work as an assistant.
>
> 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 this job
does it an average of once every two weeks.

> Things like weeding out duplicates can happen at a
> slower time span.  It is also possible to put a bug into a
> database with a state "pending", "unverified" or similar.  That
> gives a better impression than a black hole.

I do not agree with making the issue tracker open to everybody.
We'll get tons of uninformed users posting non-bugs.

> The results are not encouraging to contributors.

Maybe you didn't notice the above note.  I WOULD ENCOURAGE ANYBODY
TO OFFER TO HELP WITH THE WORK.

Cheers,
- Graham


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[David Kastrup]

Graham Percival <graham@...> 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 this job
> does it an average of once every two weeks.

So the mechanism is not working out.

>> Things like weeding out duplicates can happen at a
>> slower time span.  It is also possible to put a bug into a
>> database with a state "pending", "unverified" or similar.  That
>> gives a better impression than a black hole.
>
> I do not agree with making the issue tracker open to everybody.
> We'll get tons of uninformed users posting non-bugs.

So the idea of the current setup is actually to keep the number of users
posting bug reports down?  Why?  If you feel you should be able to
ignore bug reports by uninformed users, tell your issue tracker view to
omit showing "unverified" issues.

Sure, if everybody does that, the unverified issues will start piling
up, but at some point of time somebody who _does_ see the reports
_might_ engage in a burst of activity sorting them.

The current workflow favors just letting issues get lost on the mailing
list.

>> The results are not encouraging to contributors.
>
> Maybe you didn't notice the above note.  I WOULD ENCOURAGE ANYBODY TO
> OFFER TO HELP WITH THE WORK.

Anybody would be in a better situation to help with the work if it were
visible as "unverified" in the bug tracker, and if it was not reduced to
the personal responsibility of a single person to do something.

It is easier to get people to do a bit of work when they are in the mood
rather than get somebody who volunteers to be _responsible_ until
further notice.

--
David Kastrup


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond

[Graham Percival-3]

On Mon, Oct 26, 2009 at 02:25:55PM +0100, David Kastrup wrote:
> Graham Percival <graham@...> 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
> > does it an average of once every two weeks.
>
> So the mechanism is not working out.

There are many parts of lilypond that are not working out; I don't
see this as one of the most important ones.  It might qualify as
4th or 5th.

> > I do not agree with making the issue tracker open to everybody.
> > We'll get tons of uninformed users posting non-bugs.
>
> So the idea of the current setup is actually to keep the number of users
> posting bug reports down?

We only want decent reports in the tracker, so as to not waste the
limited programmer resources we have.

I don't see this discussion going anywhere.
- Graham


_______________________________________________
bug-lilypond mailing list
bug-lilypond@...
http://lists.gnu.org/mailman/listinfo/bug-lilypond