Re: Odd output

[Keith OHara]

Hello, Jan.
 The article you pointed out earlier, by J-P Coulon, was more useful than 
anything I could find.

 The handbook from the Music Publishers Association of the United States, by 
contrast, has some mistakes -- such as putting the key cancellation /after/ the 
new key signature; we in the US are not that strange, actually.

On Sat, 25 Dec 2010 15:28:01 +0100, Janek Warchoł wrote:

I also went to the library of Fryderyk Chopin University of Music in
Warsaw, but surprisingly they don't have anything much interesting


 The well-engraved music itself should be useful.
 I am a member of the closest University Library (which they allow for low dues 
even though I was never a student there).  They do have engraving textbooks, so 
I read Kurt Stone's book, listed in the appendix to Lilypond's Notation 
Reference.  books.google.com can help to find which libraries have a book, but 
they might not yet include libraries in Warsaw; the closest copy of Kurt 
Stone's book I could could find books.google was in Dresden.
-Keith


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Docs: automatic accidentals (was: Odd output)

[Keith OHara]

On Fri, 10 Dec 2010 01:46:24 -0500 James Lowe  wrote:>



PS To anyone else who knows, if this known issue does apply in this case, 
thenit might be a good idea to not use the word 'chord' as that can mean 
differentthings to different types of musicians - if you see what I mean. We 
couldtherefore edit the documentation?


Good point.  The issue regarding accidentals is not limited to chords.
Also, LilyPond *does* support such chords, most of the time. (The relevant
reg-test is ‘accidental-placement-samepitch.ly’)

Would you consider editing what is below into a doc patch, James?
(I intend to offset my karma deficit with a doc patch for the new Dynamics 
context.)
 ~ Keith

(1) NR 1.5.2 Collision Resolution, known issues :

- There is no support for chords where the same note occurs
- with different accidentals in the same chord.
- In this case, it is recommended to use enharmonic transcription,
- or to use special cluster notation (see Clusters).

+ Chords containing more than two pitches within a staff space, such as
+ 4 , create collisions that are not resolved automatically.
+ Consider using an enharmonic transcription of one or more pitches,
+ or moving some pitches to a temporary separate voice,
+ or using cluster notation (see Clusters)
+ or creating a custom graphic (see
+ 
http://lilypond.org/doc/v2.13/Documentation/snippets/simultaneous-notes#displaying-complex-chords
 ).
+ Note that accidentals in such chords must be specified explicitly (see
+ 
http://lilypond.org/doc/v2.13/Documentation/notation/displaying-pitches#Known-issues-and-warnings-40
 ).

(2) NR 1.1.3 Automatic Accidentals, known issues, is no longer accurate :

- Simultaneous notes are considered to be entered in sequential mode.
- This means that in a chord the accidentals are typeset as if the notes
- in the chord happen one at a time,
- in the order in which they appear in the input file.
- This is a problem when accidentals in a chord depend on each other,
- which does not happen for the default accidental style.

+ Simultaneous notes are not considered in the automatic determination
+ of accidentals; only previous notes and the key signature are considered.
+ This can result in incorrect notation in cases where the same note name
+ occurs simultaneously with different alterations.
= The problem can be solved by manually inserting ! or ?
= for the problematic notes.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

The music is the chorus part from "Three little maids".  My wife says this is 
normally sung as 1st sop, 2nd sop, alto.  All the other notes are stem-up, and 
the performers just sing the top, middle or bottom note as appropriate.  I 
guess the 2 lower notes are stem down for this one note to emphasise the fact 
that it's a # and a nat - either that or the engraver couldn't work out how to 
do it otherwise.  The chorus would just sing the top, middle and bottom note, 
as before, so no confusion.

Truth is, of course, that no non-professional chorus member would ever sing the 
Fnat - the 3 principals are all singing F# with the top sops, so the 2nd sops 
will follow the crowd and sing the #.  Bet all the pros do, too.

--
Phil Holmes


  - Original Message - 
  From: Michael Ellis 
  To: Phil Holmes 
  Cc: Neil Puttock ; James Lowe ; Keith OHara ; lilypond-user@gnu.org 
  Sent: Saturday, December 18, 2010 2:18 PM
  Subject: Re: Odd output


  Thanks Phil, I'm curious about the vocal part.  Why is the stemming different 
than the piano reduction?  As written, it indicates SAA division on the first 
chord and SSS  (no Alto!)  on the second.  This may seem trivial and skilled 
singers will generally do the right thing. OTOH, I've frequently seen 
rehearsals of a 100+ member chorus interrupted when notation less confusing 
than this causes someone to ask which notes s/he should be singing.

  Cheers,
  Mike



  On Sat, Dec 18, 2010 at 6:21 AM, Phil Holmes  wrote:

- Original Message - From: "Neil Puttock" 
To: "James Lowe" 
Cc: "Keith OHara" ; 
    Sent: Friday, December 17, 2010 11:37 PM
Subject: Re: Odd output



On 17 December 2010 23:09, James Lowe  wrote:


  I am not a vocal specialist but just using this one simplistic example of 
C seems erroneous. Isn't the idea of the notes printed at the same moment to 
show that they need to be sung at the same moment if you see what I mean? Yes I 
am sure that a vocalist can make their own mind up, but if that is the 
reasoning then it doesn't matter what we use then does it and you can provide 
instruction accordingly.


I've only seen this notation in piano music (I guess Phil's Mikado
example is part of the piano reduction accompanying the voices),
whereby the melodic line is kept separate from the accompaniment.

Attached is another example from the Mikuli edition of Chopin's
Impromptu in G flat major.

Cheers,
Neil








The beamed version is indeed the piano reduction.  I've put some extra info 
about this in the tracker, but for the record, here's the vocal and piano parts.

--
Phil Holmes


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

Thanks Phil, I'm curious about the vocal part.  Why is the stemming
different than the piano reduction?  As written, it indicates SAA division
on the first chord and SSS  (no Alto!)  on the second.  This may seem
trivial and skilled singers will generally do the right thing. OTOH, I've
frequently seen rehearsals of a 100+ member chorus interrupted when notation
less confusing than this causes someone to ask which notes s/he should be
singing.

Cheers,
Mike


On Sat, Dec 18, 2010 at 6:21 AM, Phil Holmes  wrote:

> - Original Message - From: "Neil Puttock" 
> To: "James Lowe" 
> Cc: "Keith OHara" ; 
> Sent: Friday, December 17, 2010 11:37 PM
> Subject: Re: Odd output
>
>
> On 17 December 2010 23:09, James Lowe  wrote:
>
>  I am not a vocal specialist but just using this one simplistic example of
>> C seems erroneous. Isn't the idea of the notes printed at the same moment to
>> show that they need to be sung at the same moment if you see what I mean?
>> Yes I am sure that a vocalist can make their own mind up, but if that is the
>> reasoning then it doesn't matter what we use then does it and you can
>> provide instruction accordingly.
>>
>
> I've only seen this notation in piano music (I guess Phil's Mikado
> example is part of the piano reduction accompanying the voices),
> whereby the melodic line is kept separate from the accompaniment.
>
> Attached is another example from the Mikuli edition of Chopin's
> Impromptu in G flat major.
>
> Cheers,
> Neil
>
>
>
>
> 
>
>
> The beamed version is indeed the piano reduction.  I've put some extra info
> about this in the tracker, but for the record, here's the vocal and piano
> parts.
>
> --
> Phil Holmes
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

- Original Message - 
From: "Neil Puttock" 

To: "James Lowe" 
Cc: "Keith OHara" ; 
Sent: Friday, December 17, 2010 11:37 PM
Subject: Re: Odd output


On 17 December 2010 23:09, James Lowe  wrote:

I am not a vocal specialist but just using this one simplistic example of 
C seems erroneous. Isn't the idea of the notes printed at the same moment 
to show that they need to be sung at the same moment if you see what I 
mean? Yes I am sure that a vocalist can make their own mind up, but if 
that is the reasoning then it doesn't matter what we use then does it and 
you can provide instruction accordingly.


I've only seen this notation in piano music (I guess Phil's Mikado
example is part of the piano reduction accompanying the voices),
whereby the melodic line is kept separate from the accompaniment.

Attached is another example from the Mikuli edition of Chopin's
Impromptu in G flat major.

Cheers,
Neil






The beamed version is indeed the piano reduction.  I've put some extra info 
about this in the tracker, but for the record, here's the vocal and piano 
parts.


--
Phil Holmes

<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

- Original Message - 
From: "Keith OHara" 

To: ; "Phil Holmes" 
Sent: Friday, December 17, 2010 9:43 PM
Subject: Re: Odd output


On Fri, 17 Dec 2010 04:09:10 -0800, Phil Holmes  
wrote:


The version that Chappell uses in the Mikado is attached.


Nice.
It does break the usual rules about horizontal placement, and about when 
to cancel accidentals in another voice. But, with the beaming to clarify 
the timing and linking the voices, I did not notice any rules were 
broken --until I tried to produce it with Lilypond.


It would be reasonable to ask Lilypond to produce 'A' below on her own, 
and even better if she would offset the notes as in 'B' (which she does do 
for chords in one voice).  Probably a human should decide when to bend the 
rules to produce 'C'.


I think it helps to show the desired behavior in the tracker, and plan to 
put what is below in a comment to 1134, unless somebody either beats me to 
it or has second thoughts.

-Keith


\relative c' { \time 2/8
  << s1*0^wrong
{ fis8 g } \\ { f f } >>
  << s1*0^A
{ fis8 g } \\ { f! f } >>
  << s1*0^B
{ fis8 g } \\
{ \once\override NoteColumn #'force-hshift = #1
  f! f } >>
  << s1*0^C
#(set-accidental-style 'voice)
{ fis8[ g] } \\ {
  s64 f!8*7/8[ f] } >>
}


Good with me.  I've just added the Chappell example to the tracker.


--
Phil Holmes



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Neil Puttock]

On 17 December 2010 23:09, James Lowe  wrote:

> I am not a vocal specialist but just using this one simplistic example of C 
> seems erroneous. Isn't the idea of the notes printed at the same moment to 
> show that they need to be sung at the same moment if you see what I mean? Yes 
> I am sure that a vocalist can make their own mind up, but if that is the 
> reasoning then it doesn't matter what we use then does it and you can provide 
> instruction accordingly.

I've only seen this notation in piano music (I guess Phil's Mikado
example is part of the piano reduction accompanying the voices),
whereby the melodic line is kept separate from the accompaniment.

Attached is another example from the Mikuli edition of Chopin's
Impromptu in G flat major.

Cheers,
Neil
<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

Hi James,
To beam or not to beam should be about rhythmic grouping.  Stem direction
tells which note heads go with which voice.  I think C is better for both
vocalists and pianists. With or without beaming, it's clearer what's going
on, especially with regard to which voices have the sharped or natural
notes.  Slurs, AFAIK, come lower in the hierarchy of which marks have to
make way for what.

 As to the second natural, if given I think it should be a parenthesized
courtesy accidental.  At least that's my understanding of what they tried,
and perhaps failed, to teach me in music school.

Be that as it may, if I were composing for a particular instrument and ran
into this situation I'd be inclined to consult some expert players and ask
them which they find easier to read.

Cheers,
Mike


On Fri, Dec 17, 2010 at 6:09 PM, James Lowe  wrote:

> Hello,
>
>
> -Original Message-
> From: lilypond-user-bounces+james.lowe=datacore@gnu.org on behalf of
> Michael Ellis
> Sent: Fri 12/17/2010 21:50
> To: Keith OHara
> Cc: lilypond-user@gnu.org
> Subject: Re: Odd output
>
> +1 for option C
> Cheers,
> Mike
>
>
> On Fri, Dec 17, 2010 at 4:43 PM, Keith OHara  wrote:
>
> > On Fri, 17 Dec 2010 04:09:10 -0800, Phil Holmes 
> > wrote:
> >
> >>
> >> The version that Chappell uses in the Mikado is attached.
> >>
> >>  Nice.
> > It does break the usual rules about horizontal placement, and about when
> to
> > cancel accidentals in another voice. But, with the beaming to clarify the
> > timing and linking the voices, I did not notice any rules were broken
> > --until I tried to produce it with Lilypond.
> >
> > It would be reasonable to ask Lilypond to produce 'A' below on her own,
> and
> > even better if she would offset the notes as in 'B' (which she does do
> for
> > chords in one voice).  Probably a human should decide when to bend the
> rules
> > to produce 'C'.
> >
> > I think it helps to show the desired behavior in the tracker, and plan to
> > put what is below in a comment to 1134, unless somebody either beats me
> to
> > it or has second thoughts.
> > -Keith
> >
> >
> > \relative c' { \time 2/8
> >  << s1*0^wrong
> >{ fis8 g } \\ { f f } >>
> >  << s1*0^A
> >{ fis8 g } \\ { f! f } >>
> >  << s1*0^B
> >{ fis8 g } \\
> >{ \once\override NoteColumn #'force-hshift = #1
> >  f! f } >>
> >  << s1*0^C
> >#(set-accidental-style 'voice)
> >{ fis8[ g] } \\ {
> >  s64 f!8*7/8[ f] } >>
> > }
>
>
> ---
>
> What about when extra staff notation is needed?
>
> For example if you needed slurs or ties?
>
> Wouldn't A be preferable here? That is having an accidental either side of
> each note is far more clumsy than two accidentals to the left of the note
> then the slur doesn't interfere.
>
> Also what is the purpose in the case of A B or C of the second natural?
> Isn't that implied by standard notation where the note retains the
> 'sharp/flat' for the duration of the measure unless explicitly changed?
>
> Here is a simplified example of what Keith did above to illustrate the
> point.
>
> \relative c' {
> << s1*0
> #(set-accidental-style 'voice)
> { fis8[ g] } \\ { s64 f!8*7/8[ f] }
> >>
> << s1*0
> #(set-accidental-style 'voice)
> { fis!8([ g] } \\ { s64 f!8*7/8~[ f] }
> >><< s1*0
> #(set-accidental-style 'voice)
> { fis!8[ g]) } \\ { s64 f!8*7/8[ f] }
> >><< s1*0
> #(set-accidental-style 'voice)
> { fis!8[ g] } \\ { s64 f!8*7/8)[ f] }
> >>
> }
>
> I am not a vocal specialist but just using this one simplistic example of C
> seems erroneous. Isn't the idea of the notes printed at the same moment to
> show that they need to be sung at the same moment if you see what I mean?
> Yes I am sure that a vocalist can make their own mind up, but if that is the
> reasoning then it doesn't matter what we use then does it and you can
> provide instruction accordingly.
>
> I don't think that the beaming clarifies anything at all personally.
>
> Just my tuppence worth.
>
> james
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Odd output

[James Lowe]

Hello,


-Original Message-
From: lilypond-user-bounces+james.lowe=datacore@gnu.org on behalf of 
Michael Ellis
Sent: Fri 12/17/2010 21:50
To: Keith OHara
Cc: lilypond-user@gnu.org
Subject: Re: Odd output
 
+1 for option C
Cheers,
Mike


On Fri, Dec 17, 2010 at 4:43 PM, Keith OHara  wrote:

> On Fri, 17 Dec 2010 04:09:10 -0800, Phil Holmes 
> wrote:
>
>>
>> The version that Chappell uses in the Mikado is attached.
>>
>>  Nice.
> It does break the usual rules about horizontal placement, and about when to
> cancel accidentals in another voice. But, with the beaming to clarify the
> timing and linking the voices, I did not notice any rules were broken
> --until I tried to produce it with Lilypond.
>
> It would be reasonable to ask Lilypond to produce 'A' below on her own, and
> even better if she would offset the notes as in 'B' (which she does do for
> chords in one voice).  Probably a human should decide when to bend the rules
> to produce 'C'.
>
> I think it helps to show the desired behavior in the tracker, and plan to
> put what is below in a comment to 1134, unless somebody either beats me to
> it or has second thoughts.
> -Keith
>
>
> \relative c' { \time 2/8
>  << s1*0^wrong
>{ fis8 g } \\ { f f } >>
>  << s1*0^A
>{ fis8 g } \\ { f! f } >>
>  << s1*0^B
>{ fis8 g } \\
>{ \once\override NoteColumn #'force-hshift = #1
>  f! f } >>
>  << s1*0^C
>#(set-accidental-style 'voice)
>{ fis8[ g] } \\ {
>  s64 f!8*7/8[ f] } >>
> }


---

What about when extra staff notation is needed?

For example if you needed slurs or ties?

Wouldn't A be preferable here? That is having an accidental either side of each 
note is far more clumsy than two accidentals to the left of the note then the 
slur doesn't interfere.

Also what is the purpose in the case of A B or C of the second natural? Isn't 
that implied by standard notation where the note retains the 'sharp/flat' for 
the duration of the measure unless explicitly changed?

Here is a simplified example of what Keith did above to illustrate the point.

\relative c' {
<< s1*0
#(set-accidental-style 'voice)
{ fis8[ g] } \\ { s64 f!8*7/8[ f] } 
>>
<< s1*0
#(set-accidental-style 'voice)
{ fis!8([ g] } \\ { s64 f!8*7/8~[ f] } 
>><< s1*0
#(set-accidental-style 'voice)
{ fis!8[ g]) } \\ { s64 f!8*7/8[ f] } 
>><< s1*0
#(set-accidental-style 'voice)
{ fis!8[ g] } \\ { s64 f!8*7/8)[ f] } 
>>
}

I am not a vocal specialist but just using this one simplistic example of C 
seems erroneous. Isn't the idea of the notes printed at the same moment to show 
that they need to be sung at the same moment if you see what I mean? Yes I am 
sure that a vocalist can make their own mind up, but if that is the reasoning 
then it doesn't matter what we use then does it and you can provide instruction 
accordingly.

I don't think that the beaming clarifies anything at all personally.

Just my tuppence worth.

james


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

+1 for option C
Cheers,
Mike


On Fri, Dec 17, 2010 at 4:43 PM, Keith OHara  wrote:

> On Fri, 17 Dec 2010 04:09:10 -0800, Phil Holmes 
> wrote:
>
>>
>> The version that Chappell uses in the Mikado is attached.
>>
>>  Nice.
> It does break the usual rules about horizontal placement, and about when to
> cancel accidentals in another voice. But, with the beaming to clarify the
> timing and linking the voices, I did not notice any rules were broken
> --until I tried to produce it with Lilypond.
>
> It would be reasonable to ask Lilypond to produce 'A' below on her own, and
> even better if she would offset the notes as in 'B' (which she does do for
> chords in one voice).  Probably a human should decide when to bend the rules
> to produce 'C'.
>
> I think it helps to show the desired behavior in the tracker, and plan to
> put what is below in a comment to 1134, unless somebody either beats me to
> it or has second thoughts.
> -Keith
>
>
> \relative c' { \time 2/8
>  << s1*0^wrong
>{ fis8 g } \\ { f f } >>
>  << s1*0^A
>{ fis8 g } \\ { f! f } >>
>  << s1*0^B
>{ fis8 g } \\
>{ \once\override NoteColumn #'force-hshift = #1
>  f! f } >>
>  << s1*0^C
>#(set-accidental-style 'voice)
>{ fis8[ g] } \\ {
>  s64 f!8*7/8[ f] } >>
> }
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Keith OHara]

On Fri, 17 Dec 2010 04:09:10 -0800, Phil Holmes  wrote:


The version that Chappell uses in the Mikado is attached.


Nice.
It does break the usual rules about horizontal placement, and about when to 
cancel accidentals in another voice. But, with the beaming to clarify the 
timing and linking the voices, I did not notice any rules were broken --until I 
tried to produce it with Lilypond.

It would be reasonable to ask Lilypond to produce 'A' below on her own, and 
even better if she would offset the notes as in 'B' (which she does do for 
chords in one voice).  Probably a human should decide when to bend the rules to 
produce 'C'.

I think it helps to show the desired behavior in the tracker, and plan to put 
what is below in a comment to 1134, unless somebody either beats me to it or 
has second thoughts.
-Keith


\relative c' { \time 2/8
  << s1*0^wrong
{ fis8 g } \\ { f f } >>
  << s1*0^A
{ fis8 g } \\ { f! f } >>
  << s1*0^B
{ fis8 g } \\
{ \once\override NoteColumn #'force-hshift = #1
  f! f } >>
  << s1*0^C
#(set-accidental-style 'voice)
{ fis8[ g] } \\ {
  s64 f!8*7/8[ f] } >>
}<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

- Original Message - 
From: "Keith OHara" 

To: 
Sent: Friday, December 17, 2010 9:33 AM
Subject: Re: Odd output



Phil Holmes  philholmes.net> writes:


From: "Marco Correia"  gmail.com>
>
> \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { f'4 } >>
>>>

This was one of the first issues I raised, in June this year.  I think it
was my first bug report:

http://code.google.com/p/lilypond/issues/detail?id=1134



Lilypond's _only_ failure here is missing that the both notes need
accidentals, because she compares only with previous notes, not 
simultaneous
notes. (She does compare all voices.) If we force an explicit accidental 
with

'!'
 << { fis'4 } \\ {f'!4} >>
then Lilypond prints both a sharp and a natural -- with the natural always
closer to the notehead so it is distinct from an extra natural that just
cancels an earlier accidental.

 Marco, and Phil, is sharp-natural-notehead the desired notation for this
situation?  (I prefer it to the double-stem method, which I have seen only 
in
Gardner Read's textbook, the "Displaying complex chords" snippet, and 
nowhere

else.)


The version that Chappell uses in the Mikado is attached.


--
Phil Holmes

<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Keith OHara]

Phil Holmes  philholmes.net> writes:
> 
> From: "Marco Correia"  gmail.com>
> >
> > \include "english.ly"
> > {
> > \clef treble
> > \time 4/4
> > <<
> > { fs'4 }
> > \\
> > { f'4 } >>
> >>>
>
> This was one of the first issues I raised, in June this year.  I think it 
> was my first bug report:
> 
> http://code.google.com/p/lilypond/issues/detail?id=1134
> 

 Lilypond's _only_ failure here is missing that the both notes need 
accidentals, because she compares only with previous notes, not simultaneous 
notes. (She does compare all voices.) If we force an explicit accidental with 
'!' 
  << { fis'4 } \\ {f'!4} >>
then Lilypond prints both a sharp and a natural -- with the natural always 
closer to the notehead so it is distinct from an extra natural that just 
cancels an earlier accidental.  

  Marco, and Phil, is sharp-natural-notehead the desired notation for this 
situation?  (I prefer it to the double-stem method, which I have seen only in 
Gardner Read's textbook, the "Displaying complex chords" snippet, and nowhere 
else.)

  For your computer-generated music, you might want to generate a forcing '!' 
whenever two notes of the same pitch name are produced at the same musical 
moment.  You might also consider "set-accidental-style 'dodecaphonic" and/or 
extraNatura=#f (see the manual for details). 

  Since you asked about Scheme, the decision on what accidentals are required 
is done by 'check-pitch-against-signature' in the file ../usr/share/lilypond/
current/scm/music-functions.scm which is installed with LilyPond.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: issue classification was: Odd output

[Werner LEMBERG]

> FWIW, Finale 2010 *does* support this if you put the notes in
> separate layers (voices), add a courtesy accidental to the natural
> note, and fiddle with the Accidental Mover and Note Position gui
> tools.  It doesn't do the right thing by default, though. Image
> attached.

Well, *manually* you can do exactly the same with LilyPond...  The
request is, as far as I understand, to make LilyPond handle this
automatically.


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: issue classification was: Odd output

[Michael Ellis]

FWIW, Finale 2010 *does* support this if you put the notes in separate
layers (voices), add a courtesy accidental to the natural note, and fiddle
with the Accidental Mover and Note Position gui tools.  It doesn't do the
right thing by default, though. Image attached.

So if pride in LilyPond's capabilities is a motivator, this may help bump
the issue's priority :-)

Cheers,
Mike


On Sun, Dec 12, 2010 at 3:19 AM, Jan Warchoł <
lemniskata.bernoulli...@gmail.com> wrote:

> Hi all,
>
> 2010/12/10 Marco Correia :
> > Thanks!
> >
> > I can't believe that this is seen as a low priority enhancement...! This
> > completely renders lilypond unusable for the task I need it, which is to
> serve
> > as a printer for computer generated music. The output is not ugly - it is
> > plain wrong!
>
> I agree with Marco, in my opinion this issue should be medium priority
> defect.
> Or even a high priority one (i took a look at current high priority
> defects and they don't look much grave than this one).
>
> Actually, i'd like to discuss issue classification in general, because
> in my opinion it could use a lot of improvement. Should i do this now
> on developers list, or maybe wait until 2.14 is out? Or wait for GOP?
> I don't want to disrupt current development process too much.
>
> cheers,
> Janek
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: issue classification was: Odd output

[Phil Holmes]

- Original Message - 
From: "Jan Warchoł" 

To: 
Cc: "Lilypond Bugreports" ; 
Sent: Sunday, December 12, 2010 8:19 AM
Subject: issue classification was: Odd output



Hi all,

2010/12/10 Marco Correia :

Thanks!

I can't believe that this is seen as a low priority enhancement...! This
completely renders lilypond unusable for the task I need it, which is to 
serve

as a printer for computer generated music. The output is not ugly - it is
plain wrong!


I agree with Marco, in my opinion this issue should be medium priority 
defect.

Or even a high priority one (i took a look at current high priority
defects and they don't look much grave than this one).

Actually, i'd like to discuss issue classification in general, because
in my opinion it could use a lot of improvement. Should i do this now
on developers list, or maybe wait until 2.14 is out? Or wait for GOP?
I don't want to disrupt current development process too much.

cheers,
Janek


As bug-meister, I'd think that classification is now my baby.  I'm not a 
developer, so discussing it doesn't slow development, apart from some noise 
on -devel.  The current classification is at:


http://lilypond.org/doc/v2.13/Documentation/contributor/issue-classification

Happy to have some suggestions for improvements.

The downside is that if we do change it, the right-and-proper thing to do 
would be to check the classification of all open issues.  Not sure that 
would happen short term :-(


--
Phil Holmes


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

issue classification was: Odd output

[Jan Warchoł]

Hi all,

2010/12/10 Marco Correia :
> Thanks!
>
> I can't believe that this is seen as a low priority enhancement...! This
> completely renders lilypond unusable for the task I need it, which is to serve
> as a printer for computer generated music. The output is not ugly - it is
> plain wrong!

I agree with Marco, in my opinion this issue should be medium priority defect.
Or even a high priority one (i took a look at current high priority
defects and they don't look much grave than this one).

Actually, i'd like to discuss issue classification in general, because
in my opinion it could use a lot of improvement. Should i do this now
on developers list, or maybe wait until 2.14 is out? Or wait for GOP?
I don't want to disrupt current development process too much.

cheers,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Carl Sorensen]

On 12/10/10 8:27 PM, "Marco Correia"  wrote:

> Hi,
> 
> I didn't want to sound rude or anything. I just want to make a point that I do
> not consider this as a minor improvement since:
> 
> 1. The output is not aestetically wrong, it is definitely readable differently
> from what is specified in the lilypond source.
> 
> 2. I think you should not assume the user will write a musically (logicaly)
> consistent piece in order to display the notes correctly.
> 
> 3. It can happen in a real world exercise, for example when displaying music
> which is obtained by a computer program.

It's not rude for you to question our issue classification.  Let me explain
it to you.

We have lots of issues, and few developers.  So the issues that are worked
on come in two kinds: critical issues and developers' favorite issues.

The issue classification scheme is described in the LilyPond Contributor's
Guide.



Critical issues are those that used to work in lilypond but don't now, or
those that cause lilypond to crash.

> 
> I don't know anything about the lilypond internals. I'm just a 1 week newbie,
> who just stumbled across this problem on one of the first attempts at
> lilypond.
> 
> Lilypond is written in Scheme, is that right?

LilyPond is written in a mix of C++ and Scheme.

> For someone who doesn't know
> this language, but has a strong background on computer science in general,
> would you think that he could hack into the lilypond algorithm for displaying
> the accidentals and make something better out of it?

If you have a strong background in computer science, you can definitely
contribute to LilyPond, whether or not you know Scheme.  Scheme is not that
hard to learn, and there are good references for it.

> Is there any
> documentation on the subject available?

The documentation on hacking into LilyPond is available in the Contributor's
Guide.  It's not complete, but it's the best we've got.

> 
> I think the idea behind lilypond is great, and from the examples I've seen it
> looks like it works very well for most cases. I'm willing to try to help to
> correct this issue, with your help, if you think that it is feasible.

We'll be glad to offer help.  Accidentals are created by the
Accidental_engraver, which is written in C++.  You can read a top-level
description of the Accidental_engraver in the Internals Reference.  You can
find the source code in lily/accidental-engraver.cc

> 
> Anyway, thanks for making your effort available for free. I am also an open
> souce developer and, believe me, I do value these contributions.

We'd love to have you solve that problem!  We'll provide whatever help we
can.

Thanks,

Carl Sorensen

P.S. We like to get replies in the body of the email, rather than on the top
of the email.  We have a "no top-posting" policy on the lilypond mailing
lists.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Marco Correia]

Hi,

I didn't want to sound rude or anything. I just want to make a point that I do 
not consider this as a minor improvement since:

1. The output is not aestetically wrong, it is definitely readable differently 
from what is specified in the lilypond source.

2. I think you should not assume the user will write a musically (logicaly) 
consistent piece in order to display the notes correctly.

3. It can happen in a real world exercise, for example when displaying music 
which is obtained by a computer program.

I don't know anything about the lilypond internals. I'm just a 1 week newbie, 
who just stumbled across this problem on one of the first attempts at 
lilypond.

Lilypond is written in Scheme, is that right? For someone who doesn't know 
this language, but has a strong background on computer science in general, 
would you think that he could hack into the lilypond algorithm for displaying 
the accidentals and make something better out of it? Is there any 
documentation on the subject available?

I think the idea behind lilypond is great, and from the examples I've seen it 
looks like it works very well for most cases. I'm willing to try to help to 
correct this issue, with your help, if you think that it is feasible.

Anyway, thanks for making your effort available for free. I am also an open 
souce developer and, believe me, I do value these contributions.

Thanks!
Marco


On Friday 10 December 2010, Phil Holmes wrote:
> Please reply to the user group as well.
> 
> As is often pointed out, it's free software and the fixes depend on who is
> working for nothing on the code.
> 
> I wouldn't think it would crop up frequently.
> 
> I made a workaround with a combination of forcing the accidentals to be
> displayed, and then using force-hshift and extra-offset and a few other
> tweaks to make it work.
> 
> My example is pretty complicated, because I also autogenerate the code, but
> you're welcome to a copy if you want.
> 
> --
> Phil Holmes
> 
> 
> - Original Message -
> From: "Marco Correia" 
> To: "Phil Holmes" 
> Sent: Friday, December 10, 2010 10:29 AM
> Subject: Re: Odd output
> 
> > Thanks!
> > 
> > I can't believe that this is seen as a low priority enhancement...! This
> > completely renders lilypond unusable for the task I need it, which is to
> > serve
> > as a printer for computer generated music. The output is not ugly - it is
> > plain wrong!
> > 
> > Why doesn't the accidental_engraver looks into other voices as well?
> > 
> > Maybe I can workaround it by doing an extra pass before writing the
> > lilypond
> > code to check if this kind of problem may occur... But now I wonder what
> > other
> > kind of potential problems may occur with this accidental_engraver
> > algorithm...
> > 
> > Anyway, I just wanted to say that I think this problem deserves more
> > consideration.
> > 
> > Thank you!
> > Marco
> > 
> > On Friday 10 December 2010, you wrote:
> >> - Original Message -
> >> From: "Marco Correia" 
> >> To: 
> >> Sent: Friday, December 10, 2010 12:35 AM
> >> Subject: Odd output
> >> 
> >> > Hi,
> >> > 
> >> > I just started using lilypond, so it is very possible that I'm making
> >> > some mistake.
> >> > 
> >> > When compiling this example:
> >> > 
> >> > \include "english.ly"
> >> > {
> >> > \clef treble
> >> > \time 4/4
> >> > <<
> >> > { fs'4 }
> >> > \\
> >> > { f'4 }
> >> > 
> >> > }
> >> > 
> >> > I see two notes on fs (occupying the same position but with stems up
> >> > and
> >> > down). There is no indication that f is there.
> >> > 
> >> > Is this supposed to/ how do I fix it?
> >> > 
> >> > Thanks!
> >> > Marco
> >> 
> >> This was one of the first issues I raised, in June this year.  I think
> >> it was my first bug report:
> >> 
> >> http://code.google.com/p/lilypond/issues/detail?id=1134
> >> 
> >> 
> >> --
> >> Phil Holmes


-- 
Marco Correia 

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[David Kastrup]

Michael Ellis  writes:

> Yes! Spelling does count because poorly spelled music is much harder
> to read. I'm somewhat less convinced regarding sonic differences on
> untempered instruments because the matter is more complicated than
> that, e.g G# as the leading tone to A is different from G# as the
> third of E. In practice, it comes down to the performer's ear to make
> those distinctions.

I have asked someone about a "quint register" in a virtual accordion,
and while I have not heard it myself, his opinion is that this register
is a _tempered_ fifth above the normal sound (namely, "in scale").

I tend to believe him, even though it would imply that someone had no
clue about what he is supposed to be doing (or did not have the
material/samples to do this properly).  I've long ago come to the
painful realization that it is a mistake to rule out that possibility.

I am not sure that a performer with a manually-pitchable instrument will
overly obey enharmonic information against his own ear.  Writing
functionally, however, will help with recognizing chord patterns.  There
are curious things like keyboards (cembali, I think) with split black
keys that can be tuned to make use of that distinction, but I would
suppose that the players of such rare beasts are versed enough to apply
the right choice even against notation.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[James Bailey]

I'd say it's up to more than just the performer's ear to make the distinction. 
If you spend much time listening to music where enharmonic notes are rounded to 
a median, the ability of the listener/performer to distinguish the difference 
diminishes. So the audience is just as at fault at not hearing the difference 
between our enharmonic notes as the performers.

 
On Dec 10, 2010, at 7:40 PM, Michael Ellis wrote:

> Yes! Spelling does count because poorly spelled music is much harder to read. 
> I'm somewhat less convinced regarding sonic differences on untempered 
> instruments because the matter is more complicated than that, e.g G# as the 
> leading tone to A is different from G# as the third of E. In practice, it 
> comes down to the performer's ear to make those distinctions.  So, for me at 
> least, readability is the primary consideration.   For those who care about 
> such things, here's a link to the best article I've seen on the subject. It's 
> by Bert Ligon, head of the Jazz Studies department at the University of South 
> CarolinaCollege of Music.
> 
> MUSIC SPELL CHECK? PURPOSEFUL ACCIDENTALS
> 
> Cheers,
> Mike
> 
> 
> On Fri, Dec 10, 2010 at 12:55 PM, James Bailey  
> wrote:
> Because spelling counts! D# and E♭may sound the same (on a tempered 
> instrument) but they are two very different notes. And an performer playing 
> an instrument that can distinguish between the two, should.
> 
> 
> On Dec 10, 2010, at 6:18 PM, Michael Ellis wrote:
> 
>> Why not set one of the notes to a different enharmonic pitch?  It's 
>> certainly much kinder to the musician who's trying to play the composition.
>> 
>>  \include "english.ly"
>> {
>> \clef treble
>> \time 4/4
>> <<
>> { fs'4 }
>> \\
>> { es'4 }
>> >>
>> }
>> 
>> 
>> Cheers,
>> Mike
>> 
>> 
>> On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:
>> Please reply to the user group as well.
>> 
>> As is often pointed out, it's free software and the fixes depend on who is 
>> working for nothing on the code.
>> 
>> I wouldn't think it would crop up frequently.
>> 
>> I made a workaround with a combination of forcing the accidentals to be 
>> displayed, and then using force-hshift and extra-offset and a few other 
>> tweaks to make it work.
>> 
>> My example is pretty complicated, because I also autogenerate the code, but 
>> you're welcome to a copy if you want.
>> 
>> --
>> Phil Holmes
>> 
>> 
>> 
>> - Original Message - From: "Marco Correia" 
>> 
>> To: "Phil Holmes" 
>> Sent: Friday, December 10, 2010 10:29 AM
>> Subject: Re: Odd output
>> 
>> 
>> Thanks!
>> 
>> I can't believe that this is seen as a low priority enhancement...! This
>> completely renders lilypond unusable for the task I need it, which is to 
>> serve
>> as a printer for computer generated music. The output is not ugly - it is
>> plain wrong!
>> 
>> Why doesn't the accidental_engraver looks into other voices as well?
>> 
>> Maybe I can workaround it by doing an extra pass before writing the lilypond
>> code to check if this kind of problem may occur... But now I wonder what 
>> other
>> kind of potential problems may occur with this accidental_engraver
>> algorithm...
>> 
>> Anyway, I just wanted to say that I think this problem deserves more
>> consideration.
>> 
>> Thank you!
>> Marco
>> 
>> On Friday 10 December 2010, you wrote:
>> - Original Message -
>> From: "Marco Correia" 
>> To: 
>> Sent: Friday, December 10, 2010 12:35 AM
>> Subject: Odd output
>> 
>> > Hi,
>> >
>> > I just started using lilypond, so it is very possible that I'm making
>> > some mistake.
>> >
>> > When compiling this example:
>> >
>> > \include "english.ly"
>> > {
>> > \clef treble
>> > \time 4/4
>> > <<
>> > { fs'4 }
>> > \\
>> > { f'4 }
>> >
>> > }
>> >
>> > I see two notes on fs (occupying the same position but with stems up > and
>> > down). There is no indication that f is there.
>> >
>> > Is this supposed to/ how do I fix it?
>> >
>> > Thanks!
>> > Marco
>> 
>> This was one of the first issues I raised, in June this year.  I think it
>> was my first bug report:
>> 
>> http://code.google.com/p/lilypond/issues/detail?id=1134
>> 
>> 
>> --
>> Phil Holmes
>> 
>> 
>> -- 
>> Marco Correia 
>> 
>> 
>> 
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>> 
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

Yes! Spelling does count because poorly spelled music is much harder to
read. I'm somewhat less convinced regarding sonic differences on untempered
instruments because the matter is more complicated than that, e.g G# as the
leading tone to A is different from G# as the third of E. In practice, it
comes down to the performer's ear to make those distinctions.  So, for me at
least, readability is the primary consideration.   For those who care about
such things, here's a link to the best article I've seen on the subject.
It's by Bert Ligon, head of the Jazz Studies department at the University of
South CarolinaCollege of Music.

MUSIC SPELL CHECK? PURPOSEFUL
ACCIDENTALS<https://docs.google.com/viewer?url=http%3A%2F%2Fwww.music.sc.edu%2Fea%2FJazz%2FPURPOSEFULACCIDENTALS3.pdf>

Cheers,
Mike


On Fri, Dec 10, 2010 at 12:55 PM, James Bailey
wrote:

> Because spelling counts! D# and E♭may* sound* the same (on a tempered
> instrument) but they are two very different notes. And an performer playing
> an instrument that can distinguish between the two, should.
>
>
> On Dec 10, 2010, at 6:18 PM, Michael Ellis wrote:
>
> Why not set one of the notes to a different enharmonic pitch?  It's
> certainly much kinder to the musician who's trying to play the composition.
>
>  \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { es'4 }
> >>
> }
>
>
> Cheers,
> Mike
>
>
> On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:
>
>> Please reply to the user group as well.
>>
>> As is often pointed out, it's free software and the fixes depend on who is
>> working for nothing on the code.
>>
>> I wouldn't think it would crop up frequently.
>>
>> I made a workaround with a combination of forcing the accidentals to be
>> displayed, and then using force-hshift and extra-offset and a few other
>> tweaks to make it work.
>>
>> My example is pretty complicated, because I also autogenerate the code,
>> but you're welcome to a copy if you want.
>>
>> --
>> Phil Holmes
>>
>>
>>
>> - Original Message - From: "Marco Correia" <
>> marco.v.corr...@gmail.com>
>> To: "Phil Holmes" 
>> Sent: Friday, December 10, 2010 10:29 AM
>> Subject: Re: Odd output
>>
>>
>>  Thanks!
>>>
>>> I can't believe that this is seen as a low priority enhancement...! This
>>> completely renders lilypond unusable for the task I need it, which is to
>>> serve
>>> as a printer for computer generated music. The output is not ugly - it is
>>> plain wrong!
>>>
>>> Why doesn't the accidental_engraver looks into other voices as well?
>>>
>>> Maybe I can workaround it by doing an extra pass before writing the
>>> lilypond
>>> code to check if this kind of problem may occur... But now I wonder what
>>> other
>>> kind of potential problems may occur with this accidental_engraver
>>> algorithm...
>>>
>>> Anyway, I just wanted to say that I think this problem deserves more
>>> consideration.
>>>
>>> Thank you!
>>> Marco
>>>
>>> On Friday 10 December 2010, you wrote:
>>>
>>>> - Original Message -
>>>> From: "Marco Correia" 
>>>> To: 
>>>> Sent: Friday, December 10, 2010 12:35 AM
>>>> Subject: Odd output
>>>>
>>>> > Hi,
>>>> >
>>>> > I just started using lilypond, so it is very possible that I'm making
>>>> > some mistake.
>>>> >
>>>> > When compiling this example:
>>>> >
>>>> > \include "english.ly"
>>>> > {
>>>> > \clef treble
>>>> > \time 4/4
>>>> > <<
>>>> > { fs'4 }
>>>> > \\
>>>> > { f'4 }
>>>> >
>>>> > }
>>>> >
>>>> > I see two notes on fs (occupying the same position but with stems up >
>>>> and
>>>> > down). There is no indication that f is there.
>>>> >
>>>> > Is this supposed to/ how do I fix it?
>>>> >
>>>> > Thanks!
>>>> > Marco
>>>>
>>>> This was one of the first issues I raised, in June this year.  I think
>>>> it
>>>> was my first bug report:
>>>>
>>>> http://code.google.com/p/lilypond/issues/detail?id=1134
>>>>
>>>>
>>>> --
>>>> Phil Holmes
>>>>
>>>
>>>
>>> --
>>> Marco Correia 
>>>
>>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

Your friend is absolutely correct for that particular case.  Sullivan chose
the lesser of two evils. Misspelling the dominant chord would have been
confusing to the pianist and spelling the vocal line as A G Gb G would have
looked weird to the singer.  My response was directed to the original
example which doesn't give enough context to justify the F#/Fnat relation
musically.

Cheers,
Mike


On Fri, Dec 10, 2010 at 12:36 PM, Phil Holmes  wrote:

>  As I replied in my direct reply - because it's not right.  I asked a
> friend who teaches music about the Mikado problem I had and he said:
>
> "Key- C major
>
> Bass note pedals - C-G C-G etc.
>
> Chord in Bar 1 G7 (G B D Fnat = dominant 7th); Chord in Bar 2 C major (CEG)
>
> Each bar has a melody which uses AGF# G with the F# as a chromatical
> altered
> note (lower auxiliary between the 2 Gs) and therefore clashes (to create
> interest) with both chords.
>
> Each sounds fine on their own but looks illogical as a whole.
>
> If you can convince LilyPond that the accidentals are in different voices
> in
> the piano part then I would hope it would work.   You could but shouldn't
> use a Gb not a F# as the first chordsis a G chord."
>
> Note his final comment - could use a Gb but shouldn't.
>
> --
> Phil Holmes
>
>
>
> - Original Message -
> *From:* Michael Ellis 
> *To:* LilyPond User Group 
> *Sent:* Friday, December 10, 2010 5:18 PM
> *Subject:* Re: Odd output
>
> Why not set one of the notes to a different enharmonic pitch?  It's
> certainly much kinder to the musician who's trying to play the composition.
>
>  \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { es'4 }
> >>
> }
>
>
> Cheers,
> Mike
>
>
> On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:
>
>> Please reply to the user group as well.
>>
>> As is often pointed out, it's free software and the fixes depend on who is
>> working for nothing on the code.
>>
>> I wouldn't think it would crop up frequently.
>>
>> I made a workaround with a combination of forcing the accidentals to be
>> displayed, and then using force-hshift and extra-offset and a few other
>> tweaks to make it work.
>>
>> My example is pretty complicated, because I also autogenerate the code,
>> but you're welcome to a copy if you want.
>>
>> --
>> Phil Holmes
>>
>>
>>
>> - Original Message - From: "Marco Correia" <
>> marco.v.corr...@gmail.com>
>> To: "Phil Holmes" 
>> Sent: Friday, December 10, 2010 10:29 AM
>> Subject: Re: Odd output
>>
>>
>>  Thanks!
>>>
>>> I can't believe that this is seen as a low priority enhancement...! This
>>> completely renders lilypond unusable for the task I need it, which is to
>>> serve
>>> as a printer for computer generated music. The output is not ugly - it is
>>> plain wrong!
>>>
>>> Why doesn't the accidental_engraver looks into other voices as well?
>>>
>>> Maybe I can workaround it by doing an extra pass before writing the
>>> lilypond
>>> code to check if this kind of problem may occur... But now I wonder what
>>> other
>>> kind of potential problems may occur with this accidental_engraver
>>> algorithm...
>>>
>>> Anyway, I just wanted to say that I think this problem deserves more
>>> consideration.
>>>
>>> Thank you!
>>> Marco
>>>
>>> On Friday 10 December 2010, you wrote:
>>>
>>>> - Original Message -
>>>> From: "Marco Correia" 
>>>> To: 
>>>> Sent: Friday, December 10, 2010 12:35 AM
>>>> Subject: Odd output
>>>>
>>>> > Hi,
>>>> >
>>>> > I just started using lilypond, so it is very possible that I'm making
>>>> > some mistake.
>>>> >
>>>> > When compiling this example:
>>>> >
>>>> > \include "english.ly"
>>>> > {
>>>> > \clef treble
>>>> > \time 4/4
>>>> > <<
>>>> > { fs'4 }
>>>> > \\
>>>> > { f'4 }
>>>> >
>>>> > }
>>>> >
>>>> > I see two notes on fs (occupying the same position but with stems up >
>>>> and
>>>> > down). There is no indication that f is there.
>>>> >
>>>> > Is this supposed to/ how do I fix it?
>>>> >
>>>> > Thanks!
>>>> > Marco
>>>>
>>>> This was one of the first issues I raised, in June this year.  I think
>>>> it
>>>> was my first bug report:
>>>>
>>>> http://code.google.com/p/lilypond/issues/detail?id=1134
>>>>
>>>>
>>>> --
>>>> Phil Holmes
>>>>
>>>
>>>
>>> --
>>> Marco Correia 
>>>
>>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
>  --
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[James Bailey]

Because spelling counts! D# and E♭may sound the same (on a tempered instrument) 
but they are two very different notes. And an performer playing an instrument 
that can distinguish between the two, should.


On Dec 10, 2010, at 6:18 PM, Michael Ellis wrote:

> Why not set one of the notes to a different enharmonic pitch?  It's certainly 
> much kinder to the musician who's trying to play the composition.
> 
>  \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { es'4 }
> >>
> }
> 
> 
> Cheers,
> Mike
> 
> 
> On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:
> Please reply to the user group as well.
> 
> As is often pointed out, it's free software and the fixes depend on who is 
> working for nothing on the code.
> 
> I wouldn't think it would crop up frequently.
> 
> I made a workaround with a combination of forcing the accidentals to be 
> displayed, and then using force-hshift and extra-offset and a few other 
> tweaks to make it work.
> 
> My example is pretty complicated, because I also autogenerate the code, but 
> you're welcome to a copy if you want.
> 
> --
> Phil Holmes
> 
> 
> 
> - Original Message - From: "Marco Correia" 
> To: "Phil Holmes" 
> Sent: Friday, December 10, 2010 10:29 AM
> Subject: Re: Odd output
> 
> 
> Thanks!
> 
> I can't believe that this is seen as a low priority enhancement...! This
> completely renders lilypond unusable for the task I need it, which is to serve
> as a printer for computer generated music. The output is not ugly - it is
> plain wrong!
> 
> Why doesn't the accidental_engraver looks into other voices as well?
> 
> Maybe I can workaround it by doing an extra pass before writing the lilypond
> code to check if this kind of problem may occur... But now I wonder what other
> kind of potential problems may occur with this accidental_engraver
> algorithm...
> 
> Anyway, I just wanted to say that I think this problem deserves more
> consideration.
> 
> Thank you!
> Marco
> 
> On Friday 10 December 2010, you wrote:
> - Original Message -
> From: "Marco Correia" 
> To: 
> Sent: Friday, December 10, 2010 12:35 AM
> Subject: Odd output
> 
> > Hi,
> >
> > I just started using lilypond, so it is very possible that I'm making
> > some mistake.
> >
> > When compiling this example:
> >
> > \include "english.ly"
> > {
> > \clef treble
> > \time 4/4
> > <<
> > { fs'4 }
> > \\
> > { f'4 }
> >
> > }
> >
> > I see two notes on fs (occupying the same position but with stems up > and
> > down). There is no indication that f is there.
> >
> > Is this supposed to/ how do I fix it?
> >
> > Thanks!
> > Marco
> 
> This was one of the first issues I raised, in June this year.  I think it
> was my first bug report:
> 
> http://code.google.com/p/lilypond/issues/detail?id=1134
> 
> 
> --
> Phil Holmes
> 
> 
> -- 
> Marco Correia 
> 
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

As I replied in my direct reply - because it's not right.  I asked a friend who 
teaches music about the Mikado problem I had and he said:

"Key- C major

Bass note pedals - C-G C-G etc.

Chord in Bar 1 G7 (G B D Fnat = dominant 7th); Chord in Bar 2 C major (CEG)

Each bar has a melody which uses AGF# G with the F# as a chromatical altered 
note (lower auxiliary between the 2 Gs) and therefore clashes (to create 
interest) with both chords.

Each sounds fine on their own but looks illogical as a whole.

If you can convince LilyPond that the accidentals are in different voices in 
the piano part then I would hope it would work.   You could but shouldn't 
use a Gb not a F# as the first chordsis a G chord."

Note his final comment - could use a Gb but shouldn't.

--
Phil Holmes


  - Original Message - 
  From: Michael Ellis 
  To: LilyPond User Group 
  Sent: Friday, December 10, 2010 5:18 PM
  Subject: Re: Odd output


  Why not set one of the notes to a different enharmonic pitch?  It's certainly 
much kinder to the musician who's trying to play the composition.


   \include "english.ly"
  {
  \clef treble
  \time 4/4
  <<
  { fs'4 }
  \\
  { es'4 }
  >>
  }



  Cheers,
  Mike



  On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:

Please reply to the user group as well.

As is often pointed out, it's free software and the fixes depend on who is 
working for nothing on the code.

I wouldn't think it would crop up frequently.

I made a workaround with a combination of forcing the accidentals to be 
displayed, and then using force-hshift and extra-offset and a few other tweaks 
to make it work.

My example is pretty complicated, because I also autogenerate the code, but 
you're welcome to a copy if you want.

--
Phil Holmes



- Original Message - From: "Marco Correia" 


    To: "Phil Holmes" 
Sent: Friday, December 10, 2010 10:29 AM
Subject: Re: Odd output



  Thanks!

  I can't believe that this is seen as a low priority enhancement...! This
  completely renders lilypond unusable for the task I need it, which is to 
serve
  as a printer for computer generated music. The output is not ugly - it is
  plain wrong!

  Why doesn't the accidental_engraver looks into other voices as well?

  Maybe I can workaround it by doing an extra pass before writing the 
lilypond
  code to check if this kind of problem may occur... But now I wonder what 
other
  kind of potential problems may occur with this accidental_engraver
  algorithm...

  Anyway, I just wanted to say that I think this problem deserves more
  consideration.

  Thank you!
  Marco

  On Friday 10 December 2010, you wrote:

- Original Message -
    From: "Marco Correia" 
To: 
Sent: Friday, December 10, 2010 12:35 AM
Subject: Odd output

> Hi,
>
> I just started using lilypond, so it is very possible that I'm making
> some mistake.
>
> When compiling this example:
>
> \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { f'4 }
>
> }
>
> I see two notes on fs (occupying the same position but with stems up 
> and
> down). There is no indication that f is there.
>
> Is this supposed to/ how do I fix it?
>
> Thanks!
> Marco


This was one of the first issues I raised, in June this year.  I think 
it
was my first bug report:

http://code.google.com/p/lilypond/issues/detail?id=1134


--
Phil Holmes



  -- 
  Marco Correia 




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user





--


  ___
  lilypond-user mailing list
  lilypond-user@gnu.org
  http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

If you check, you'll see that there's an F# and an Fnat in different voices, 
but they're not shown as separate notes.  It's a bug I reported earlier this 
year.


--
Phil Holmes


- Original Message - 
From: "Marc Mouries" 

To: "Marco Correia" 
Cc: 
Sent: Friday, December 10, 2010 3:18 AM
Subject: Re: Odd output


You get 2 stems because you created 2 voices with the signs "<<" and \\
see 
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Multiple-voices.html


What are you trying to compose?


On Dec 9, 2010, at 7:35 PM, Marco Correia wrote:


Hi,

I just started using lilypond, so it is very possible that I'm making some
mistake.

When compiling this example:

\include "english.ly"
{
\clef treble
\time 4/4
<<
{ fs'4 }
\\
{ f'4 }



}

I see two notes on fs (occupying the same position but with stems up and
down). There is no indication that f is there.

Is this supposed to/ how do I fix it?

Thanks!
Marco

--
Marco Correia 

--
--
Marco Correia

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Michael Ellis]

Why not set one of the notes to a different enharmonic pitch?  It's
certainly much kinder to the musician who's trying to play the composition.

 \include "english.ly"
{
\clef treble
\time 4/4
<<
{ fs'4 }
\\
{ es'4 }
>>
}


Cheers,
Mike


On Fri, Dec 10, 2010 at 7:00 AM, Phil Holmes  wrote:

> Please reply to the user group as well.
>
> As is often pointed out, it's free software and the fixes depend on who is
> working for nothing on the code.
>
> I wouldn't think it would crop up frequently.
>
> I made a workaround with a combination of forcing the accidentals to be
> displayed, and then using force-hshift and extra-offset and a few other
> tweaks to make it work.
>
> My example is pretty complicated, because I also autogenerate the code, but
> you're welcome to a copy if you want.
>
> --
> Phil Holmes
>
>
>
> - Original Message - From: "Marco Correia" <
> marco.v.corr...@gmail.com>
> To: "Phil Holmes" 
> Sent: Friday, December 10, 2010 10:29 AM
> Subject: Re: Odd output
>
>
>  Thanks!
>>
>> I can't believe that this is seen as a low priority enhancement...! This
>> completely renders lilypond unusable for the task I need it, which is to
>> serve
>> as a printer for computer generated music. The output is not ugly - it is
>> plain wrong!
>>
>> Why doesn't the accidental_engraver looks into other voices as well?
>>
>> Maybe I can workaround it by doing an extra pass before writing the
>> lilypond
>> code to check if this kind of problem may occur... But now I wonder what
>> other
>> kind of potential problems may occur with this accidental_engraver
>> algorithm...
>>
>> Anyway, I just wanted to say that I think this problem deserves more
>> consideration.
>>
>> Thank you!
>> Marco
>>
>> On Friday 10 December 2010, you wrote:
>>
>>> - Original Message -
>>> From: "Marco Correia" 
>>> To: 
>>> Sent: Friday, December 10, 2010 12:35 AM
>>> Subject: Odd output
>>>
>>> > Hi,
>>> >
>>> > I just started using lilypond, so it is very possible that I'm making
>>> > some mistake.
>>> >
>>> > When compiling this example:
>>> >
>>> > \include "english.ly"
>>> > {
>>> > \clef treble
>>> > \time 4/4
>>> > <<
>>> > { fs'4 }
>>> > \\
>>> > { f'4 }
>>> >
>>> > }
>>> >
>>> > I see two notes on fs (occupying the same position but with stems up >
>>> and
>>> > down). There is no indication that f is there.
>>> >
>>> > Is this supposed to/ how do I fix it?
>>> >
>>> > Thanks!
>>> > Marco
>>>
>>> This was one of the first issues I raised, in June this year.  I think it
>>> was my first bug report:
>>>
>>> http://code.google.com/p/lilypond/issues/detail?id=1134
>>>
>>>
>>> --
>>> Phil Holmes
>>>
>>
>>
>> --
>> Marco Correia 
>>
>>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

Please reply to the user group as well.

As is often pointed out, it's free software and the fixes depend on who is 
working for nothing on the code.


I wouldn't think it would crop up frequently.

I made a workaround with a combination of forcing the accidentals to be 
displayed, and then using force-hshift and extra-offset and a few other 
tweaks to make it work.


My example is pretty complicated, because I also autogenerate the code, but 
you're welcome to a copy if you want.


--
Phil Holmes


- Original Message - 
From: "Marco Correia" 

To: "Phil Holmes" 
Sent: Friday, December 10, 2010 10:29 AM
Subject: Re: Odd output



Thanks!

I can't believe that this is seen as a low priority enhancement...! This
completely renders lilypond unusable for the task I need it, which is to 
serve

as a printer for computer generated music. The output is not ugly - it is
plain wrong!

Why doesn't the accidental_engraver looks into other voices as well?

Maybe I can workaround it by doing an extra pass before writing the 
lilypond
code to check if this kind of problem may occur... But now I wonder what 
other

kind of potential problems may occur with this accidental_engraver
algorithm...

Anyway, I just wanted to say that I think this problem deserves more
consideration.

Thank you!
Marco

On Friday 10 December 2010, you wrote:

- Original Message -
From: "Marco Correia" 
To: 
Sent: Friday, December 10, 2010 12:35 AM
Subject: Odd output

> Hi,
>
> I just started using lilypond, so it is very possible that I'm making
> some mistake.
>
> When compiling this example:
>
> \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 }
> \\
> { f'4 }
>
> }
>
> I see two notes on fs (occupying the same position but with stems up 
> and

> down). There is no indication that f is there.
>
> Is this supposed to/ how do I fix it?
>
> Thanks!
> Marco

This was one of the first issues I raised, in June this year.  I think it
was my first bug report:

http://code.google.com/p/lilypond/issues/detail?id=1134


--
Phil Holmes



--
Marco Correia 




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Marco Correia]

Thanks!

I can't believe that this is seen as a low priority enhancement...! This 
completely renders lilypond unusable for the task I need it, which is to serve 
as a printer for computer generated music. The output is not ugly - it is 
plain wrong!

Why doesn't the accidental_engraver looks into other voices as well?

Maybe I can workaround it by doing an extra pass before writing the lilypond 
code to check if this kind of problem may occur... But now I wonder what other 
kind of potential problems may occur with this accidental_engraver 
algorithm...

Anyway, I just wanted to say that I think this problem deserves more 
consideration.

Thank you!
Marco

On Friday 10 December 2010, you wrote:
> - Original Message -
> From: "Marco Correia" 
> To: 
> Sent: Friday, December 10, 2010 12:35 AM
> Subject: Odd output
> 
> > Hi,
> > 
> > I just started using lilypond, so it is very possible that I'm making
> > some mistake.
> > 
> > When compiling this example:
> > 
> > \include "english.ly"
> > {
> > \clef treble
> > \time 4/4
> > <<
> > { fs'4 }
> > \\
> > { f'4 }
> > 
> > }
> > 
> > I see two notes on fs (occupying the same position but with stems up and
> > down). There is no indication that f is there.
> > 
> > Is this supposed to/ how do I fix it?
> > 
> > Thanks!
> > Marco
> 
> This was one of the first issues I raised, in June this year.  I think it
> was my first bug report:
> 
> http://code.google.com/p/lilypond/issues/detail?id=1134
> 
> 
> --
> Phil Holmes


-- 
Marco Correia 

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Marc Mouries]

You get 2 stems because you created 2 voices with the signs "<<" and \\
see 
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Multiple-voices.html

What are you trying to compose?

 
On Dec 9, 2010, at 7:35 PM, Marco Correia wrote:

> Hi,
> 
> I just started using lilypond, so it is very possible that I'm making some 
> mistake.
> 
> When compiling this example:
> 
> \include "english.ly"
> {
> \clef treble
> \time 4/4
> <<
> { fs'4 } 
> \\ 
> { f'4 } 
>>> 
> }
> 
> I see two notes on fs (occupying the same position but with stems up and 
> down). There is no indication that f is there.
> 
> Is this supposed to/ how do I fix it? 
> 
> Thanks!
> Marco
> 
> -- 
> Marco Correia 
> 
> -- 
> --
> Marco Correia
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Tim McNamara]

Isn't there a >> missing to pair with the << ?

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Odd output

[Phil Holmes]

- Original Message - 
From: "Marco Correia" 

To: 
Sent: Friday, December 10, 2010 12:35 AM
Subject: Odd output



Hi,

I just started using lilypond, so it is very possible that I'm making some
mistake.

When compiling this example:

\include "english.ly"
{
\clef treble
\time 4/4
<<
{ fs'4 }
\\
{ f'4 }



}

I see two notes on fs (occupying the same position but with stems up and
down). There is no indication that f is there.

Is this supposed to/ how do I fix it?

Thanks!
Marco

--
Marco Correia 


This was one of the first issues I raised, in June this year.  I think it 
was my first bug report:


http://code.google.com/p/lilypond/issues/detail?id=1134


--
Phil Holmes



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Odd output

[James Lowe]

Hello


-Original Message-
From: lilypond-user-bounces+james.lowe=datacore@gnu.org on behalf of Marco 
Correia
Sent: Fri 12/10/2010 0:35
To: lilypond-user@gnu.org
Subject: Odd output
 
Hi,

I just started using lilypond, so it is very possible that I'm making some 
mistake.

When compiling this example:

\include "english.ly"
{
\clef treble
\time 4/4
<<
 { fs'4 } 
 \\ 
 { f'4 } 
>>
}

I see two notes on fs (occupying the same position but with stems up and 
down). There is no indication that f is there.

Is this supposed to/ how do I fix it? 

--

I believe this is the known issue documented

Someone maybe able to give some better solutions but for instance you can

--

\include "english.ly"
{
\clef treble
\time 4/4
<<
 { fs'?4 } 
% This moves the second note to the right adjust the number as you see fit
 \once \override NoteColumn #'force-hshift = #1.7
 \\ 
 { f'!4 } 
>>
}

--

There is also a snippet in the documentation

http://lilypond.org/doc/v2.13/Documentation/snippets/simultaneous-notes#displaying-complex-chords

that might help.

and see

http://lilypond.org/doc/v2.13/Documentation/notation/multiple-voices#collision-resolution

also see the 'known issue' at the bottom of this page - believe this applies 
here even though 'chords' are mentioned.

James

PS To anyone else who knows, if this known issue does apply in this case, then 
it might be a good idea to not use the word 'chord' as that can mean different 
things to different types of musicians - if you see what I mean. We could 
therefore edit the documentation?

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Odd output

[Marco Correia]

Hi,

I just started using lilypond, so it is very possible that I'm making some 
mistake.

When compiling this example:

\include "english.ly"
{
\clef treble
\time 4/4
<<
 { fs'4 } 
 \\ 
 { f'4 } 
>>
}

I see two notes on fs (occupying the same position but with stems up and 
down). There is no indication that f is there.

Is this supposed to/ how do I fix it? 

Thanks!
Marco

-- 
Marco Correia 

-- 
--
Marco Correia

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Two Staves two time signatures repeated bars in different locations per staff- very odd output

[Jay Hamilton, Sound and Silence]

I have created/am working on a score/composition.
Two staves one in 5/4 and one in 3/4 that worked very well.
At one point there is a single bar repeated in the 5/4 line and then a 
bit later I entered a repeat in the second line and an end repeat in the 
middle of the next measure so the 'count' would come out in the end.

The output in pdf showed both sets of repeats in the top line.

Now the easy solution would be for me to just copy and paste the repeats 
in and leave out the offending barlines but I was surprised by my result.

Jay

--
Childhood is a Journey not a race- Emma Sadinsky aged 8
Jay Hamilton
Sound and Silence
206-328-7694
www.soundand.com



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user