headers
Erik Sandberg | 1 Jan 2005 03:14
Picon
Picon
Favicon

Re: Fingering Spacing Bug

On Friday 31 December 2004 14.35, David Raleigh Arnold wrote:
> I've held off upgrading from 2.2.6 to 2.4.2 because I wanted to finish
> a project.
>
> I converted this file from 2.2.6 to 2.4.2 and the bug is still very much
> present.
>
> I know I could adjust one note at a time, but I think it's more practical
> to wait until you fix this.  There is also a similar problem with
> horizontal spacing, but that can be helped with a tweak.

You can also try to use some ugly trick, like:

A = \transpose c des \relative {c'4 d e f g a b c}
S = \transpose d des {\hideNotes \relative {d'^1 e^1 f^1 g^1 a^1 b^1 c^1 d^1}}
\new Staff <<
\A
\new Voice \S
>>

This works, and it might take less time to do.

> The spacing of the fingering above the notes looks awful.  It will actually
> give you a headache to read too much scale like that.  The height should
> not be affected by the presence of a chromatic sign.

The problem is that it _should_ be affected if the text sticks out to the left 
of the notehead. Solving the general problem of script placement is a very 
big task, and the time for development is limited.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Raleigh Arnold | 1 Jan 2005 14:17

Re: Fingering Spacing Bug

On Friday 31 December 2004 09:14 pm, Erik Sandberg wrote:
> On Friday 31 December 2004 14.35, David Raleigh Arnold wrote:
> > I've held off upgrading from 2.2.6 to 2.4.2 because I wanted to finish
> > a project.
> >
> > I converted this file from 2.2.6 to 2.4.2 and the bug is still very much
> > present.
> >
> > I know I could adjust one note at a time, but I think it's more practical
> > to wait until you fix this.  There is also a similar problem with
> > horizontal spacing, but that can be helped with a tweak.
>
> You can also try to use some ugly trick, like:
>
> A = \transpose c des \relative {c'4 d e f g a b c}
> S = \transpose d des {\hideNotes \relative {d'^1 e^1 f^1 g^1 a^1 b^1 c^1
> d^1}} \new Staff <<
> \A
> \new Voice \S
>
>
> This works, and it might take less time to do.

It's ingenious, but now the numbers are too far from the
note head, even with the fingering attached to lower
invisible notes.

Surely the staccato dots don't look like that?
I'm sure it can be done with a sed script, but the problem
is getting out the paddings and shiftings later, when they
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wiz Aus | 1 Jan 2005 05:41
Picon
Favicon

slurs clashing with portato marks (which are inverted!)

What lilypond calls "portato" marks (a staccato dot and tenuto line 
combined) appear to be inverted - all scores I have have the staccato dot 
closest to the notehead, and the tenuto line furthest.
Furhermore, slurs do not properly avoid them.

Example:

{ g'-_( c'-_ g'-_) }

_________________________________________________________________
Click here for the latest chart ringtones:  
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp
Permalink | Reply | 7 comments |
headers
Mats Bengtsson | 3 Jan 2005 12:34
Picon
Picon
Favicon

Re: Bug report

It seems that the attachment didn't make it through the mailing list,
please try again and paste the trace directly into the email body.

    /Mats

joe ferguson wrote:
> Attached is a trace resulting from " lilypond --verbose 
> ./MUSIC/LILYPOND/lilypond-2.4.3/input/mutopia/J.S.Bach/baerenreiter-sarabande.ly 
> |tee /tmp/LPTrace"
> 
> My system is
> uname -a
> Linux joe 2.6.8-24-default #1 Wed Oct 6 09:16:23 UTC 2004 x86_64 x86_64 
> x86_64 GNU/Linux
> 
> from the SuSE 9.2 distribution on an Athlon-64 processor.  I got the 
> same error during post-install testing from F.Schubert/morgenlied.ly
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> bug-lilypond mailing list
> bug-lilypond <at> gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond

--

-- 
=============================================
	Mats Bengtsson
	Signal Processing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Sandberg | 4 Jan 2005 16:47
Picon
Picon
Favicon

centralCPosition

Hi,

there is a small mistake here:
http://lilypond.org/doc/v2.5/Documentation/user/out-www/lilypond/Clef.html#Clef

centralCPosition should be middleCPosition.

Also, it would be nice if the example at the bottom of the page could 
demonstrate this property somehow.

Thanks,
Erik
Permalink | Reply | 3 comments |
headers
Graham Percival | 6 Jan 2005 08:33
Picon
Favicon

Re: centralCPosition


On 4-Jan-05, at 7:47 AM, Erik Sandberg wrote:
> there is a small mistake here:
> http://lilypond.org/doc/v2.5/Documentation/user/out-www/lilypond/ 
> Clef.html#Clef
>
> centralCPosition should be middleCPosition.
>
> Also, it would be nice if the example at the bottom of the page could
> demonstrate this property somehow.

I'll try to fix it in a few days -- I'd like to be able to test this  
change before
committing it, and we're still working on the OSX build.

If I can't build it by next Monday, I'll commit it anyway, but I'll  
make sure
I don't do anything else that might break the build process, so they'll
know exactly where the problem is (if a problem arises).  :)

Cheers,
- Graham
Permalink | Reply | 2 comments |
headers
Han-Wen Nienhuys | 7 Jan 2005 12:07
Picon
Picon
Favicon

Re: centralCPosition

gperlist <at> shaw.ca writes:
> 
> On 4-Jan-05, at 7:47 AM, Erik Sandberg wrote:
> > there is a small mistake here:
> > http://lilypond.org/doc/v2.5/Documentation/user/out-www/lilypond/ 
> > Clef.html#Clef
> >
> > centralCPosition should be middleCPosition.
> >
> > Also, it would be nice if the example at the bottom of the page could
> > demonstrate this property somehow.
> 
> I'll try to fix it in a few days -- I'd like to be able to test this  
> change before
> committing it, and we're still working on the OSX build.
> 
> If I can't build it by next Monday, I'll commit it anyway, but I'll  
> make sure
> I don't do anything else that might break the build process, so they'll
> know exactly where the problem is (if a problem arises).  :)

Unless you use really strange commands, it's not much work for me to
figure out where the build breaks and

   <at> ignore

it. If you watch the ChangeLog (to fix the  <at> ignore when I put them
in), it should be ok.

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wiz Aus | 8 Jan 2005 21:24
Picon
Favicon

Staff group bracket ends not merged

Given the following:

\new StaffGroup
<<
\new Staff { R1 R1 R1 }
\new InnerStaffGroup
<<
\new Staff { R1 R1 R1 }
\new Staff { R1 R1 R1 }
>>
>>

Both staff grouping brackets end at the same point.  In traditionally 
engraved scores (e.g. Dover's publication of Scheherazade), these ends are 
merged, or at least the inner ends are hidden.
It looks even more noticeable with 3 levels (the latter score has exactly 
this on, say, pg 12, V.Cello).

Speaking of which, how do you have more than 3 levels of staff bracketing? 
It seems to get three you need to use StaffGroup/ChoirStaff/InnerStaffGroup, 
but after that you're on your own.  If I wanted, say, the whole score with 
one bracket, the string section with another bracket, then violin I & II 
bracketed, and then violin I solo and violin I (rest) bracketed, it doesn't 
seem obvious how to do this.

_________________________________________________________________
Find love today with ninemsn personals. Click here:  
http://ninemsn.match.com?referrer=hotmailtagline
Permalink | Reply | 501 comments |
headers
Erik Sandberg | 9 Jan 2005 15:12
Picon
Picon
Favicon

Re: slurs clashing with portato marks (which are inverted!)

On Saturday 01 January 2005 05.41, Wiz Aus wrote:
> What lilypond calls "portato" marks (a staccato dot and tenuto line
> combined) appear to be inverted - all scores I have have the staccato dot
> closest to the notehead, and the tenuto line furthest.

Added as portato-direction.

Portato doesn't exist in the music I use to play, so I don't know myself which 
direction that is correct. Do you have concrete examples of well-engraved 
scores that do it the other way around? Or can anyone else confirm how it 
should look?

(Most sources I can find prefer tenuto lines, or slurred notes with staccato 
dots)

> Furhermore, slurs do not properly avoid them.

Added as c-slur-portato.

Thanks!
Erik
Permalink | Reply | 6 comments |
headers
Erik Sandberg | 9 Jan 2005 15:35
Picon
Picon
Favicon

Re: Staff group bracket ends not merged

On Saturday 08 January 2005 21.24, Wiz Aus wrote:
> Given the following:
>
> \new StaffGroup
> <<
> \new Staff { R1 R1 R1 }
> \new InnerStaffGroup
> <<
> \new Staff { R1 R1 R1 }
> \new Staff { R1 R1 R1 }
>
>
>
> Both staff grouping brackets end at the same point.  In traditionally
> engraved scores (e.g. Dover's publication of Scheherazade), these ends are
> merged, or at least the inner ends are hidden.
> It looks even more noticeable with 3 levels (the latter score has exactly
> this on, say, pg 12, V.Cello).

Thanks! Do you have a scan of an example of how it should be done?

I agree that it doesn't look good, and I have added it as 
staffgroup-bracket-nested in the bug cvs. Thanks for the report!

> Speaking of which, how do you have more than 3 levels of staff bracketing?
> It seems to get three you need to use
> StaffGroup/ChoirStaff/InnerStaffGroup, but after that you're on your own. 
> If I wanted, say, the whole score with one bracket, the string section with
> another bracket, then violin I & II bracketed, and then violin I solo and
> violin I (rest) bracketed, it doesn't seem obvious how to do this.
(Continue reading)

Permalink | Reply | 503 comments |

Gmane