Re: do we want special versions of the accidentals for use with text?

[Werner LEMBERG]

> I think the solution is to create a shorter variaton of accidental
> glyphs; an example in the attachment.  How do you like this idea?
> Do you think all accidentals should have shorter versions, or would
> it be overkill to create for example a shorter version of 3-stemmed
> sharp or arrowed flat?

Basically, I like the idea.  However, it is an illusion IMHO to
believe that such glyphs will fit all text fonts.  As David has
mentioned already, many fonts contain (usually ugly) text versions of
accidentals which should fit the font's height.

For figured bass, the situation is different: Here we use LilyPond's
digit font, which is completely under our control, and having
accidentals fitting those digits better is a good thing.


Werner

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

PATCH: 48-hour countdown to 20110914

[Colin Campbell]

For 22:00 MDT Wednesday, September 14

Issue 456 : 
\laissezVibrer in chords - R 4969069 



Issue 1876 : 
MusicXML: fix case when some elements have a staff number, while others 
don't - R 4991044 


Issue 1193 : 
Enhancement: internal ledger lines, and
Issue 1292 : 
Enhancement: twelve-notation support, and
Issue 1878 : 
Add support for custom ledger positions

All 3 above connected to  R 4974075 

Issue 380 : 
cycling markup reference segfaults - R 4951073 



Issue 1852 : 
manuals needs more explicit dependencies - R 4996044 



Issue 1873 : 
Added glyphs for Kievan Notation - R 4951062 



Issue 1776 : 
Doc: NR - Polymetric Notation \compoundMeter isn't documented - R 
4837050 


A goodly batch today, devels. Nice work!

Cheers
Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 

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

change longas similarly to how breves were changed (issue 4962072)

[janek . lilypond]

Reviewers: Bertrand Bordage,

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

Description:
change longas similarly to how breves were changed

Put vertical lines farther apart,
make them longer to increase readability
and include them in X-extent.

Please review this at http://codereview.appspot.com/4962072/

Affected files:
  M mf/feta-noteheads.mf


Index: mf/feta-noteheads.mf
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index  
87d9034713359aeb5e9cd0d4266334c8cbbf23ae..8fee28083196dc04663c78dd38afb1697742b8e0  
100644

--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -82,42 +82,62 @@ endgroup;
 enddef;


-%
-% dimensions aren't entirely right.
-%
 def draw_longa (expr up) =
save stemthick, fudge;

stemthick# = 2 stafflinethickness#;
define_whole_blacker_pixels (stemthick);

-   fudge = hround (blot_diameter / 2);
+   % Longas of smaller design sizes should have their lines farther
+   % apart (the overlap with notehead ellipsoid should be smaller).
+   fudge = hround (blot_diameter
+   * min (max (-0.15,
+   (0.9
+- (20 / (design_size + 4,
+  0.3));

draw_outside_ellipse (1.80, 0, 0.707, 0);
undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#);

+   set_char_box (stemthick#,
+ width# + stemthick#,
+ noteheight# / 2,
+ noteheight# / 2);
+
pickup pencircle scaled stemthick;

+   % Longas of smaller design sizes should have their lines longer.
+   line_length := min (max (0.7, (64/60 - (design_size / 60))), 0.85);
+
+   % Line lengths between 0.72 and 0.77 are not nice
+   % because they are neither separate nor connected
+   % when there is an interval of fourth.
+   if line_length < 0.75:
+   quanted_line_length := min (0.72, line_length);
+   else:
+   quanted_line_length := max (0.77, line_length);
+   fi;
+
if up:
-   bot y1 = -d;
-   top y2 = h;
+   bot y1 = -quanted_line_length * staff_space;
+   top y2 = quanted_line_length * staff_space;
rt x1 - fudge = 0;
x1 = x2;

-   fudge + lft x3 = w;
+   fudge + lft x3 = width;
x4 = x3;
top y4 = h + 3.0 staff_space;
y3 = y1;
else:
bot y1 = -d - 3.0 staff_space;
-   top y2 = h;
+   top y2 = quanted_line_length * staff_space;
rt x1 - fudge = 0;
x1 = x2;

-   fudge + lft x3 = w;
+   fudge + lft x3 = width;
x4 = x3;
y4 = y2;
-   bot y3 = -d;
+   bot y3 = -quanted_line_length * staff_space;
fi;

draw_gridline (z1, z2, stemthick);



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

Re: A few remarks concerning \relative

[David Kastrup]

Graham Percival  writes:

> On Tue, Sep 13, 2011 at 12:20:47AM +0200, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > But this is *not* appropriate for the
>> > tutorial.  I will be very unhappy if you put it there.
>> 
>> It already went in with the last batch of patches
>
> I am very unhappy.
>
>> > Trust me.  The tutorial should keep words to 3 syllables or less
>> > if at all possible.
>> 
>> How about:
>> "Here is a neat trick: if you write @code{@w\relative f}}, the next
>> note will look just like absolute pitch."
>> Apart from "absolute", only monosyllabic words.
>
> That would make me less unhappy.  Getting rid of the "here is a
> neat trick" would make me slightly less unhappy again -- I would
> then merely be displeased.

I have to admit I utterly fail to comprehend either.  "If you write
@code{@w\relative f}}, the next note will look just like absolute
pitch.", on its own at that point in the text, is _terrible_ for a
tutorial.  The message is "Here is some meaningless scrap of
information.  Don't expect an explanation.  Don't expect usefulness".
You can improve only slightly by writing: "Note: if you write ...".

"Here is a neat trick:" conveys "this could be useful", "if you think
about it with the information already available to you, you will be able
to figure it out and learn something in the process", and "you are
smart, and we like you to have fun during your journey with Lilypond".

It's tutorial-speak at its best.  I don't understand either your
unhappiness nor your displeasure.

-- 
David Kastrup

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

Re: include lines in breve X-extent (issue 1814) (issue 4986042)

[janek . lilypond]

On 2011/09/12 22:54:44, J_lowe wrote:

Passes make and I get a few reg test differences.


Thanks.  They are all expected.
Pushed as a1ce4a26eb893c1f752d260394a977ab811e3368

cheers,
Janek

http://codereview.appspot.com/4986042/

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

Re: include lines in breve X-extent (issue 1814) (issue 4986042)

[pkx166h]

Passes make and I get a few reg test differences.

See

http://code.google.com/p/lilypond/issues/detail?id=1814#c10

for attachments,

http://codereview.appspot.com/4986042/

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

in what unit is shift_amount measured? (preparing fix for 1546)

[Janek Warchoł]

Hi,

i'm pretty confused about how note columns shift is measured (line 277
and following in note-collision.cc).  I tried modifying the values
there, but the results were quite unexpected; i tried to trace in what
unit is shift_amount measured but to no avail.  Could you enlighten
me?
(my idea to fix 1546 is to include X-extent of the left note column in
shift_amount).

cheers,
Janek

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

Re: A few remarks concerning \relative

[Graham Percival]

On Tue, Sep 13, 2011 at 12:20:47AM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > But this is *not* appropriate for the
> > tutorial.  I will be very unhappy if you put it there.
> 
> It already went in with the last batch of patches

I am very unhappy.

> > Trust me.  The tutorial should keep words to 3 syllables or less
> > if at all possible.
> 
> How about:
> "Here is a neat trick: if you write @code{@w\relative f}}, the next
> note will look just like absolute pitch."
> Apart from "absolute", only monosyllabic words.

That would make me less unhappy.  Getting rid of the "here is a
neat trick" would make me slightly less unhappy again -- I would
then merely be displeased.

I make no guarantees that even that sentence will survive my next
review of Tutorial, but that probably won't happen until 2013, and
by then we'll hopefully have the new \relative-mode command
anyway.

Your notation-speak version looks ok for pitches.itely.

Cheers,
- Graham

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

Re: A few remarks concerning \relative

[Janek Warchoł]

2011/9/13 David Kastrup :
> Graham Percival  writes:
>
>> On Mon, Sep 12, 2011 at 04:18:38PM +0200, David Kastrup wrote:
>>> Graham Percival  writes:
>>>
>>> > I'm reluctant to add the suggestion of \relative f' {  to the
>>> > tutorial since all the examples are variants of c.
>>>
>>> Personally, I don't think \relative f' is all that interesting.  The
>>> really idiomatic phrase is \relative f without octave indicators.
>>
>> oh, ok.
>>
>>>  quotes @code{''} and not one double quote @code{"}@tie{}!
>>>  @c " - keeps quotes in order for context-sensitive editor -td
>>>
>>> +If you carefully consider all the rules above and remember that the
>>> +octave of absolute pitches also is specified disregarding any
>>> +accidentals, one rather interesting consequence is that the first note
>>> +in @code{@w{\relative f}} music is interpreted just the same as in
>>> +absolute pitch mode.
>>> +
>>>  @subheading Durations (rhythms)
>>
>> Sounds great for notation/pitches.itely.  Feel free to push it to
>> pitches.itely directly.  But this is *not* appropriate for the
>> tutorial.  I will be very unhappy if you put it there.
>
> It already went in with the last batch of patches (I was stopping to get
> anywhere because changes happened faster than I could rebase and
> regtest).  Feel free to revert.
>
> However, this particular text was intended to be written in
> tutorial-speak and not tailored for the notation manual.  Notation-speak
> would be something like "Since octaves of absolute pitches are also
> established ignoring accidentals, @code{@w{\relative f}} is
> indistinguishable from having the first note specified as absolute
> pitch."
>
>
>> When users are still coming to grips with two single quotes '' vs
>> a double quote ", they're not going to be carefully considering
>> the specifications of disregarding interesting consequences
>> carefully.
>>
>>> and I don't see the point in hiding this information from beginners out
>>> of fear that they might like it.
>>
>> Trust me.  The tutorial should keep words to 3 syllables or less
>> if at all possible.
>
> How about:
> "Here is a neat trick: if you write @code{@w\relative f}}, the next
> note will look just like absolute pitch."
> Apart from "absolute", only monosyllabic words.
>
> Deal?

:D

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

do we want special versions of the accidentals for use with text?

[Janek Warchoł]

Hi,

I've noticed that accidental glyphs don't mix well with text: their
baseline is incorrect, and their size doesn't match the letters.  Look
at the chordnames resulting from input below: the accidentals are too
big.  If they were of correct height, they would become too thin and
generally too small.  Also, look at the figured bass: the accidentals
are totally unreadable - definately too small!  But if we simply
change font-size, they would become too high.
I think the solution is to create a shorter variaton of accidental
glyphs; an example in the attachment.  How do you like this idea?  Do
you think all accidentals should have shorter versions, or would it be
overkill to create for example a shorter version of 3-stemmed sharp or
arrowed flat?

cheers,
Janek

\chords { \set chordNameLowercaseMinor = ##t fis gis bes ces fis:m
gis:m es:m ces:m }

<<
  \new Voice { \clef bass dis4 c d ais g fis}
  \new FiguredBass {
\figuremode {
  < 6 >4 < 7\+ >8 < 6+ [_!] >
  < 6 >4 <6 5 [3+] >
  < _ >4 < 6 5/>4
}
  }
>>
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New engraver for braces (issue 4807053)

[Janek Warchoł]

2011/9/13  :
> On 2011/09/12 21:35:03, janek wrote:
>>
>> can you tell me what needs work in this patch?  I've read Mike's
>
> comments, but i
>>
>> don't understand what should be done.
>
> This patch contains many copy/paste from the arpeggio engraver. We
> obviously need a new grob, since the braces need some special grob
> parameters like font-encoding=fetaBraces. But this doesn't necessarily
> require to add an engraver that would be a copy/paste from
> arpeggio-engraver.
> My other wish is to add text to braces, so that it can be used for
> annotations.
> I am close to a good solution, but still need some time to finish it.
> I hope this will be finished in a few weeks.

Ok.  If you'd like me to help you, let me know.

cheers,
Janek

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

Re: Improves some parmesan noteheads. (issue 4639065)

[janek . lilypond]

Hi,

i've looked at latest screenshot attached to tracker issue and... wow!
It looks really great!
I have only small suggestions about some sizes.
You've put a lot of work into this!

thanks,
Janek


http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly
File ly/engraver-init.ly (right):

http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063
ly/engraver-init.ly:1063: \override Stem #'thickness = #2
I'd make them just a bit thinner, perhaps 1.8.  I think that 2 might get
too thick with smaller font-size (as font-size decreases, the relative
thickness increases).

http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):

http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode272
mf/parmesan-noteheads.mf:272: nm_red_holeheight := 2.5 linethickness;
I'd make this 3 linethickness.

http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode329
mf/parmesan-noteheads.mf:329: nm_width := staff_space#;
if i'm not mistaken and these are the height and width of half and
quarter noteheads, i'd make them very slightly bigger - something like
nm_height := 1.1 noteheight#;
329 nm_width := 1.05 staff_space#;

http://codereview.appspot.com/4639065/

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

Re: Improves some parmesan noteheads. (issue 4639065)

[bordage . bertrand]

Thanks for your reviews!

On 2011/09/12 19:16:26, benko.pal wrote:

http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode147

lily/mensural-ligature.cc:147: Direction stem_dir = stem ?

get_grob_direction

(stem) : CENTER;
this is unneeded: there are no stemmed notes within ligaturae.


I am a total ligature newbie. But I see some stemmed notes in
input/regression/mensural-ligatures.ly .

Of course, I agree that there's a bug. I fixed it in a new patch set.

Bertrand.

http://codereview.appspot.com/4639065/

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

Re: A few remarks concerning \relative

[David Kastrup]

Graham Percival  writes:

> On Mon, Sep 12, 2011 at 04:18:38PM +0200, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > I'm reluctant to add the suggestion of \relative f' {  to the
>> > tutorial since all the examples are variants of c.
>> 
>> Personally, I don't think \relative f' is all that interesting.  The
>> really idiomatic phrase is \relative f without octave indicators.
>
> oh, ok.
>
>>  quotes @code{''} and not one double quote @code{"}@tie{}!
>>  @c " - keeps quotes in order for context-sensitive editor -td
>>  
>> +If you carefully consider all the rules above and remember that the
>> +octave of absolute pitches also is specified disregarding any
>> +accidentals, one rather interesting consequence is that the first note
>> +in @code{@w{\relative f}} music is interpreted just the same as in
>> +absolute pitch mode.
>> +
>>  @subheading Durations (rhythms)
>
> Sounds great for notation/pitches.itely.  Feel free to push it to
> pitches.itely directly.  But this is *not* appropriate for the
> tutorial.  I will be very unhappy if you put it there.

It already went in with the last batch of patches (I was stopping to get
anywhere because changes happened faster than I could rebase and
regtest).  Feel free to revert.

However, this particular text was intended to be written in
tutorial-speak and not tailored for the notation manual.  Notation-speak
would be something like "Since octaves of absolute pitches are also
established ignoring accidentals, @code{@w{\relative f}} is
indistinguishable from having the first note specified as absolute
pitch."


> When users are still coming to grips with two single quotes '' vs
> a double quote ", they're not going to be carefully considering
> the specifications of disregarding interesting consequences
> carefully.
>
>> and I don't see the point in hiding this information from beginners out
>> of fear that they might like it.
>
> Trust me.  The tutorial should keep words to 3 syllables or less
> if at all possible.

How about:
"Here is a neat trick: if you write @code{@w\relative f}}, the next
note will look just like absolute pitch."
Apart from "absolute", only monosyllabic words.

Deal?

-- 
David Kastrup

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

Re: New engraver for braces (issue 4807053)

[bordage . bertrand]

On 2011/09/12 21:35:03, janek wrote:

can you tell me what needs work in this patch?  I've read Mike's

comments, but i

don't understand what should be done.


This patch contains many copy/paste from the arpeggio engraver. We
obviously need a new grob, since the braces need some special grob
parameters like font-encoding=fetaBraces. But this doesn't necessarily
require to add an engraver that would be a copy/paste from
arpeggio-engraver.
My other wish is to add text to braces, so that it can be used for
annotations.
I am close to a good solution, but still need some time to finish it.
I hope this will be finished in a few weeks.

Thanks,
Bertrand

http://codereview.appspot.com/4807053/

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

Re: A few remarks concerning \relative

[Graham Percival]

On Mon, Sep 12, 2011 at 04:18:38PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > I'm reluctant to add the suggestion of \relative f' {  to the
> > tutorial since all the examples are variants of c.
> 
> Personally, I don't think \relative f' is all that interesting.  The
> really idiomatic phrase is \relative f without octave indicators.

oh, ok.

>  quotes @code{''} and not one double quote @code{"}@tie{}!
>  @c " - keeps quotes in order for context-sensitive editor -td
>  
> +If you carefully consider all the rules above and remember that the
> +octave of absolute pitches also is specified disregarding any
> +accidentals, one rather interesting consequence is that the first note
> +in @code{@w{\relative f}} music is interpreted just the same as in
> +absolute pitch mode.
> +
>  @subheading Durations (rhythms)

Sounds great for notation/pitches.itely.  Feel free to push it to
pitches.itely directly.  But this is *not* appropriate for the
tutorial.  I will be very unhappy if you put it there.

When users are still coming to grips with two single quotes '' vs
a double quote ", they're not going to be carefully considering
the specifications of disregarding interesting consequences
carefully.

> and I don't see the point in hiding this information from beginners out
> of fear that they might like it.

Trust me.  The tutorial should keep words to 3 syllables or less
if at all possible.

Besides, we already get enough crap for having a tutorial that's
"too complicated" (see recent emails on -user).  There's an art to
documentation, and a lot of that art is in removing anything that
doesn't need to be there.  The tutorial is already 18 pages.

Cheers,
- Graham

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

Re: New engraver for braces (issue 4807053)

[janek . lilypond]

Hi Bertrand,

can you tell me what needs work in this patch?  I've read Mike's
comments, but i don't understand what should be done.  I have a strong
feeling that it should be patch-review.
It's a nice work and i'd like to see it implemented.

cheers,
Janek

http://codereview.appspot.com/4807053/

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

Re: A few remarks concerning \relative

[Janek Warchoł]

2011/9/12 Trevor Daniels :
> David Kastrup wrote Monday, September 12, 2011 3:18 PM
>
>> I'd propose something like
>>
>> +If you carefully consider all the rules above and remember that the
>> +octave of absolute pitches also is specified disregarding any
>> +accidentals, one rather interesting consequence is that the first note
>> +in @code{@w{\relative f}} music is interpreted just the same as in
>> +absolute pitch mode.
>
> I'd be happy with this addition,

+1

> but we also need
> a preface pointing out that, although c is usually
> specified for the absolute note in the manuals, this
> is not necessary and any note can be used.

might be good too.

cheers,
Janek

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

Re: Add some polyphonically directed grobs (issue 4387046)

[janek . lilypond]

On 2011/09/06 16:42:34, Bertrand Bordage wrote:

Ok, DynamicText and DynamicLineSpanner should be removed.
But what about the others?


I think they should be added.

cheers,
Janek

http://codereview.appspot.com/4387046/

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

Re: parser.yy et al: turn \partial and \skip into music functions. (issue 4969076)

[dak]

Pushed as 12449405eb89bb45d49d3dd3a37bdfcebda3ceaa.

http://codereview.appspot.com/4969076/

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

Re: How to add measure counters?

[Neil Puttock]

On 12 September 2011 20:45, Reinhold Kainhofer  wrote:

> Exactly, that was my idea. My problem is that I can't do it like in the
> percent repeat case, where we have percent-repeat-events (generated in the
> iterator), which start at the right moment and have the correct length. In the
> measure counter case everything is handled via context properties (or maybe a
> start/stop event), so there is no music event at the start of each measure and
> thus there is also no event from which I can obtain the length of one such
> measure-spanner.
>
> So, to formulate the question a little more precisely: In the engraver, for
> which events or grobs do I have to listen/acknowledge to get the left and the
> right column for each bar?
>
> I can't listen to bar lines, since there might be mid-measure barlines, or no
> barline at all (think longa or breve)...

Can't you just use the same timing information the
Multi_measure_rest_engraver uses?  It knows the current moment and the
length of each bar, so you only have to store columns (via
currentCommandColumn) and create a new counter grob for each bar.  You
just need to set the bounds at the right time, bearing in mind that
adjacent counters will need the same column but for opposite bound
directions.

Cheers,
Neil

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

Re: How to add measure counters?

[Reinhold Kainhofer]

Am Monday, 12. September 2011, 21:14:11 schrieb Neil Puttock:
> On 12 September 2011 20:03, Reinhold Kainhofer  
wrote:
> > Any idea how to implement this?
> 
> Shouldn't it just be a spanner whose bounds are the left column and
> right column for each bar?  Similar to a full-bar rest or percent
> repeat.

Exactly, that was my idea. My problem is that I can't do it like in the 
percent repeat case, where we have percent-repeat-events (generated in the 
iterator), which start at the right moment and have the correct length. In the 
measure counter case everything is handled via context properties (or maybe a 
start/stop event), so there is no music event at the start of each measure and 
thus there is also no event from which I can obtain the length of one such 
measure-spanner.

So, to formulate the question a little more precisely: In the engraver, for 
which events or grobs do I have to listen/acknowledge to get the left and the 
right column for each bar?

I can't listen to bar lines, since there might be mid-measure barlines, or no 
barline at all (think longa or breve)...

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: Improves some parmesan noteheads. (issue 4639065)

[benko . pal]

there are problems: the patch as is fails the mensural-ligatures
regtest.  see below.

p


http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc
File lily/mensural-ligature.cc (right):

http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode147
lily/mensural-ligature.cc:147: Direction stem_dir = stem ?
get_grob_direction (stem) : CENTER;
this is unneeded: there are no stemmed notes within ligaturae.

http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode151
lily/mensural-ligature.cc:151: -1);
this is bad: shapes within ligaturae depend not only on duration but on
context as well.  in other words: MLP_BREVIS doesn't necessarily
correspond to duration -1, etc.
use note_shape instead of duration_log: turn MLP_BREVIS into "M1",
MLP_LONGA into "M2" and MLP_MAXIMA into "M3".

perhaps we may change the MLP macros in mensural-ligature.hh to be
simpler.

http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode160
lily/mensural-ligature.cc:160: + (duration_log == -3 ? "lig" : "") +
"mensural";
put all computations in lines 145-160 into the block in lines 172-183.

http://codereview.appspot.com/4639065/

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

Re: How to add measure counters?

[Neil Puttock]

On 12 September 2011 20:03, Reinhold Kainhofer  wrote:

> Any idea how to implement this?

Shouldn't it just be a spanner whose bounds are the left column and
right column for each bar?  Similar to a full-bar rest or percent
repeat.

Cheers,
Neil

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

How to add measure counters?

[Reinhold Kainhofer]

I'm currently investigating how to implement measure counters (Bug 146):
http://code.google.com/p/lilypond/issues/detail?id=146

Compared to multi-measure rest numbers and to percent repeat numbers, there is 
a little complication: There is no grob to attach the numbers to (the percent 
repeat iterator creates one music object with the correct length for each 
percent/number, and the multi-measure rest also has the rest as the proper 
grob to attach to), and it is not straightforward to find the correct bounds 
for creating a spanner for each measure.

My current idea is to
1) start counting with an \startMeasureCounter event or context property
2) add a Measure_counter_engraver, which will create those counters
3) in each measure, create a spanner spanning the whole measure
4) create a MeasureCounter as a child of that spanner (centered).

Now, I don't know how to create a spanner that spans exactly one measure in an 
engraver... There might note be a barline (and there might be mid-measure 
barlines), so acknowledging bar lines is not possible. There might also be no 
notes at all at the beginning of a measure (e.g. with longas there are three 
measures without a note).

Any idea how to implement this?

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: parser.yy et al: turn \partial and \skip into music functions. (issue 4969076)

[David Kastrup]

bordage.bertr...@gmail.com writes:

> LGTM.
> Is there any way to also move \time, \key, \repeat and \alternative
> from the parser?

\time has a weird syntax with optional assignment
\key can take a \default argument
\repeat only takes an _optional_ \alternative

So no.  I am not sure about other candidates.

> http://codereview.appspot.com/4969076/

Currently my accumulated patches are getting out of hand.  I'll be
flushing out about a dozen of them once the regtests complete.

-- 
David Kastrup

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

Re: parser.yy et al: turn \partial and \skip into music functions. (issue 4969076)

[bordage . bertrand]

LGTM.
Is there any way to also move \time, \key, \repeat and \alternative from
the parser?
Bertrand

http://codereview.appspot.com/4969076/

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

Re: Finding commits

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: "Patrick McCarty" 
Cc: "Devel" 
Sent: Monday, September 12, 2011 8:51 AM
Subject: Re: Finding commits


- Original Message - 
From: "Patrick McCarty" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Monday, September 12, 2011 1:31 AM
Subject: Re: Finding commits


On Sun, Sep 11, 2011 at 8:52 AM, Phil Holmes  
wrote:
To verify that a "patch" Issue has been fixed, we check the commit. 
Using
the git web interface, is there a way to find the commit from the 
commitish?

I've tried but can't find a way, but I'm assuming I'm missing something.


There is no way to search for a committish (AFAIK) through the gitweb 
interface.


That said, notice that the committish is part of the URL for a
particular commit/commitdiff.  So, you can craft a URL to display the
commit you are looking for.

For example, the diff for commit
d63744cb5e26c4ec8e125a05f9f45654496c248b is shown here:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d63744cb5e26c4ec8e125a05f9f45654496c248b




Good point, Patrick.  I might make a small web page to produce that as a 
"search".


Here you go:

http://philholmes.net/lilypond/git/

very simple, no error handling, but works for me.

--
Phil Holmes



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

Re: Working on Issue 1135

[Graham Percival]

On Mon, Sep 12, 2011 at 04:40:42PM +0200, Marc Hohl wrote:
> They appear both in E and F - before the patch, they were listed in F only.
> Is this ok? Then the attached patch is probably ready to push.

thanks, pushed.

Cheers,
- Graham

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

Re: A few remarks concerning \relative

[Trevor Daniels]

David Kastrup wrote Monday, September 12, 2011 3:18 PM


I'd propose something like

+If you carefully consider all the rules above and remember that 
the

+octave of absolute pitches also is specified disregarding any
+accidentals, one rather interesting consequence is that the first 
note
+in @code{@w{\relative f}} music is interpreted just the same as 
in

+absolute pitch mode.


I'd be happy with this addition, but we also need
a preface pointing out that, although c is usually
specified for the absolute note in the manuals, this
is not necessary and any note can be used.

Trevor




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

Re: Working on Issue 1135

[Marc Hohl]

Am 12.09.2011 15:33, schrieb Graham Percival:

On Mon, Sep 12, 2011 at 02:32:56PM +0200, Marc Hohl wrote:

ok, but does that mean that issue 1135 can be closed?
As mentioned elsewhere, I replaced @findex by @funindex in

scm/document-identifiers.scm

but this seems to change nothing ...

That should make the functions appear in both
   Appendix E. LilyPond command index
   Appendix F. LilyPond command index

If that changes nothing, then specify *exactly* which index the
function does not appear in.

Ah, ok, I assumed they should apper in the internals index ...

They appear both in E and F - before the patch, they were listed in F only.
Is this ok? Then the attached patch is probably ready to push.

Regards,

Marc

Cheers,
- Graham



>From 853703d458fbb01ec4f8e57c2e3833414cfa80d2 Mon Sep 17 00:00:00 2001
From: Marc Hohl 
Date: Mon, 12 Sep 2011 16:39:04 +0200
Subject: [PATCH] Issue 1135: changing @findex to @funindex in scm/document-identifiers.scm

---
 scm/document-identifiers.scm |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scm/document-identifiers.scm b/scm/document-identifiers.scm
index 838de55..f83ba45 100644
--- a/scm/document-identifiers.scm
+++ b/scm/document-identifiers.scm
@@ -37,7 +37,7 @@
 	  (zip arg-names type-names)
 (format #f
  "@item @code{~a}~a~a
-@findex ~a
+@funindex ~a
 ~a
 "
  name-sym (if (equal? "" signature-str) "" " - ") signature-str
-- 
1.7.0.4

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

Re: A few remarks concerning \relative

[David Kastrup]

Graham Percival  writes:

> On Mon, Sep 12, 2011 at 11:44:33AM +0200, David Kastrup wrote:
>> Now I don't like having two different syntaxes for \relative,
>> but I guess Graham would kill me if I proposed just leaving
>> \relative { ... } in place with a new meaning.
>
> Yeah, that's so not happening.  Come up with a different name and
> we'll talk.
>
>> He'd have to learn absolute note names,
>
> Since I don't use lilypond myself, that's not an issue.
>
>> and every existing Lilypond source would become invalid or change its
>> meaning.
>
> That's the issue.
>
>
> I'm reluctant to add the suggestion of \relative f' {  to the
> tutorial since all the examples are variants of c.

Personally, I don't think \relative f' is all that interesting.  The
really idiomatic phrase is \relative f without octave indicators.

> I'm also reluctant to have a huge long discussion about something as
> fundamental as note entry without a *lot* more advertising (i.e.
> GLISS).  I'm willing to have a separate music function, documented in
> Notation but not Learning, which behaves like you're suggesting.  This
> could even become the default way to do stuff in lilypond 3.0.

Hm?  \relative f is already there.

I'd propose something like

commit 7de0ef57bddb16e422c8d79e7dc293be43a48cdd
Author: David Kastrup 
Date:   Mon Sep 12 03:08:18 2011 +0200

leaning.itely: add a musing about \relative f

diff --git a/Documentation/learning/tutorial.itely b/Documentation/learning/tutorial.itely
index 6752a3b..aa6c147 100644
--- a/Documentation/learning/tutorial.itely
+++ b/Documentation/learning/tutorial.itely
@@ -287,6 +287,12 @@ To change a note by two (or more!) octaves, we use multiple
 quotes @code{''} and not one double quote @code{"}@tie{}!
 @c " - keeps quotes in order for context-sensitive editor -td
 
+If you carefully consider all the rules above and remember that the
+octave of absolute pitches also is specified disregarding any
+accidentals, one rather interesting consequence is that the first note
+in @code{@w{\relative f}} music is interpreted just the same as in
+absolute pitch mode.
+
 @subheading Durations (rhythms)
 
 @cindex note durations

and I don't see the point in hiding this information from beginners out
of fear that they might like it.

-- 
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: A few remarks concerning \relative

[Graham Percival]

On Mon, Sep 12, 2011 at 11:44:33AM +0200, David Kastrup wrote:
> Now I don't like having two different syntaxes for \relative,
> but I guess Graham would kill me if I proposed just leaving
> \relative { ... } in place with a new meaning.

Yeah, that's so not happening.  Come up with a different name and
we'll talk.

> He'd have to learn absolute note names,

Since I don't use lilypond myself, that's not an issue.

> and every existing Lilypond source would become invalid or change its
> meaning.

That's the issue.


I'm reluctant to add the suggestion of \relative f' {  to the
tutorial since all the examples are variants of c.  I'm also
reluctant to have a huge long discussion about something as
fundamental as note entry without a *lot* more advertising (i.e.
GLISS).
I'm willing to have a separate music function, documented in
Notation but not Learning, which behaves like you're suggesting.
This could even become the default way to do stuff in lilypond
3.0.

Cheers,
- Graham

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

Re: Working on Issue 1135

[Graham Percival]

On Mon, Sep 12, 2011 at 02:32:56PM +0200, Marc Hohl wrote:
> ok, but does that mean that issue 1135 can be closed?
> As mentioned elsewhere, I replaced @findex by @funindex in
> 
> scm/document-identifiers.scm
> 
> but this seems to change nothing ...

That should make the functions appear in both
  Appendix E. LilyPond command index
  Appendix F. LilyPond command index

If that changes nothing, then specify *exactly* which index the
function does not appear in.

Cheers,
- Graham

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

Re: Improves some parmesan noteheads. (issue 4639065)

[lemzwerg]

LGTM

Werner

http://codereview.appspot.com/4639065/

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

Re: 2.15.10 regtests

[Graham Percival]

On Mon, Sep 12, 2011 at 08:53:01AM +0100, Phil Holmes wrote:
> I know (I think..)  James now does the regtest comparison for every
> patch.

He does not.  And even if he did, he would be comparing the
individual effects of each individual patch, not the total effect
of them all.  It's not impossible that two unrelated patches could
individually produce no problem, but break stuff when combined.

> I'm wondering whether that makes the version-version regtests
> less important anyway?

It means that there should be a lower chance of something being
wrong, but it's still important to check.


The existance of massive-change patches is problematic; a tiny
modification to some font can cause almost every regtest to show a
change.  We could consider "saving up" those patches, then having
a release which *only* includes those patches.  A cursory
examination should suffice to see that nothing has broken.
At the current rate of releases and patches, I'm envisioning
having a "font release" once every two months.
I'll include this in tomorrow's new GOP-PROP.

Cheers,
- Graham

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

Re: Working on Issue 1135

[Neil Puttock]

On 12 September 2011 13:47, Marc Hohl  wrote:

> I created a new directory, made a git repository from scratch,
> changed the one line and did
>
> make all
> make doc

Hmm, in that case, I'm not sure why it doesn't work.  I assume you
changed the offending line to this:

@funindex \\~a

Cheers,
Neil

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

Re: Working on Issue 1135

[David Kastrup]

Neil Puttock  writes:

> On 12 September 2011 13:49, David Kastrup  wrote:
>
>> Not as long as I have not checked and pushed appropriate changes.
>
> I don't see how that's relevant.  You've broken the way the argument
> list is documented for each function.  That has no bearing on the way
> music functions are indexed.

You are likely right.  I'll downgrade my panic one notch.

-- 
David Kastrup

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

Re: Working on Issue 1135

[Neil Puttock]

On 12 September 2011 13:49, David Kastrup  wrote:

> Not as long as I have not checked and pushed appropriate changes.

I don't see how that's relevant.  You've broken the way the argument
list is documented for each function.  That has no bearing on the way
music functions are indexed.

Cheers,
Neil

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

Re: Working on Issue 1135

[David Kastrup]

Neil Puttock  writes:

> On 12 September 2011 13:32, Marc Hohl  wrote:
>
>> ok, but does that mean that issue 1135 can be closed?
>> As mentioned elsewhere, I replaced @findex by @funindex in
>>
>> scm/document-identifiers.scm
>>
>> but this seems to change nothing ...
>
> Did you ensure it's rebuilt properly?

Not as long as I have not checked and pushed appropriate changes.

> IIUC you need to touch something like notation.tely to regenerate it.

-- 
David Kastrup


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

Re: Working on Issue 1135

[Marc Hohl]

Am 12.09.2011 14:41, schrieb Neil Puttock:

On 12 September 2011 13:32, Marc Hohl  wrote:


ok, but does that mean that issue 1135 can be closed?
As mentioned elsewhere, I replaced @findex by @funindex in

scm/document-identifiers.scm

but this seems to change nothing ...

Did you ensure it's rebuilt properly?  IIUC you need to touch
something like notation.tely to regenerate it.

I created a new directory, made a git repository from scratch,
changed the one line and did

make all
make doc

HTH,

Marc

Cheers,
Neil




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

Re: Working on Issue 1135

[Neil Puttock]

On 12 September 2011 13:32, Marc Hohl  wrote:

> ok, but does that mean that issue 1135 can be closed?
> As mentioned elsewhere, I replaced @findex by @funindex in
>
> scm/document-identifiers.scm
>
> but this seems to change nothing ...

Did you ensure it's rebuilt properly?  IIUC you need to touch
something like notation.tely to regenerate it.

Cheers,
Neil

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

Re: Working on Issue 1135

[Marc Hohl]

Am 12.09.2011 12:59, schrieb David Kastrup:

Janek Warchoł  writes:


2011/9/12 Marc Hohl:

Am 11.09.2011 22:35, schrieb Janek Warchoł:

[...]
The only thing that comes to my mind is that some settings from the
previous configuration of make (when there was no separate build/)
slipped to the current configuration.  The only way that i know to
solve such problems is to make from scratch (in this case it's delete
everything, copy the repository again, create separate build directory
and configure and make - of course since you'd be deleting everything,
you'd have to backup your work by creating patches and storing them
somewhere safe).  If this doesn't help, i don't know what can be done.
  However, i'm sure that someone on the -devel mailing list will know.

Ok, this time it worked -

Great!


but the index looks the same as before :-(

Do I understand issue 1135 right - the scheme functions should get listed
on out-www/offline-root/Documentation/internals/scheme-functions.html?

Or am I searching on the wrong place?

I'm not the one who can answer this question :(
I'm forwarding this to -devel.

You don't say from where you are forwarding this, and the quoted content
is not sufficient for guessing what problem you are talking about.

I tried to solve issue 1135 - it looked very much like an one-line
patch, changing @findex to @funindex in scm/document-identifiers.scm.

But compiling the docs from scratch is Yet Another Issue (tm) ;-)

I assumed from the description in
http://code.google.com/p/lilypond/issues/detail?id=1135
that these functions will be added to the index mentioned above,
but probably I was wrong.

Music function autodocumentation has been broken by my Scheme function
work.  I am currently checking a fix, but I don't have the fastest
computer on Earth.


Perhaps this is the culprit; I don't know.

HTH,

Marc


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

Re: Working on Issue 1135

[Marc Hohl]

Am 12.09.2011 12:56, schrieb Neil Puttock:

2011/9/12 Janek Warchoł:

2011/9/12 Marc Hohl:

Do I understand issue 1135 right - the scheme functions should get listed
on out-www/offline-root/Documentation/internals/scheme-functions.html?

Or am I searching on the wrong place?

I'm not the one who can answer this question :(
I'm forwarding this to -devel.

Nope, these are music functions.  They're documented in the appendices
to the Notation Reference via scm/document-identifiers.scm.

scheme-functions.html documents the exported scheme functions defined in c/c++.

ok, but does that mean that issue 1135 can be closed?
As mentioned elsewhere, I replaced @findex by @funindex in

scm/document-identifiers.scm

but this seems to change nothing ...

Marc



Cheers,
Neil




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

Re: Doc: Added \compoundMeter function to NR (issue 4837050)

[n . puttock]

LGTM.

http://codereview.appspot.com/4837050/

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

Re: Working on Issue 1135

[David Kastrup]

Janek Warchoł  writes:

> 2011/9/12 Marc Hohl :
>> Am 11.09.2011 22:35, schrieb Janek Warchoł:
>>>
>>> [...]
>>> The only thing that comes to my mind is that some settings from the
>>> previous configuration of make (when there was no separate build/)
>>> slipped to the current configuration.  The only way that i know to
>>> solve such problems is to make from scratch (in this case it's delete
>>> everything, copy the repository again, create separate build directory
>>> and configure and make - of course since you'd be deleting everything,
>>> you'd have to backup your work by creating patches and storing them
>>> somewhere safe).  If this doesn't help, i don't know what can be done.
>>>  However, i'm sure that someone on the -devel mailing list will know.
>>
>> Ok, this time it worked -
>
> Great!
>
>> but the index looks the same as before :-(
>>
>> Do I understand issue 1135 right - the scheme functions should get listed
>> on out-www/offline-root/Documentation/internals/scheme-functions.html?
>>
>> Or am I searching on the wrong place?
>
> I'm not the one who can answer this question :(
> I'm forwarding this to -devel.

You don't say from where you are forwarding this, and the quoted content
is not sufficient for guessing what problem you are talking about.

Music function autodocumentation has been broken by my Scheme function
work.  I am currently checking a fix, but I don't have the fastest
computer on Earth.

-- 
David Kastrup


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

parser.yy et al: turn \partial and \skip into music functions. (issue 4969076)

[n . puttock]

LGTM.


http://codereview.appspot.com/4969076/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

http://codereview.appspot.com/4969076/diff/1/ly/music-functions-init.ly#newcode794
ly/music-functions-init.ly:794: "Make a partial measure."
(_i "Make a partial measure.")

indent

http://codereview.appspot.com/4969076/diff/1/ly/music-functions-init.ly#newcode908
ly/music-functions-init.ly:908: (make-music 'SkipMusic
indent

needs docstring

http://codereview.appspot.com/4969076/

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

Re: Working on Issue 1135

[Neil Puttock]

2011/9/12 Janek Warchoł :
> 2011/9/12 Marc Hohl :

>> Do I understand issue 1135 right - the scheme functions should get listed
>> on out-www/offline-root/Documentation/internals/scheme-functions.html?
>>
>> Or am I searching on the wrong place?
>
> I'm not the one who can answer this question :(
> I'm forwarding this to -devel.

Nope, these are music functions.  They're documented in the appendices
to the Notation Reference via scm/document-identifiers.scm.

scheme-functions.html documents the exported scheme functions defined in c/c++.

Cheers,
Neil

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

Re: Working on Issue 1135

[Janek Warchoł]

2011/9/12 Marc Hohl :
> Am 11.09.2011 22:35, schrieb Janek Warchoł:
>>
>> [...]
>> The only thing that comes to my mind is that some settings from the
>> previous configuration of make (when there was no separate build/)
>> slipped to the current configuration.  The only way that i know to
>> solve such problems is to make from scratch (in this case it's delete
>> everything, copy the repository again, create separate build directory
>> and configure and make - of course since you'd be deleting everything,
>> you'd have to backup your work by creating patches and storing them
>> somewhere safe).  If this doesn't help, i don't know what can be done.
>>  However, i'm sure that someone on the -devel mailing list will know.
>
> Ok, this time it worked -

Great!

> but the index looks the same as before :-(
>
> Do I understand issue 1135 right - the scheme functions should get listed
> on out-www/offline-root/Documentation/internals/scheme-functions.html?
>
> Or am I searching on the wrong place?

I'm not the one who can answer this question :(
I'm forwarding this to -devel.

cheers,
Janek

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

Re: A few remarks concerning \relative

[David Kastrup]

Reinhold Kainhofer  writes:

> Am Monday, 12. September 2011, 12:01:53 schrieb David Kastrup:
>> Actually, I noticed just now that built-in music functions are
>> documented in lilypond-notation, and of course all of my work on music
>> functions has resulted in borking this documentation.
>
> The documentation is extracted from the music functions in 
> scm/document-identifiers.scm
>
> The question is whether we shall extend that to also document your new
> scheme-functions?

Sure.  I am on it.  I don't think there are any in Lilypond itself yet,
but that should not be a hindrance.

-- 
David Kastrup


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

Re: A few remarks concerning \relative

[Reinhold Kainhofer]

Am Monday, 12. September 2011, 12:01:53 schrieb David Kastrup:
> Actually, I noticed just now that built-in music functions are
> documented in lilypond-notation, and of course all of my work on music
> functions has resulted in borking this documentation.

The documentation is extracted from the music functions in 
scm/document-identifiers.scm

The question is whether we shall extend that to also document your new scheme-
functions?

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: regtests about very small differencies

[Reinhold Kainhofer]

Am Monday, 12. September 2011, 12:01:25 schrieb Janek Warchoł:
> Hi all,
> 
> I'm going to fix an issue where a note is misplaced by about 0.07
> staffspace.  I'll add a regtest for this, but how will we make sure
> that it won't be overlooked in the future?  When we watch a regtest
> comparison, it shows us the output in a quite low-resolution
> rasterized form; it will be impossible to spot the difference.  I can
> also think of some more issues that i'm planning to fix which involve
> such small changes.

Look at how beam-quanting (input/regression/beam-quant-standard.ly) does it: 
It prints the position of the beams, so that all changes in the position will 
lead to a change in the displayed text, which will be detectable in the 
regtests.

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: A few remarks concerning \relative

[David Kastrup]

Benkő Pál  writes:

 \relative x??? { x
 Namely start with the starting pitch.
>>>
>>> my two cents: I always do that.
>>
>> And my two cents: I never do that.
>> My rationale: in an (admittedly quite rare) case i want to paste the
>> contents of one relative to another relative, having various starting
>> pitches forces me to think how i should modify the octavation of the
>> first note when i move it around.  If everything is related to c* (or
>> another pitch, as long as it's the same everywhere), the calculation
>> is quite simple.
>
> but generally you have to relate to the last note before the paste position,
> so you can save thinking only when you paste from the very beginning
> of a relative block to the very beginning of another one.

\resetRelativeOctave f

to the rescue...

Actually, I noticed just now that built-in music functions are
documented in lilypond-notation, and of course all of my work on music
functions has resulted in borking this documentation.

Sigh.

-- 
David Kastrup

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

Re: A few remarks concerning \relative

[Benkő Pál]

> Seems like I am starting the wrong popular revolution.  I ask "Isn't
> \relative f nice?" and people say "Sure, but let's call it \relative { }
> instead, never mind that the name is taken."

> You are the second in a row, and if I understand "Basso Profundo"
> correctly (he has not followed up yet), his particular problem would
> have been non-existent with that default.
>
> Now I don't like having two different syntaxes for \relative, but I
> guess Graham would kill me if I proposed just leaving \relative { ... }
> in place with a new meaning.  He'd have to learn absolute note names,
> and every existing Lilypond source would become invalid or change its
> meaning.

no different syntaxes for anything, I agree.  I wouldn't mind a new name.
I tremendously like the idea to anchor a \relative block by writing the
first used pitch in absolute instead of introducing an absolute before-first
pitch used for nothing else.

p (o Basso profondo ma non troppo)

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

regtests about very small differencies

[Janek Warchoł]

Hi all,

I'm going to fix an issue where a note is misplaced by about 0.07
staffspace.  I'll add a regtest for this, but how will we make sure
that it won't be overlooked in the future?  When we watch a regtest
comparison, it shows us the output in a quite low-resolution
rasterized form; it will be impossible to spot the difference.  I can
also think of some more issues that i'm planning to fix which involve
such small changes.

cheers,
Janek

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

Re: Finding commits

[Reinhold Kainhofer]

Am Monday, 12. September 2011, 02:31:46 schrieb Patrick McCarty:
> On Sun, Sep 11, 2011 at 8:52 AM, Phil Holmes  wrote:
> > To verify that a "patch" Issue has been fixed, we check the commit.
> >  Using the git web interface, is there a way to find the commit from the
> > commitish? I've tried but can't find a way, but I'm assuming I'm missing
> > something.
> 
> There is no way to search for a committish (AFAIK) through the gitweb
> interface.

I would recomment the use of qgit anyway. There are packages for ubuntu 
available in the standard ubuntu distribution.


Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: A few remarks concerning \relative

[David Kastrup]

Benkő Pál  writes:

 \relative x??? { x
 Namely start with the starting pitch.
>>>
>>> my two cents: I always do that.
>>
>> Would you be tempted to use either
>> a) \relative f { x???
>> b) \relative f??? { x
>> (and which one?) if you realized it worked just the same?
>
> well, b) is nearer to my current idiom;
> I can see that a) has the advantage of not needing f at all,
> so the best would be
>
> \relative { x,
>
> (yes, I sing bass.)
>
> thanks for the suggestion, I stand convinced,

Seems like I am starting the wrong popular revolution.  I ask "Isn't
\relative f nice?" and people say "Sure, but let's call it \relative { }
instead, never mind that the name is taken."

You are the second in a row, and if I understand "Basso Profundo"
correctly (he has not followed up yet), his particular problem would
have been non-existent with that default.

Now I don't like having two different syntaxes for \relative, but I
guess Graham would kill me if I proposed just leaving \relative { ... }
in place with a new meaning.  He'd have to learn absolute note names,
and every existing Lilypond source would become invalid or change its
meaning.

-- 
David Kastrup


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

Re: A few remarks concerning \relative

[Benkő Pál]

>>> \relative x??? { x
>>> Namely start with the starting pitch.
>>
>> my two cents: I always do that.
>
> And my two cents: I never do that.
> My rationale: in an (admittedly quite rare) case i want to paste the
> contents of one relative to another relative, having various starting
> pitches forces me to think how i should modify the octavation of the
> first note when i move it around.  If everything is related to c* (or
> another pitch, as long as it's the same everywhere), the calculation
> is quite simple.

but generally you have to relate to the last note before the paste position,
so you can save thinking only when you paste from the very beginning
of a relative block to the very beginning of another one.

copy&paste is dangerous anyway - I'm generally bitten when the
first pasted note doesn't have an explicit duration.

p

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

Re: A few remarks concerning \relative

[Janek Warchoł]

2011/9/12 Benkő Pál :
>> \relative x??? { x
>> Namely start with the starting pitch.
>
> my two cents: I always do that.

And my two cents: I never do that.
My rationale: in an (admittedly quite rare) case i want to paste the
contents of one relative to another relative, having various starting
pitches forces me to think how i should modify the octavation of the
first note when i move it around.  If everything is related to c* (or
another pitch, as long as it's the same everywhere), the calculation
is quite simple.
An example: i'm typesetting simple SATB pieces from time to time.  At
the beginning my initial template setup was
soprano = \relative c'' { }
alto = \relative f' {  }
tenor = \relative c' {  }
bass = \relative f {  }
because i felt that these pitches are roughly in the middle of each
voice tessitura (and therefore using them minimized the chance of
having an octavation mark at the first note).  But then i've often ran
into a situation like this: I enter soprano part
soprano = \relative c'' { e, a c b g2 }
Then i look at the alto part and see "oh, it's the same" so i copy&paste it:
alto = \relative f' { e, a c b g2 }
aaand... oops, wrong octave!


2011/9/11 David Kastrup :
> It requires thinking if you have not yet come across it.  If the
> documentation (tutorial _and_ notation) mentions it prominently, it
> should be idiomatic enough.

That's quite possible.


2011/9/12 David Kastrup :
> I am still curious whether this idiom might be worth popularizing.

The more i think about it, the more i like it.

cheers,
Janek

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

Re: A few remarks concerning \relative

[Benkő Pál]

>>> \relative x??? { x
>>> Namely start with the starting pitch.
>>
>> my two cents: I always do that.
>
> Would you be tempted to use either
> a) \relative f { x???
> b) \relative f??? { x
> (and which one?) if you realized it worked just the same?

well, b) is nearer to my current idiom;
I can see that a) has the advantage of not needing f at all,
so the best would be

\relative { x,

(yes, I sing bass.)

thanks for the suggestion, I stand convinced,
p

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

Re: A few remarks concerning \relative

[David Kastrup]

Benkő Pál  writes:

>> \relative x??? { x
>> Namely start with the starting pitch.
>
> my two cents: I always do that.

Would you be tempted to use either
a) \relative f { x???
b) \relative f??? { x
(and which one?) if you realized it worked just the same?

I know Graham could not be tempted as he can't even remember what x???
means for x~=c, but I am still curious whether this idiom might be worth
popularizing.

-- 
David Kastrup

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

Re: A few remarks concerning \relative

[Benkő Pál]

> \relative x??? { x
> Namely start with the starting pitch.

my two cents: I always do that.

p

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

Re: 2.15.10 regtests

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, September 11, 2011 5:44 PM
Subject: Re: 2.15.10 regtests



On Sun, Sep 11, 2011 at 04:06:14PM +0100, Phil Holmes wrote:

Same problem as 2.15.9 - I think the change of spacing from the clef
to the first note means that almost every regtest is different.  I
get the same problem on my pixel comparator.  I can't go back to an
earlier version because of the clef change.


Hmm.  I'll upload 2.15.11, containing comparisons against 2.15.10
and 2.15.9.  The latter still shows tons of changes, so I don't
know if it'll help at all.

I was sorely tempted to call it a release candidate anyway, but in
the end I figured that I should a few days.


... BTW, with your fancy shiny computer, you /might/ want to try
the steps to regenerate regtests without a specific commit.  First
get your git repo into the state you want (i.e. release-2.15.9-1
but also reverting patch abcd1234), then follow these:
http://lilypond.org/doc/v2.15/Documentation/contributor/release-extra-notes
It won't be fun, but it's doable... and if you can make a regtest
comparison without the change-everything commit(s) with an hour or
two of fumbling around and recompiling stuff, you could save
people an hour (or more) of manually comparison regtests.

Cheers,
- Graham



I know (I think..)  James now does the regtest comparison for every patch. 
I'm wondering whether that makes the version-version regtests less important 
anyway?


--
Phil Holmes



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

Re: Finding commits

[Phil Holmes]

- Original Message - 
From: "Patrick McCarty" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Monday, September 12, 2011 1:31 AM
Subject: Re: Finding commits



On Sun, Sep 11, 2011 at 8:52 AM, Phil Holmes  wrote:

To verify that a "patch" Issue has been fixed, we check the commit. Using
the git web interface, is there a way to find the commit from the 
commitish?

I've tried but can't find a way, but I'm assuming I'm missing something.


There is no way to search for a committish (AFAIK) through the gitweb 
interface.


That said, notice that the committish is part of the URL for a
particular commit/commitdiff.  So, you can craft a URL to display the
commit you are looking for.

For example, the diff for commit
d63744cb5e26c4ec8e125a05f9f45654496c248b is shown here:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d63744cb5e26c4ec8e125a05f9f45654496c248b




Good point, Patrick.  I might make a small web page to produce that as a 
"search".


--
Phil Holmes



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

Re: 2.15.10 regtests

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> 
> Same problem as 2.15.9 - I think the change of spacing from the clef to the 
> first note means that almost every regtest is different.  

I looked through the 2.15.10 vs .9 comparison and recognized the cause of most 
changes  Those I didn't recognize are small and did not worry me.

Some explanation of fixes that changed more than one might guess:

The fix for issue 1856 (restoring 'fixed-space' after time-/key-signatures)
affects the tests where spacing wishes are averaged between a staff with
key/time sig and one without, such as most of the TabStaff tests.  These 
tests now show the staff with the key- or time- signature getting its 
fixed-space without compromise.

The fix for issue 724 (space between key-/time-signature and accidentals) 
also gives space before fingering, grace-notes, etc., and for some reason 
whole-measure rests.




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