Re: why chords with notes of different duration is not supported?

2011-01-12 Thread Werner LEMBERG
[About chords which contain notes of different durations, sometimes seen in string music.] > If the notes are all attached to the same voice why not allowing: > > << g,4 d'4 b'4>> ? If at all, the syntax would be e.g. and the chord's duration would be the maximum of the single note's dura

Re: Chapter "Collision resolution"

2011-01-12 Thread Trevor Daniels
David Kastrup wrote Wednesday, January 12, 2011 4:23 PM "Trevor Daniels" writes: LilyPond currently has a documented restriction that merging cannot take place if there are three or more notes in the same note column. Here there are three, so the third note has to be moved out to permit th

Re: Chapter "Collision resolution"

2011-01-12 Thread Trevor Daniels
David Kastrup wrote Wednesday, January 12, 2011 3:40 PM Polyphony is not required here, as a proper notehead merge will do the trick, like the fourth example shows. The fourth example is correct after shifting an _unrelated_ notehead. In LilyPond terms polyphony is required when two (or m

Re: Chapter "Collision resolution"

2011-01-12 Thread David Kastrup
"Trevor Daniels" writes: > David Kastrup wrote Wednesday, January 12, 2011 3:40 PM > > >> Polyphony is not required here, as a proper notehead merge will do >> the >> trick, like the fourth example shows. The fourth example is correct >> after shifting an _unrelated_ notehead. > > In LilyPond te

Re: Chapter "Collision resolution"

2011-01-12 Thread David Kastrup
"Trevor Daniels" writes: > David Kastrup wrote Wednesday, January 12, 2011 2:24 PM > >> Hi, I'm taking a look at the notation manual under "Collision >> Resolution". >> >> The first beat on the second bar in the example has bad output >> (merges >> an eighth and a half note while inexplicably kee

Re: Chapter "Collision resolution"

2011-01-12 Thread Trevor Daniels
David Kastrup wrote Wednesday, January 12, 2011 2:24 PM Hi, I'm taking a look at the notation manual under "Collision Resolution". The first beat on the second bar in the example has bad output (merges an eighth and a half note while inexplicably keeping the eighth's note head). This is b

Chapter "Collision resolution"

2011-01-12 Thread David Kastrup
Hi, I'm taking a look at the notation manual under "Collision Resolution". The first beat on the second bar in the example has bad output (merges an eighth and a half note while inexplicably keeping the eighth's note head). This particular faulty piece of the output remains in the first three ex

Re: Issue 1419 in lilypond: makelsr.py 's convert-ly should use -d

2011-01-12 Thread lilypond
Comment #6 on issue 1419 by Carl.D.Sorensen: makelsr.py 's convert-ly should use -d http://code.google.com/p/lilypond/issues/detail?id=1419 So, can we make the change to add -d to the convert-ly call in makelsr.py now? ___ bug-lilypond mailing

Re: desired behaviour

2011-01-12 Thread Graham Percival
On Tue, Jan 11, 2011 at 11:43:25PM -0800, Keith OHara wrote: > On Tue, 11 Jan 2011 02:26:08 -0800, Graham Percival > wrote:> > > >>% Accidentals should be printed for only the first note in a tie > >>\version "2.10.1" > >>\relative c'' { > >> bes1 ~ | > >> bes1 > >>} > > I still like it. I h

Re: missing accidental after clef change

2011-01-12 Thread Dmytro O. Redchuk
On Mon 10 Jan 2011, 12:29 Keith OHara wrote: > Dear bug squad, > I am rephrasing a report that got lost in a long-ish thread > > discussing whether it was really a bug. The thread eventually made clear: it > is. > > % When

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

2011-01-12 Thread lilypond
Comment #1 on issue 1471 by brownian.box: accidentals after a clef change are not printed http://code.google.com/p/lilypond/issues/detail?id=1471 (for the record) Keith also pointed to the discussion: http://lists.gnu.org/archive/html/bug-lilypond/2010-12/msg00403.html _