Re: Clef change and measure length

[foxfanfare]

Malte Meyn-3 wrote
> That example is the same in the german translation. But at p. 172 
> (“Horizontale Ausrichtung von Pausen → Ganztaktige Pausen”, i. e. 
> “Horizontal positioning of rests → full measure rests”) she writes 
> something like “If the rest measure contains a clef, key signature or 
> time signature, one has to center the rest in the remaining space”, see 
> attachment.
> 
> So Gould is inconsistent here ;)

Yes I see :) Well it's p.160 in the english version. In my opinion, this
rule only applies when you write with a single staff, that's all. I
understand why LP has been configured that way and your right, it's not a
bug. But I'll have to remember correcting that each time I write for several
musicians or at least with 2-staves instruments!

It seems to me to be an engraving issue, especially when you write
orchestral music. Don't you think it would be a good idea to put the
demonstration with \override MultiMeasureRest.spacing-pair = #'(staff-bar .
staff-bar) in the documentation after
http://lilypond.org/doc/v2.19/Documentation/notation/writing-rests#full-measure-rests
 
?





--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Malte Meyn]

Am 27.10.19 um 17:30 schrieb foxfanfare:

Thanks for your replies. Where did you find this reference in Gould's book?
I was looking for that before writing my initial post but without success.
On the contrary, I found this example which suggests otherwise (see the
second one):
mmr.jpg   


That example is the same in the german translation. But at p. 172 
(“Horizontale Ausrichtung von Pausen → Ganztaktige Pausen”, i. e. 
“Horizontal positioning of rests → full measure rests”) she writes 
something like “If the rest measure contains a clef, key signature or 
time signature, one has to center the rest in the remaining space”, see 
attachment.


So Gould is inconsistent here ;)


I also rember writing orchestral music and I found always strange when
several MMR where not centered in their measure because only one instrument
had a clef change... Or maybe I don't get your point.


Yes, that’s what I find strange too.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[foxfanfare]

Malte Meyn-3 wrote
> I think that it depends on context: In a full score where only one 
> instrument has a clef change, it would look weird if all the other 
> instruments have the rest not centered. But in solo music, I’m not so 
> sure which one I would prefer.
> 
> According to Gould LilyPond’s behaviour is correct, but she doesn’t say 
> anything about full scores …

Thanks for your replies. Where did you find this reference in Gould's book?
I was looking for that before writing my initial post but without success.
On the contrary, I found this example which suggests otherwise (see the
second one):
mmr.jpg   

I also rember writing orchestral music and I found always strange when
several MMR where not centered in their measure because only one instrument
had a clef change... Or maybe I don't get your point.


Thomas Morley-2 wrote
> Nevertheless you can change this behaviour by applying
> [\once]
> \override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
> as stated in the IR.

That's good to know, thank you very much.



--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Thomas Morley]

Am Sa., 26. Okt. 2019 um 10:30 Uhr schrieb foxfanfare :
>
> Hi all,
>
> I think this is a bug: when a clef change appears after a full measure rest,
> the rest is no longer centered properly in the measure. The result looks
> weird. See that example:
>
> \version "2.19.82"
>
> \new Staff
> \relative c' {
>   c1
>   R-"default"
>   \bar "||"
>   R_"not centered"
>   \clef bass
>   \once \override MultiMeasureRest.X-offset = #1
>   R-"tweaked"
>   \clef treble
>   c
> }
>
> What do you think?
>
> clefchange.ly
> 
> clefchange.pdf
> 

Well, while centering a MMR the question is "center between which items?"
Default LilyPond centers between left and right break-alignment.
That's what's done and what you see.
So no bug, but intended.

Nevertheless you can change this behaviour by applying
[\once]
\override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
as stated in the IR.


Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Malte Meyn]

Am 26.10.19 um 10:40 schrieb foxfanfare:

Hi all,

I think this is a bug: when a clef change appears after a full measure rest,
the rest is no longer centered properly in the measure. The result looks
weird. See that example:

\version "2.19.82"

\new Staff
\relative c' {
   c1
   R-"default"
   \bar "||"
   R_"not centered"
   \clef bass
   \once \override MultiMeasureRest.X-offset = #1
   R-"tweaked"
   \clef treble
   c
}

What do you think?


I think that it depends on context: In a full score where only one 
instrument has a clef change, it would look weird if all the other 
instruments have the rest not centered. But in solo music, I’m not so 
sure which one I would prefer.


According to Gould LilyPond’s behaviour is correct, but she doesn’t say 
anything about full scores …


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[David Kastrup]

james james.lilyp...@googlemail.com writes:

 In the following:
 \version 2.14.2
 \score {
\relative c' {
   \time 2/4
   \set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
   \clef treble
   c8 a c d
 %%% Commenting out the following line solves the problem %%%
   \clef bass
   e fis d c
}
\layout {}
 }

 The clef change causes lilypond to error and not produce output. This
 also errors in 2.15., while 2.12 does not error. Is there some way
 around this?

Ok, consider me annoyed now.  Yes, we have some snippets documenting
this sort of thing, but what is it even supposed to mean?

The actual accidental _code_ knows two kinds of accidental entries: one
_without_ octave entry for the key signature, and one _with_ octave
entry _and_ bar/measure position for signifying a locally changed key
signature by a particular accidental in the music with given note and
octave and time.

The actual code does not try making sense of a _key_ signature entry
_with_ octave (and consequently without bar/measure position).  And what
is a key signature with octave location actually supposed to mean?  Do
we need an accidental for a note in key signature but one octave higher,
or not?

So I fail to make _any_ sense of your example.  If I had to guess, I'd
say the octave specifications are there for overriding the default
octaves chosen by the key signature engraver, but without being fixed to
a certain octave concerning their effect on the music.

However, with _that_ interpretation, a clef change like you propose
above leads to accidentals displayed up in the sky in ledger line
domain.  What's the key engraver to do in this case?  Transpose the
whole octave-enriched key signature down by entire octaves (thus keeping
the arrangement of the scale) until it starts making sense again?  Leave
it in the sky with ledger lines?  Without?

What is your expectation?  For what kind of music and situation is this
useful?

Without an answer to that question, I don't really know the direction
the fix should be taking properly.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[james]

On Aug 14, 2012, at 5:00 PM, David Kastrup wrote:

 james james.lilyp...@googlemail.com writes:
 
 So I fail to make _any_ sense of your example.  If I had to guess, I'd
 say the octave specifications are there for overriding the default
 octaves chosen by the key signature engraver, but without being fixed to
 a certain octave concerning their effect on the music.
 
 However, with _that_ interpretation, a clef change like you propose
 above leads to accidentals displayed up in the sky in ledger line
 domain.  What's the key engraver to do in this case?  Transpose the
 whole octave-enriched key signature down by entire octaves (thus keeping
 the arrangement of the scale) until it starts making sense again?  Leave
 it in the sky with ledger lines?  Without?
 
 What is your expectation?  For what kind of music and situation is this
 useful?
 
 Without an answer to that question, I don't really know the direction
 the fix should be taking properly.

Honestly, what's most important to me is where the sharps/flats in the key 
signature are placed. I attach the image of what I expect:
\include deutsch.ly
\version 2.12.3
\score {
   
  \new Staff 
 \relative c'{
\time 1/4
\set Staff.keySignature = #`((9 . ,FLAT))
c4*1/3 d es f g a h a g f es d c4
 }
  
  \new Staff 
 \relative c' {
a4*1/3 h c d e fis gis fis e d c h a4
 }
 {  %% Key Signatures
\clef bass
\set Staff.keySignature = #`(((-1 . -3) . ,SHARP) ((-1 . -4) . 
,SHARP))
s4*2  | %1-18
\clef treble
\set Staff.printKeyCancellation = ##f
\set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
 }
  
   
   \layout {}
}
\score {
   
  \new Staff 
 \relative c'{
\time 1/4
\set Staff.keySignature = #`((9 . ,FLAT))
c4*1/3 d es f g a h a g f es d c4
 }
  
  \new Staff 
 \relative c' {
a4*1/3 h c d e fis gis fis e d c h a4
 }
 {  %% Key Signatures
\clef bass
\set Staff.keySignature = #`((4 . ,SHARP) (3 . ,SHARP))
s4*2  | %1-18
\clef treble
\set Staff.printKeyCancellation = ##f
\set Staff.keySignature = #`((4 . ,SHARP) (3 . ,SHARP))
 }
  
   
   \layout {}
}

I should note that making minor changes (like to the rhythm) may also solve the 
problem, but the important thing, for me at least, is that it shouldn't happen, 
regardless.


key signatures_2.12.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[David Kastrup]

james james.lilyp...@googlemail.com writes:

 Honestly, what's most important to me is where the sharps/flats in the
 key signature are placed. I attach the image of what I expect:

That image does not make sense to me at all.  Notes appear in key
signature (though in a different octave) and still carry an accidental.
How do you distinguish a normal key signature (valid across all octaves)
from a restricted-octave one (valid only in one octave)?  They look the
same.

 I should note that making minor changes (like to the rhythm) may also
 solve the problem, but the important thing, for me at least, is that
 it shouldn't happen, regardless.

I can't make sense of your score, and I can't even make sense of your
sentences.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change placed outside score

[Ralph Palmer]

On Tue, Jun 14, 2011 at 11:55 PM, Jay Anderson horndud...@gmail.com wrote:

 \version 2.14.1

 %The bass clef in the lower staff is placed to the left of the staff. If
 either
 %the tempo mark is removed or the triplets are changed to a quarter note
 the
 %the clef is placed correctly. This was not an error in 2.12.3.

 musx = \relative c'
 {
  % Change this to c4 for correct clef placement
  \times 2/3 {c8 c c}

  % Comment this out for correct clef placement
  \tempo asdf

  c4 c c
 }

 musy = \relative c'
 {
  \clef treble c4 \clef bass c4 c c
 }

 \score
 {
  
\new Staff \musx
\new Staff \musy
  
 }


Greetings, Jay Anderson and Lilyponders -

This has  been submitted as Issue 1695 :
http://code.google.com/p/lilypond/issues/detail?id=1695

Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change placed outside score

[Jay Anderson]

On Wed, Jun 15, 2011 at 6:11 AM, Ralph Palmer ralphbugl...@gmail.com wrote:
 This has  been submitted as Issue 1695 :
 http://code.google.com/p/lilypond/issues/detail?id=1695

Thanks. I think I found a couple workarounds:

musy = \relative c'
{
  \clef treble
  \override Score.NonMusicalPaperColumn #'allow-loose-spacing = ##f
  c4
  \clef bass c4 c c
  \revert Score.NonMusicalPaperColumn #'allow-loose-spacing
}

This isn't the best as the clef now causes space to be made in the other staff.

The other workaround is just changing the tempo to a markup. I prefer
the tempo, but at least with this there isn't the extra space.

Are there other workarounds? Nothing else I tried seemed to work.

-Jay

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Erik Sandberg]

This bug is fixed, or at least much improved, in 2.7.6.

Michael, can you please verify that it is the way you expect?

On Saturday 24 April 2004 15.09, Erik Sandberg wrote:
 Hi,

 I added this to the bug cvs as 'clef-change'.

 %
 % 
 \header { texidoc =
 The clef change in bar 1 is too far to the right (it should be
 placed below the notes of the first staff), and in bar 2 it is
 too far to the right (it should be next to the left of the next
 note) }
 \version 2.3.1
 \score {
 
 \new Staff \notes {
 b8. b16 b8. b16 b8. b16 b8. b16 |
 \time 4/2 b8. b16 b8. b16 b8. b16 b8. b16 b1 }
 \new Staff \notes {
 b1 \clef F b \clef G b}

 \paper { raggedright = ##t }
 }

-- 
Erik Sandberg
Maintainer of the Lilypond bug CVS archive,
http://savannah.gnu.org/cgi-bin/viewcvs/lilypond/lily-bugs/bugs/
http://lilypond.org/bugs/v2.6/


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

Re: Clef change

[Erik Sandberg]

On Sunday 02 May 2004 23.00, Han-Wen Nienhuys wrote:
 Couldn't we just have the entire collection rendered just like
 input/test in the tips  tricks? Putting binary blobs, which are also
 compiler output (by lilypond), into a source version control system
 isn't the way to go I.M.O.

I see the pngs only as an illustration to the bug description. Different pngs 
may be created in different ways, see e.g. grace-accidental-spacing.png. The 
reason why most pngs are direct lilypond output, is that this often is the 
easiest  clearest way of doing it (but it would work just as well e.g. to 
draw a picture of lilypond's output by hand)

There are 2 reasons they are there:
1. To make it more obvious to you developers what I mean
2. That I will be able to easily compare the .ps output of new versions to the 
old buggy output, so I quickly can decide whether the bug has been fixed.

What you describe is AFAICU some kind of history of how layout bugs evolve 
between lily versions. I have not seen any use for this myself yet. Bugs tend 
to be binary; first it doesn't work, then it works; so in this case the only 
relevant history is contained in the date the bug was removed from CVS.

I agree that using cvs for uploading png may seem a bit strange. But it works 
and is very simple. cvs add -kb foo.png is much easier than using ftp. And 
the file will be downloaded automatically to . during cvs update, which is 
much easier than having to open mozilla.

I'll be happy to change the system once there is a really good reason for it, 
though.

Erik


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

 I agree that using cvs for uploading png may seem a bit strange. But
 it works and is very simple. cvs add -kb foo.png is much easier
 than using ftp. And the file will be downloaded automatically to .
 during cvs update, which is much easier than having to open mozilla.

I fully second this.


Werner


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Han-Wen Nienhuys]

[EMAIL PROTECTED] writes:
 I agree that using cvs for uploading png may seem a bit strange. But it works 
 and is very simple. cvs add -kb foo.png is much easier than using ftp. And 
 the file will be downloaded automatically to . during cvs update, which is 
 much easier than having to open mozilla.
 
 I'll be happy to change the system once there is a really good reason for it, 
 though.

ok. Point taken.

 
 Erik

-- 

 Han-Wen Nienhuys   |   [EMAIL PROTECTED]   |   http://www.xs4all.nl/~hanwen 



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Erik Sandberg]

On Sunday 02 May 2004 16.16, Werner LEMBERG wrote:
  BTW, the same goes for multivoice-rest-position2.  It's not 100%
  obvious (to me at least) that it really is a bug; I can imagine that
  the coders could be more motivated to fix the problem if you've done
  some research that shows that your suggestion is common practise.

 It's quite difficult to find a real example quickly (except my own
 work :-).  Well, take `Das Wohltemperierte Klavier, Teil I' (Henle 14,
 engraved 1950 I think) and look at Fuga XVIII (BWV 863).  In bar 4,
 the eighth rests in the left hand are lower than in bar 39 or 40.
 Similar typesetting can be found in Fuga XX.  The general idea is that
 rests of a voice in a multi-voice staff should follow the melody.

 An even better example is from Robert Schumann, Klavierwerke IV
 (Breitkopf 2620, engraved at least before 130 years), Humoreske, page
 24f (`Mit einigem Pomp'), left hand -- I'm quite sure that this must
 look similar in all other editions of the Humoreske.  Again, the idea
 is that the rests roughly follow the voice's vertical position.

Great!

 PS: I don't have a scanner (yet), so I can't provide images.

Not needed IMO, the important thing is that there _exists_ a good source. I 
added notes that your two bug reports are verified as The Way It Should Be 
Done In Well-Engraved Scores. It makes an important difference in priority, 
compared to people who simply complain that they think something doesn't look 
good.

Erik



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

I wrote:

 I ask for yet another refinement: Do a zoom at the problematic spot
 and crop the image around the buggy detail [...]

A good example is grace-accidental-spacing.ly: The current image (as
of Apr. 28th) doesn't really show the problem since the relevant
distances are already within subpixel resolution at the image's scale.


Werner


PS: I've added the following files of my bug collection to lily-bugs:

  beam-accidental-collision.ly
  broken-small-slur.ly
  multivoice-rest-position.ly
  multivoice-rest-position2.ly


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Erik Sandberg]

On Sunday 02 May 2004 07.34, Werner LEMBERG wrote:
 I wrote:
  I ask for yet another refinement: Do a zoom at the problematic spot
  and crop the image around the buggy detail [...]

 A good example is grace-accidental-spacing.ly: The current image (as
 of Apr. 28th) doesn't really show the problem since the relevant
 distances are already within subpixel resolution at the image's scale.

Very true, it has now been replaced by a better image. Thanks for the comment.

 PS: I've added the following files of my bug collection to lily-bugs:

   beam-accidental-collision.ly
   broken-small-slur.ly
   multivoice-rest-position.ly
   multivoice-rest-position2.ly

Thanks! I marked multivoice-rest-position as important (since I fully agree 
with your severe comments).

Re: broken-small-slur:
This one has pretty much to do about taste. Your suggestion sounds sensible, 
but do you have a hand-engraved example of this behaviour? (this would 
support the claim that you have a good taste :) You wouldn't need to provide 
a scan of the score; just adding a texidoc notice telling which score you 
have looked at, should be enough)

Erik



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Erik Sandberg]

On Sunday 02 May 2004 10.36, Erik Sandberg wrote:
 On Sunday 02 May 2004 07.34, Werner LEMBERG wrote:
beam-accidental-collision.ly
broken-small-slur.ly
multivoice-rest-position.ly
multivoice-rest-position2.ly

 Thanks! I marked multivoice-rest-position as important (since I fully agree
 with your severe comments).

 Re: broken-small-slur:
 This one has pretty much to do about taste. Your suggestion sounds
 sensible, but do you have a hand-engraved example of this behaviour? (this
 would support the claim that you have a good taste :) You wouldn't need to
 provide a scan of the score; just adding a texidoc notice telling which
 score you have looked at, should be enough)

BTW, the same goes for multivoice-rest-position2. It's not 100% obvious (to me 
at least) that it really is a bug; I can imagine that the coders could be 
more motivated to fix the problem if you've done some research that shows 
that your suggestion is common practise.

Erik



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

 This one has pretty much to do about taste.  Your suggestion sounds
 sensible, but do you have a hand-engraved example of this behaviour?
 (this would support the claim that you have a good taste :) You
 wouldn't need to provide a scan of the score; just adding a texidoc
 notice telling which score you have looked at, should be enough)

I've just looked into César Franck's Violin Sonata A major (Henle 293,
engraved 1975).  In this score, broken slurs in the small staff are in
fact always horizontally smaller (this is, the x coordinate value of
the starting point is larger) -- they are printed in a natural size,
so to say.

Another example is the Urtext edition of the three Violin Sonatas of
Johannes Brahms (UE 50011-50013, engraved 1973).  Here the smaller
staff for the Violin is typeset with a larger size, compared to the
Henle edition from Franck.  In most cases, both broken slurs and ties
are aligned vertically.  Sometimes the slurs and ties of the smaller
staff are shorter, and very seldom they are *a bit* larger, probably
caused by aligning with the eye and not with a ruler.


Werner


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

 BTW, the same goes for multivoice-rest-position2.  It's not 100%
 obvious (to me at least) that it really is a bug; I can imagine that
 the coders could be more motivated to fix the problem if you've done
 some research that shows that your suggestion is common practise.

It's quite difficult to find a real example quickly (except my own
work :-).  Well, take `Das Wohltemperierte Klavier, Teil I' (Henle 14,
engraved 1950 I think) and look at Fuga XVIII (BWV 863).  In bar 4,
the eighth rests in the left hand are lower than in bar 39 or 40.
Similar typesetting can be found in Fuga XX.  The general idea is that
rests of a voice in a multi-voice staff should follow the melody.

An even better example is from Robert Schumann, Klavierwerke IV
(Breitkopf 2620, engraved at least before 130 years), Humoreske, page
24f (`Mit einigem Pomp'), left hand -- I'm quite sure that this must
look similar in all other editions of the Humoreske.  Again, the idea
is that the rests roughly follow the voice's vertical position.


Werner


PS: I don't have a scanner (yet), so I can't provide images.


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Han-Wen Nienhuys]

[EMAIL PROTECTED] writes:
 On Sunday 25 April 2004 13.35, Werner LEMBERG wrote:
   I added this to the bug cvs [...]
 
  It would be great if you can store JPG images also which show the
  problem!
 
 I use .png instead. I use the convention that if I submit something as 
 clef-change.ly, I upload clef-change.png demonstrating the problem, if 
 appropriate. Doesn't that file appear for you? If not, you can get it by web 
 CVS as well:
 
 http://savannah.gnu.org/cgi-bin/viewcvs/lilypond/lily-bugs/bugs/clef-change.png?rev=1.1content-type=text/vnd.viewcvs-markup



Couldn't we just have the entire collection rendered just like
input/test in the tips  tricks? Putting binary blobs, which are also
compiler output (by lilypond), into a source version control system
isn't the way to go I.M.O.

The collection could have a webpage for every release, eg see,

 http://byrd.xs4all.nl/lilypond/sites/

(if it's up, it's my desktop), which does this for the websites.

--
 Han-Wen Nienhuys   |   [EMAIL PROTECTED]   |   http://www.xs4all.nl/~hanwen 



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

  It would be great if you can store JPG images also which show the
  problem!
 
 I use .png instead.

Yes, of course.  A typo of mine.

 I use the convention that if I submit something as clef-change.ly,
 I upload clef-change.png demonstrating the problem, if appropriate.

Thanks, I got them.  I ask for yet another refinement: Do a zoom at
the problematic spot and crop the image around the buggy detail
(without using anti-aliasing to have the images as small as possible).

Is `\version x.x.x.' precise enough?  Be prepared that I use the date
of the ChangeLog file as the time stamp for a bug report...


Werner


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Erik Sandberg]

On Monday 26 April 2004 07.43, Werner LEMBERG wrote:
   It would be great if you can store JPG images also which show the
   problem!
 
  I use .png instead.

 Yes, of course.  A typo of mine.

  I use the convention that if I submit something as clef-change.ly,
  I upload clef-change.png demonstrating the problem, if appropriate.

 Thanks, I got them.  I ask for yet another refinement: Do a zoom at
 the problematic spot and crop the image around the buggy detail
 (without using anti-aliasing to have the images as small as possible).

So far I've just used plain lilypond --png for simplicity. I'll do more 
whenever anything seems unclear. I am minimalistic by nature; I don't enjoy 
putting effort in producing aesthetically correct bug reports if it isn't 
necessary. To me it's just an illustration to help pointing out what's wrong.

So: If it is a layout bug, and it is not immediately 100% clear from lilypond 
--png + texidoc what the problem is, then I'll do the work of starting gimp; 
and I'll probably draw a few red rings  arrows, and crop the image. I'll 
skip this step if it is too obvious (such as misplaced-octaviation or 
piano-repeat), but i'll do the work in cases such as 
grace-accidental-spacing.

And is space really an issue? A typical bugreport PNG is 5K, which should take 
about 1 second to download over a modem; and typically 5 people will 
download it by modem. And the space consumption is not so crucial really; 
given that one gigabyte costs less than 1 euro these days (so it takes about 
2000 bugreports to reach the cost of 1 cent).

 Is `\version x.x.x.' precise enough?  Be prepared that I use the date
 of the ChangeLog file as the time stamp for a bug report...

Most bugs I've added have existed in official releases as well, so \version 
has been enough. But you're right, there should be a mechanism to be more 
specific than that.

I'd suggest to add timestamp = ... in \header, when needed.

BTW, is there a  preferred date format  how do you extract that easily with 
CVS?

Erik



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

 BTW, is there a preferred date format  how do you extract that
 easily with CVS?

I just take the ChangeLog timestamp which normally is precise enough
-- optimally, you should refer to the ChangeLog revision number.


Werner


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

 I added this to the bug cvs [...]

It would be great if you can store JPG images also which show the
problem!


Werner


___
Bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Han-Wen Nienhuys]

[EMAIL PROTECTED] writes:
 
  I added this to the bug cvs [...]
 
 It would be great if you can store JPG images also which show the
 problem!

it's a better idea to use lilypond  or lilypond-book to do this, then
we can see what happens to each bugs  for every release.


-- 

 Han-Wen Nienhuys   |   [EMAIL PROTECTED]   |   http://www.xs4all.nl/~hanwen 



___
Bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Werner LEMBERG]

  It would be great if you can store JPG images also which show the
  problem!
 
 it's a better idea to use lilypond or lilypond-book to do this, then
 we can see what happens to each bugs for every release.

But sometimes it is difficult to describe a problem with words.  To
compare newer versions of lilypond with the buggy results should be
easier if images are already there...


Werner


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change

[Jan Nieuwenhuizen]

Werner LEMBERG writes:

 But sometimes it is difficult to describe a problem with words.  To
 compare newer versions of lilypond with the buggy results should be
 easier if images are already there...

Yes, a picture showing the bug is a very good idea.  That's one of the
reasons why your bug reports are so helpful; a picture talks.
Additional pictures showing latest lily output is another thing.

-- 
Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org



___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond