date:20110123

I think I may be losing my mind.

Somebody this weekend posted, either in an email or in an issue comment,
that they were finally able to upload patches to Rietveld.

They had been having a problem because their Python was linking .scm files
with a mime-type of a ScreenCam file, rather than a text file.  When they
fixed that, they could successfully upload to Rietveld with git-cl.

Mike Solomon is having that same issue.  In trying to help him resolve it, I
looked for that email in -devel, -user, and bug-, but I couldn't find it.

Did anybody besides me see that email, or am I just dreaming it?

Thanks,


Carl


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

Re: Fixing issue 37 with extra position callback (issue3928041)

2011-01-23 Thread Han-Wen Nienhuys

On Mon, Jan 24, 2011 at 2:46 AM, Han-Wen Nienhuys  wrote:

>> I hope that my clearer code will assuage your fears that this affects
>> anything other than certain limited scenarios - in the regtests, it
>
> that is not so much my fear.  I am concerned with putting in code that
> we know is flawed in advance, when we have a much better mechanism to
> deal with this (see below).

Actually, there are some serious show-stoppers in this approach. See
the attached file. It appears your code kicks into action even if
there are no collisions.  We should probably double check if the
regression test detects beam changes accurately.  If not, we have a
serious hole in our coverage.

(I was going to look for more subtle failure cases, but this error
prevents me from demonstrating them.)

\new Staff \relative c' {
<<
 \new Voice
 { \stemUp c8[ c c c] c8[ c c c]
   c8[ c c c]
 }
  \new Voice {
\voiceThree s2
\stemUp e'8[ e e e]
\set fontSize = #-4 c8[ c c c]

  }
>>
}

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixing issue 37 with extra position callback (issue3928041)

2011-01-23 Thread Han-Wen Nienhuys

On Mon, Jan 24, 2011 at 12:58 AM,   wrote:

>> acknowledge manual beams only instead, then there's no need for this
>
> hack
>
> OK - but as far as I know, there is no way to have DECLARE_ACKNOWLEDGER
> (manual_beam) .  What would be the appropriate way to do this?

Look at the cause of the beam grob. If it is a BeamEvent, it is manual.

> http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1014
> lily/beam.cc:1014: pos[RIGHT] += offset;
> On 2011/01/23 18:11:08, hanwenn wrote:
>>
>> also, these offsets disregard carefully computed beam quantizations.
>
> Even though
>>
>> these are floats, the positions are not continuously variable.
>
> I don't quite get what you mean - the offsets tack on extra space iff
> there is a collision.  It keeps all of the quanting data.

I am talking about the case that there is a collision.  Look at Beam::quanting,

  Real straddle = 0.0;
  Real sit = (beam_thickness - slt) / 2;
  Real inter = 0.5;
  Real hang = 1.0 - (beam_thickness - slt) / 2;
  Real quants [] = {straddle, sit, inter, hang };

as you can see, for each end of the beam, there are 4 allowed
positions per staff space (with the inter being forbidden if the end
of the beam is inside the staff, iirc).

In the case of a collision, your code adds an amount derived from

  covered_grob->extent(Y)

which is an arbitrary amount.  Such offsets could cause horizontal
beams to appear like

    beam

   tiny sliver of whitespace that should not be there.
   staffline

for sloped beams, unquanted positions are not desirable either.

> I hope that my clearer code will assuage your fears that this affects
> anything other than certain limited scenarios - in the regtests, it

that is not so much my fear.  I am concerned with putting in code that
we know is flawed in advance, when we have a much better mechanism to
deal with this (see below).

> eliminates collisions in certain regtests that have them and leaves
> everything else alone.
>
> http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1015
> lily/beam.cc:1015: return ly_interval2scm (pos);
> On 2011/01/23 18:05:39, hanwenn wrote:
>>
>> it looks like this only handles the 1st collision found, and exits
>
> after
>>
>> circumventing the first one.  The risks are
>
>> * in case of multiple grobs, the resolution is dependent on the order
>
> of
>>
>> constructing the covered grobs list.  Unpredictable and arbitrary.
>
>> * that you will park the beam on top of something else, like the next
>
> grob you
>>
>> are skipping with this return.
>
>> * in the last case, you may even create a beam with enormous stems
>
> (ugly) that
>>
>> still has a collision.
>
>> Why not calculate all the locations of all covered grobs, and work
>
> collisions
>>
>> into the scores for beam positions?
>
>> See beam-quanting.cc; you'd have to add another scoring pass to
>> Beam::quanting().
>
> It does not disregard other collisions (check out the regtest).

Let me try to cook up some examples.

> I don't know beam quanting well enough - someone who knows how to do
> this better than I could integrate it in there.  For now, I believe that
> this method works well.

The quanting code is not that difficult to understand; it is actually
a lot easier to follow than most of the collision code, as it is
declarative: the code gives scores to configurations, and then there
is a separate step that picks the one with the minimum badness score.

You already have written most of the logic to implement the scoring version.

It requires a function that takes a (left-y, right-y) pair and
determines if the beam produced collides with a grobs. There is no
need to calculate how much to shift anything, and the scoring will
have the possibility to tilt the beam to avoid collisions, or to
shorten stems relative to the default; something that you are
foregoing by just shifting in the beam-direction.

> http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1015
> lily/beam.cc:1015: return ly_interval2scm (pos);
> On 2011/01/23 18:05:39, hanwenn wrote:
>>
>> it looks like this only handles the 1st collision found, and exits
>
> after
>>
>> circumventing the first one.  The risks are
>

I am sorry, I misread this code here.  You are completely right that
it handles multiple collisions.

> symmetry
>>
>> wrt up/down correct (which has been tricky in my experience).
>
> I do not believe the symmetry to be an issue.

Can you try make use of symmetry anyway, to keep our code base clean and tight?

+  if (dir == UP)
+offset = max (offset, temp_offset);
+  else
+offset = min (offset, temp_offset);

you could write

  minmax(dir, offset, temp_offset)

similarly,

+  if (dir == UP)
+{
+  if (y_val > beam_y1)
..
+  else
+{
+  if (y_val < beam_y1)

could be

  if (dir * (y_val - beam_y1) > 0)

-- 
H

Re: Fixing issue 37 with extra position callback (issue3928041)



http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1014
lily/beam.cc:1014: pos[RIGHT] += offset;
also, these offsets disregard carefully computed beam quantizations.
Even though these are floats, the positions are not continuously
variable.

http://codereview.appspot.com/3928041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)



http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1015
lily/beam.cc:1015: return ly_interval2scm (pos);
On 2011/01/23 18:05:39, hanwenn wrote:

it looks like this only handles the 1st collision found, and exits

after

circumventing the first one.  The risks are



* in case of multiple grobs, the resolution is dependent on the order

of

constructing the covered grobs list.  Unpredictable and arbitrary.



* that you will park the beam on top of something else, like the next

grob you

are skipping with this return.



* in the last case, you may even create a beam with enormous stems

(ugly) that

still has a collision.



Why not calculate all the locations of all covered grobs, and work

collisions

into the scores for beam positions?



See beam-quanting.cc; you'd have to add another scoring pass to
Beam::quanting().


doing it with beam quant scoring instead will free you of getting the
symmetry wrt up/down correct (which has been tricky in my experience).

http://codereview.appspot.com/3928041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)


Sorry, I got the author incorrect.

Thanks for looking into this, Mike!

http://codereview.appspot.com/3928041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)


Hi Carl,

thanks for diving into this!

I love the idea of handling beam collisions, but I think the design of
the backend code is flawed.  See my comments.


http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode972
lily/beam.cc:972: sw[LEFT] = covered_grob->relative_coordinate (commonx,
X_AXIS) + stencil->extent(X_AXIS)[LEFT] - x0;
why not use covered_grob->extent(common_x, X)[LEFT] instead?

the same for all other stencil->extent manipulations.

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode973
lily/beam.cc:973: sw[RIGHT] = covered_grob->relative_coordinate
(commony, Y_AXIS) + stencil->extent(Y_AXIS)[DOWN] - pos[LEFT];
* what is sw ?  can you rename to something more explanatory?

* you are mixing X and Y in an interval.  Shouldnt sw be an Offset ?

* Why is this code not symmetric in UP and DOWN, using flip() ?  This
looks error prone wrt collisions that work for upstems, but not for down
stems and vice-versa

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1015
lily/beam.cc:1015: return ly_interval2scm (pos);
it looks like this only handles the 1st collision found, and exits after
circumventing the first one.  The risks are

* in case of multiple grobs, the resolution is dependent on the order of
constructing the covered grobs list.  Unpredictable and arbitrary.

* that you will park the beam on top of something else, like the next
grob you are skipping with this return.

* in the last case, you may even create a beam with enormous stems
(ugly) that still has a collision.

Why not calculate all the locations of all covered grobs, and work
collisions into the scores for beam positions?

See beam-quanting.cc; you'd have to add another scoring pass to
Beam::quanting().

http://codereview.appspot.com/3928041/

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

Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)

2011-01-23 Thread k-ohara5a5a


Extended to cover the other issues that were fixed along with 1120.  The
regression test that /could/ have caught the breakage of issue 1120 is
revised so it will (more likely) catch any future breakage.


http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm#newcode261
scm/define-grobs.scm:261: (stencil . ,ly:text-interface::print)
On 2011/01/23 04:48:19, Keith wrote:

extra-spacing-height . (-0.5  . 0.5) for issue 1138

.. is not required for the regtest that raised issue 1138
(figured-bass-extenders-markup) Also, if the line above is added to
FiguredBass, it spaces complicated basso continuo too tightly.  Figured
Bass is more similar to NoteHeads than it is to Lyrics.

http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm#newcode586
scm/define-grobs.scm:586: (extra-spacing-height . (-0.5 . 0.5))
CueClef and CueEndClef were added after ee00488 so a simple revert
missed these.  They should match Clef.

http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm#newcode967
scm/define-grobs.scm:967: (stencil . ,system-start-text::print)
InstrumentName goes left of the staff.  No analogy with the melismata
issue 1120

http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm#newcode1183
scm/define-grobs.scm:1183: (stencil . ,ly:measure-grouping::print)
On 2011/01/23 04:48:19, Keith wrote:

extra-spacing-height analogous to Lyrics?

MeasureGrouping does not work analogously to Lyrics.  No need to extend
a fix for 1120 here.

http://codereview.appspot.com/4095041/diff/42001/input/regression/lyrics-melisma-beam.ly
File input/regression/lyrics-melisma-beam.ly (right):

http://codereview.appspot.com/4095041/diff/42001/input/regression/lyrics-melisma-beam.ly#newcode17
input/regression/lyrics-melisma-beam.ly:17: g4 d8[ b8 d8 g8]  g4
Moved some note heads so their stems interfere with lyrics, so that
these notes will move should something like issue 1120 recur.

http://codereview.appspot.com/4095041/diff/42001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/4095041/diff/42001/scm/define-grobs.scm#newcode178
scm/define-grobs.scm:178: (BalloonTextItem
Similar to Lyrics in its spacing needs

http://codereview.appspot.com/4095041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)


New patch set uploaded.

http://codereview.appspot.com/3928041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)

2011-01-23 Thread mtsolo


I made a lot of changes to get things looking more lilypond-y.

I also now have it better handling scenarios where the subdivisions are
wacky.  Check out:

\relative c' { << { b32 [ c,16 c'8 d,64 e'8. c,32 e'' ] } \\ { f8 [ c32
d'32 bes,,64 c'64 c64 c'128 ] } >> }

The low D is snug as a bug in a rug, as is the high C.

Cheers,
MS


http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly
File input/regression/beam-collision.ly (right):

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode1
input/regression/beam-collision.ly:1: \version "2.13.46"
On 2011/01/23 17:53:45, Graham Percival wrote:

2.13.47


Done.

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode2
input/regression/beam-collision.ly:2: \header{
On 2011/01/23 17:46:58, Neil Puttock wrote:

\header {


Done.

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode3
input/regression/beam-collision.ly:3: texidoc="@cindex Beam Collisions
On 2011/01/23 17:46:58, Neil Puttock wrote:

indent


Done.

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode12
input/regression/beam-collision.ly:12: \time 4/4
On 2011/01/23 17:46:58, Neil Puttock wrote:

indent


Done.

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode13
input/regression/beam-collision.ly:13: << { s128 e [ s cis, ] } \\ { b''
[ s b ] } >> r8..
On 2011/01/23 17:46:58, Neil Puttock wrote:

e[



etc.


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc
File lily/beam-collision-engraver.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode24
lily/beam-collision-engraver.cc:24: #include "item.hh"
On 2011/01/23 17:46:58, Neil Puttock wrote:

resort alphabetically


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode45
lily/beam-collision-engraver.cc:45: void process_acknowledged ();
On 2011/01/23 17:46:58, Neil Puttock wrote:

remove


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode52
lily/beam-collision-engraver.cc:52:
Beam_collision_engraver::stop_translation_timestep()
On 2011/01/23 17:46:58, Neil Puttock wrote:

timestep ()


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode54
lily/beam-collision-engraver.cc:54: for (vsize i=0; i <
covered_interior_grobs_.size (); i++)
On 2011/01/23 17:46:58, Neil Puttock wrote:

i = 0 (etc.)



Why use a separate vector?  There's no difference in processing, so it

would

make more sense to add all the grobs to covered_grobs_.


Key signatures, time signatures, and clefs that come in at the same
timestep as the beam's beginning will not come under the beam.  Thus,
they need to be treated differently than noteheads, which could
intersect with a beam that begins during their timestep.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode70
lily/beam-collision-engraver.cc:70: in auto beaming, end beams are
signaled with their beams at a later timestep.
On 2011/01/23 17:46:58, Neil Puttock wrote:

acknowledge manual beams only instead, then there's no need for this

hack

OK - but as far as I know, there is no way to have DECLARE_ACKNOWLEDGER
(manual_beam) .  What would be the appropriate way to do this?

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode96
lily/beam-collision-engraver.cc:96: active_beams_.erase
(active_beams_.begin() + j);
On 2011/01/23 17:46:58, Neil Puttock wrote:

begin ()


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode103
lily/beam-collision-engraver.cc:103:
Beam_collision_engraver::Beam_collision_engraver() {}
On 2011/01/23 17:46:58, Neil Puttock wrote:

engraver ()


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode106
lily/beam-collision-engraver.cc:106:
Beam_collision_engraver::process_acknowledged() {}
On 2011/01/23 17:46:58, Neil Puttock wrote:

remove


Done.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode115
lily/beam-collision-engraver.cc:115:
Beam_collision_engraver::acknowledge_accidental (Grob_info i)
On 2011/01/23 17:46:58, Neil Puttock wrote:

Since you're acknowledging noteheads, they already cache accidentals,

so you

could extract them later.


True - I was imagining the scenario where an accidental somehow shows up
w/o a notehead.  If this is inconceivable, I can change the code.

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode972
lily/beam.cc:972: sw[LEFT] = covered_grob->relative_coordinate (commonx,
X_AXIS) + stencil->extent(X_AXIS)[LEFT] - x0;
On 2011/01/23 18:0

Re: Fix issue 1376 ambitus two accidentals. (issue4099044)


LGTM.

Carl


http://codereview.appspot.com/4099044/

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

Re: mensural notation improvements (issue3797046)


Let me start by saying I know *nothing* about mensural notation.

The code looks good to me.

I found only one real issue:

LilyPond coding standards for C++ say that if there is only one
statement in an if clause, we omit {} around that clause.

I also had a question (and it probably doesn't matter much).  When I've
written font glyphs that are sometimes solid and sometimes hollow, I
always calculate both the inner and outer paths.  And then when I create
the glyph I only use the paths that are actually needed.  In your code,
you didn't create the path unless it was needed.  It probably makes no
difference at all, but I'd like to hear from the font gurus if there is
a preference.

My take was we only make the fonts at install, so the code doesn't need
to be optimized for speed, so I optimized for readability, which in my
mind, meant not putting the inner path inside a conditional.

Great work!

Thanks,

Carl



http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc
File lily/mensural-ligature-engraver.cc (right):

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode277
lily/mensural-ligature-engraver.cc:277: {
Remove unneeded {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode315
lily/mensural-ligature-engraver.cc:315: prev_primitive->set_property
("add-join", ly_bool2scm (true));
Remove unneeded {} from previous line and next line

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
lily/mensural-ligature-engraver.cc:380: {
Why put the {} in this case?

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode448
lily/mensural-ligature-engraver.cc:448: {
Remove {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode453
lily/mensural-ligature-engraver.cc:453: {
Remove {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode455
lily/mensural-ligature-engraver.cc:455: {
Remove {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode460
lily/mensural-ligature-engraver.cc:460: {
Remove {}

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

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode101
lily/mensural-ligature.cc:101: {
remove {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode144
lily/mensural-ligature.cc:144: flexa_width = robust_scm2double
(me->get_property ("flexa-width"), 2.0)
Remove {}

http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode221
lily/mensural-ligature.cc:221: {
Remove {}

http://codereview.appspot.com/3797046/

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

Re: Better support for beat slashes (multi-slash & mixed duration). (issue212048)


LGTM.

Carl


http://codereview.appspot.com/212048/

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

Re: Pentatonic Diatonic Transposition?

On 1/23/11 4:03 AM, "Trevor Daniels"  wrote:

> The code below seems to satisfy a request
> seen several times on -user.  Assuming the code
> is good I'd prefer to see this added to the LP
> distribution rather than the LSR.
> 
> What do you think?

Looks reasonable to me.

The code needs to be put in a .scm file (scm/modal-transpose.scm), and the
music function needs to go to ly/music-functions-init.ly.

The publically-accessible functions need to be define-public.

The indentation isn't right.

I think the errors should be turned into warnings.  If the transposer
pitches aren't valid, the transposer should just return the argument to be
transposed without transposition.  We shouldn't abort when we have the
chance to continue gracefully but with a warning.

make-extended-scale has a display-scheme-music call that I think should be
eliminated.

We need a shortened version of the demo for a regression test.

And we need a doc-section written.

But the code generally looks good to me.  I think we should get it added.

Thanks,

Carl

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

Re: patch organization

On Sun, Jan 23, 2011 at 05:13:07PM -0700, Carl Sorensen wrote:
> On 1/23/11 7:54 AM, "Graham Percival"  wrote:
> 
> > 4) patch-new: all new patches from contributors should have this label.
> 
> When a developer responds to the review that moved it from patch-new to
> patch-needs_work, does it go back to patch-new, or to patch-review?

Hmm... if the patch was previously patch-review, then it would go
back to patch-review; if the patch was previous patch-new, then
I'd say that it should go to patch-new.

Basically:
- people with git push ability will alternate between patch-review
  and patch-needs_work.  Go ahead and skip over the patch-new
  stage, unless you think that you may have made an "obvious"
  mistake.
- people without git push ability should have stuff as patch-new;
  I will change it to patch-review, patch-needs_work, or back
  to patch-new as appropriate.  (I'll be checking for "obvious"
  problems whenever the contributor makes a new version)

Cheers,
- Graham

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

Re: patch organization

On 1/23/11 7:54 AM, "Graham Percival"  wrote:

> 
> Developers: please bookmark this:
> http://code.google.com/p/lilypond/issues/listcan=2=label:patch-review
> 

This link is missing a ?, so it doesn't work.

Here's the right link:

HTH,

Carl

P.S. Thanks, Graham.  I think this will help.

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

Re: remove bar-size and replace its usage by bar-extent (issue4025044)


Looks good to me.

http://codereview.appspot.com/4025044/

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

Re: Fix critical regressions to lyric spacing (issue4061043)

I've responded to the comments in detail below.

Graham, relative to your comments on issues 1483 and 1486, both are
addressed in this patch.

The templates now have the lyrics attached properly to the staves, as do
the examples in the NR. This takes care of 1483.

The templates also have sufficient space for the lyrics at the top and
bottom of the score. This takes care of 1486.

For good measure, there is a snippet in the docs that demonstrates the
way to get the same spacing behavior as in 2.12.

As far as I can see, all of the problems associated with both issues are
resolved by this patch.

http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely#newcode70
Documentation/changes.tely:70: Lyrics above a staff must have their
@code{staff-affinity} set to
I think it is appropriate, because people who used the old vocal
templates will suddenly find that the soprano lyrics will be attached to
the previous system, and the tenor lyrics will be attached to the
womens' staff. One rational place for them to go to investigate is to
look at CHANGES.

What if, instead of a snippet, it referenced the appropriate section in
the Notation Reference?

I've gone ahead and added the reference; I'll change if you think it
necessary.

http://codereview.appspot.com/4061043/diff/1/Documentation/notation/vocal.itely
File Documentation/notation/vocal.itely (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/notation/vocal.itely#newcode1021
Documentation/notation/vocal.itely:1021: % lyrics above a stave should
have this override
Changed stave to staff

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/lyrics-old-spacing-settings.ly
File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/lyrics-old-spacing-settings.ly#newcode19
Documentation/snippets/new/lyrics-old-spacing-settings.ly:19: % VERSE
ONE
On 2011/01/23 14:20:35, Graham Percival wrote:

This differs from our normal indentation style... and in particular,

conflicts with the two-space indentation style that you used above in

the global

section... but meh, go ahead.

No, I'll fix it. This is what happens when I copy somebody else's code
and don't review it carefully. I made sure it worked, and that we had
the right header stuff, but didn't pay a lot of attention to the coding
style.

Thanks for the catch.

I've fixed the indentation, along with removing the unnecessary { s1 }
from each \new Lyrics construct.

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly
File
Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly
(right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly#newcode6
Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly:6:
%% Translation of GIT committish:
fa19277d20f8ab0397c560eb0e7b814bd804ecec
On 2011/01/23 22:55:54, Neil Puttock wrote:

remove all translation stuff

Done.

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template.ly
File Documentation/snippets/new/vocal-ensemble-template.ly (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template.ly#newcode6
Documentation/snippets/new/vocal-ensemble-template.ly:6: %% Translation
of GIT committish: fa19277d20f8ab0397c560eb0e7b814bd804ecec
On 2011/01/23 22:55:54, Neil Puttock wrote:

remove

Done.

http://codereview.appspot.com/4061043/diff/1/input/regression/baerenreiter-sarabande.ly
File input/regression/baerenreiter-sarabande.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/baerenreiter-sarabande.ly#newcode174
input/regression/baerenreiter-sarabande.ly:174:
obsolete-between-system-space = 25\mm system-system-spacing
#'basic-distance = #(/ obsolete-between-system-space staff-space)
score-system-spacing #'basic-distance = #(/
obsolete-between-system-space staff-space)
On 2011/01/23 14:20:35, Graham Percival wrote:

woah, what happened here? Could we get some linebreaks? (is this some

weird

osx-linebreaks+git malfunction?)

No, this is exactly the way convert-ly was intended to work for this
change, because in some cases the lines were commented.

This was discussed before the convert-ly rule was pushed.

The convert-ly rule was pushed in commit
4921d3518f4961abcfaf9ea243bec33efc943574 IIUC. The author was Keith
O'Hara and the committer was Graham Percival ;-)

But I will do a manual fix and make it the way it would be if we were
writing it from scratch.

Done.

http://codereview.appspot.com/4061043/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):

http://code

Re: Fix critical regressions to lyric spacing (issue4061043)


On 2011/01/23 09:09:09, Trevor Daniels wrote:

I think the templates would be improved with
system-system-spacing #'basic-distance = #20
added to \paper.  Otherwise the bass lyrics will be too
close to the soprano lyrics on the following system.


Done.  I also added top-system-spacing and last-bottom-spacing to take
care of the first and last systems of the score.

http://codereview.appspot.com/4061043/

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

Re: flags, beams and stem length in forced directions - output improvement

2011-01-23 Thread Janek Warchoł

2011/1/23 Werner LEMBERG :
>
>> umm... DVI output?  I've searched the manuals and didn't found how
>> to achieve it :/
>
> In one of my previous mails I gave you a recipe how to produce a
> `proof' version of the font using `mf' and `gftodvi'.  It doesn't help
> to get the exact outline since it is always based on the rasterized
> output of `mf', but it nicely shows the construction points (if
> possible).

Oh.
I've tried making a "proof" version of the font, but my insufficient
knowledge resulted in a failure :( So i gave up then, because it
seemed that i won't desperately need this...

>>>  FONTFORGE=foo mf2pt1 --rounding=0.0001    ,
>>>
>>> do you see the irregularity if you open the font with fontforge?
>>
>> Yes, i attach a screenshot. The font file is here:
>> http://www.mediafire.com/?hadr9nt5w5iqulb
>
> Looking at the image, I see that you haven't followed my advice since
> all overlapping outlines have been removed already.

Sorry for that!
I didn't quite know how to achieve what you said, it didn't work as i
expected :(
I'll try again tomorrow using your instructions.
Thank you very much for your help!
Janek

>  Using the
> `FONTFORGE=foo' environment setting while calling mf2pt1 prevents this
> so that you get the direct output of mf2pt1 without postprocessing
> with fontforge.  And yes, it should really be `foo', a non-existent
> program name.
>
> To set up mf2pt1 so that you can call it manually in an easy way,
> please execute
>
>  mpost -progname=mpost -ini mf2pt1.mp \\dump
>
> in the `mf' subdirectory (lilypond does this in the `mf/out' directory
> during `make all').
>
>>> You might try the recent CVS version of fontforge which has a lot
>>> of fixed issues.  Don't forget to pass `--enable-double' to the
>>> `configure' script of fontforge.
>>
>> Umm.. i'm afraid i don't understand :(
>
> 1. Check out the CVS sources of fontforge:
>
>     cvs -d:pserver:anonym...@fontforge.cvs.sourceforge.net:/cvsroot/fontforge 
> login
>     cvs -z3 
> -d:pserver:anonym...@fontforge.cvs.sourceforge.net:/cvsroot/fontforge co -P 
> fontforge
>
> 2. Change to the freshly created `fontforge' directory and configure
>   the program with
>
>     ./configure --enable-double
>
>   then build the program with
>
>     make
>
>   If the configure script complains it is necessary to install
>   additional packages to fulfill all dependencies (probably missing
>   `*-devel' packages so that the necessary C header files are
>   provided for compiling).  After installing a new package, simply
>   rerun `./configure --enable-double' until it succeeds.
>
> 3. Finally, install it with
>
>     sudo make install
>
> Assuming that you are originally using a fontforge package from your
> GNU/Linux distribution, your original binary is in /usr/bin/fontforge.
> Now you have a new, additional binary in `/usr/local/bin/fontforge'.
> You might add `--prefix=/your/preferred/directory/tree' to the
> configure script if you want a different location than `/usr/local'.
>
>
>    Werner
>

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

Re: Better support for beat slashes (multi-slash & mixed duration). (issue212048)


On 2011/01/22 20:29:17, Graham Percival wrote:


Patch looks great, passes regtests, and I built the docs from scratch

with it.

I think it's ready to be pushed.


Thanks.  I've deliberately left out doc changes (i.e., snippets, removal
of known issue and changes entry), but they'd follow soon after pushing.

Cheers,
Neil



http://codereview.appspot.com/212048/

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

Re: Add new merge-function.ly file for rests (issue4005046)


This is a nice hack, but the way it's currently implemented makes it
unsuitable to be merged.

The full-bar rests should be collected by an engraver (like the
Rest_collision_engraver), rather than using a hash table.

http://codereview.appspot.com/4005046/

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

Re: flags, beams and stem length in forced directions - output improvement

2011-01-23 Thread Janek Warchoł

2011/1/23 Carl Sorensen :
>
> Well, you could call calc_length to get the stem length, since you have the
> stem grob in the form of me, i.e.
>
> Real length = robust_scm2double (me->calc_length (smob));
>
> If you want to, you could try adding a saved value for the length so you
> don't have to make this call twice.
>
> That would involve modifying lily/include/stem.hh so that you had a private
> variable Real length_, and then at the end of Stem::calc_length you would do
> an assignment length_ = length; (just before return scm_from_double
> (length);)
>
> I would probably take the latter approach, since we have lots of stems in
> the music and I think it would be significantly faster, but only make a
> minor difference in storage space.

I've tried this but failed :(
Finally i've got it working the other way with some help from a friend of mine.
I see the end now :) and i'll post results when i finish, perhaps on wednesday.
I need to get rid of that spikes in flags now.

cheers,
Janek

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

Re: Fix critical regressions to lyric spacing (issue4061043)



http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely#newcode70
Documentation/changes.tely:70: Lyrics above a staff must have their
@code{staff-affinity} set to
I don't think this is appropriate here.

If it must stay, it needs a snippet to show how 'staff-affinity and
alignAboveContext are used.

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly
File
Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly
(right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly#newcode6
Documentation/snippets/new/vocal-ensemble-template-with-automatic-piano-reduction.ly:6:
%% Translation of GIT committish:
fa19277d20f8ab0397c560eb0e7b814bd804ecec
remove all translation stuff

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template.ly
File Documentation/snippets/new/vocal-ensemble-template.ly (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/vocal-ensemble-template.ly#newcode6
Documentation/snippets/new/vocal-ensemble-template.ly:6: %% Translation
of GIT committish: fa19277d20f8ab0397c560eb0e7b814bd804ecec
remove

http://codereview.appspot.com/4061043/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/mozart-hrn-3.ly#newcode51
input/regression/mozart-hrn-3.ly:51: obsolete-between-system-space = 20
\mm  system-system-spacing #'basic-distance = #(/
obsolete-between-system-space staff-space)  score-system-spacing
#'basic-distance = #(/ obsolete-between-system-space staff-space)
On 2011/01/23 14:20:35, Graham Percival wrote:

ditto.  hmm, maybe Keith's recent convert-ly patch has a problem?


It's deliberate, in case user scores have commented-out paper settings:
if these are converted, the obsolete-* variables are undefined, causing
Guile to complain.

http://codereview.appspot.com/4061043/

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

Re: Fix issue 1376 ambitus two accidentals. (issue4099044)


On 2011/01/23 18:21:11, Graham Percival wrote:


I've uploaded patchset 3, which I believe fixes all these.


Sorry Graham, my comment on the regtest should've been clearer: I wasn't
proposing we add that information to the test (since it only applies to
the new case fixed by this patch); it's just that the original text is
ambiguous (the part about two noteheads, since we can only see one in
the altered unison case).

Cheers,
Neil

http://codereview.appspot.com/4099044/

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

Re: Fix Issue 1035 -- Add context property for negative frets (issue4056041)


On 2011/01/23 19:11:46, c_sorensen_byu.edu wrote:


I could make a separate patch that moves it, and then compare against



that patch, if you think it's worth it


Thanks, but don't worry about it.  I'll try that myself once I've
applied the patch.

Cheers,
Neil

http://codereview.appspot.com/4056041/

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

Re: guile-config: inconsistent behaviour when run using lilypond configure under meta/uninstalled-env bash or fully installed Guile V1.9.14

2011-01-23 Thread Andy Wingo

On Thu 23 Dec 2010 21:42, Ian Hulin  writes:

> If we run lilypond ./configure under meta/uninstalled-env bash it
> hangs

Do you happen to have a stale guile-config file in the root of your
Guile checkout?

IIRC At some point guile-config moved from the root to meta, but is or
was generated, so an old build artifact could be hanging around.

Andy
-- 
http://wingolog.org/

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

Re: Add new merge-function.ly file for rests (issue4005046)

On 1/23/11 2:10 PM, "pkx1...@gmail.com"  wrote:

> Reviewers: carl.d.sorensen_gmail.com, Graham Percival,
> 
> Message:
> I have done all the changes (except added a reg test) and uploaded them.
> However this does not make cleanly. I am getting an error
> 
> current/scm/lily.scm:851:21: Unbound variable:
> merge-rests-on-positioning
> 
> Any help would be appreciated as I can't see any formatting errors.

You need to change (define (merge-rests-on-positioning ))
to 
(define-public (merge-rests-on-positioning ))

Do the same for the other function that is set as a property (I can't
remember exactly what it's called now).

HTH,

Carl


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

Re: Add new merge-function.ly file for rests (issue4005046)

2011-01-23 Thread pkx166h


Reviewers: carl.d.sorensen_gmail.com, Graham Percival,

Message:
I have done all the changes (except added a reg test) and uploaded them.
However this does not make cleanly. I am getting an error

current/scm/lily.scm:851:21: Unbound variable:
merge-rests-on-positioning

Any help would be appreciated as I can't see any formatting errors.


http://codereview.appspot.com/4005046/diff/1/ly/declarations-init.ly
File ly/declarations-init.ly (right):

http://codereview.appspot.com/4005046/diff/1/ly/declarations-init.ly#newcode31
ly/declarations-init.ly:31: \include "merge-function.ly"
On 2011/01/22 23:29:24, Carl wrote:

Once we move ly/merge-function.ly to scm/merge-rests.scm, this will

need to move

to scm/lily.scm as part of the definition of init-scheme-files (see

lines 393

and thereabouts.


Done.

http://codereview.appspot.com/4005046/diff/1/ly/merge-function.ly
File ly/merge-function.ly (right):

http://codereview.appspot.com/4005046/diff/1/ly/merge-function.ly#newcode1
ly/merge-function.ly:1: %{
On 2011/01/22 23:29:24, Carl wrote:

Once you have moved the commands out to ly/property-init.ly and
ly/engraver-init.ly, there's nothing but scheme code in this file, so

it should

become a scheme file.



Let's call it scm/merge-rests.scm.



Put a LilyPond copyright statement at the top of it (use one from any

other .scm

file), with Wilbert Berendsen and James Lowe as the copyright holders.


Done.

http://codereview.appspot.com/4005046/diff/1/ly/merge-function.ly#newcode8
ly/merge-function.ly:8: \include "merge-rests"
On 2011/01/23 00:07:33, Graham Percival wrote:

The whole point of this work is so that you _won't_ need to \include
merge-rests, so I'd omit this part.  :)


Done.

http://codereview.appspot.com/4005046/diff/1/ly/merge-function.ly#newcode118
ly/merge-function.ly:118: mergeRestsOn = {
On 2011/01/22 23:29:24, Carl wrote:

You have properly defined mergeRestsOn and mergeRestsOff in

ly/property-init.ly,

so they should be removed here.



mergeRests should be moved to ly/engraver-init.ly (and removed here).


Done.

http://codereview.appspot.com/4005046/diff/1/ly/property-init.ly
File ly/property-init.ly (right):

http://codereview.appspot.com/4005046/diff/1/ly/property-init.ly#newcode282
ly/property-init.ly:282: mergeRests = \layout {
On 2011/01/22 23:29:24, Carl wrote:

mergeRests should have the \layout{} block removed, so that it
can be included in anybody's layout block.



It should be in ly/engraver-init.ly.



Done.

Description:
Add new merge-function.ly file for rests

Taken from Tracker issue 1228

Function to merge rests that occur, for example, in two voices at
the same moment so that only a single rest is printed.

Added a new .ly file and included the functions in declarations-init.ly
and property-init.ly

This may not be the best way to implement this but I am hoping this is
a start at least.

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

Affected files:
  M ly/engraver-init.ly
  M ly/property-init.ly
  M scm/lily.scm
  A scm/merge-rests.scm



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

MIDI remapping

2011-01-23 Thread c.m.bryan

Hi everyone, I know the lilypond's main purpose isn't midi playback.  HOWEVER :)

I am wondering if I can hack the source so that I can change what midi
pitch values are output when it renders.  This is so that I can retune
the output with a software synth like csound or pd.

For instance, I would like the following sequence of notes:

c cih cis des deh d

to send to the midi file the following pitch values:

60 61 62 63 64 65

or something like that.  The specific values don't really matter:  I
just need *discrete* values without enharmonic equivalents, since the
synth can map those to any pitches I like!  I'm not too familiar with
lilypond's internals, but I do have a rusty programming background.
Could someone tell me if this is a monumental undertaking, and if not
where I should begin looking through the source?

Many thanks

Chris

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

Re: Using lyrics in a markup

2011-01-23 Thread Jan-Peter Voigt

Hello and thank you Jakob, hello list,

this piece is a great work. It compiles well in 2.13(.47 lilybuntu) and adds a 
very useful function to lily!
The .ly is attached again, because I think it is good to have it on the 
devel-list.
I would like to add it to LSR to have it in the main distro once. But it 
doesn't compile in 2.12(.3) stable, so it can't be uploaded right now.
What else should we do now?

Lilypond 2.12 complains about these lines:
...
#(define-markup-command (verse layout props lyrics) (ly:music?)
#:properties ((display-nl #f)
(make-line make-justify-markup))
...

by the way: Is this #:properties(()) notation a new functionality in 2.13? I 
haven't seen it before?
And is there a tutorial on all those comma- and accent-notations like in 
\override #`(make-line . ,make-wordwrap-markup) ?
I haven't found it in my scheme-tutorials.

Best regards,
Jan-Peter.

Am 23.01.2011 um 14:15 schrieb jakob lund:

> oops, forgot to reply to list (sorry about the extra spam Jan-Peter)
I don't mind ;-)
> 2011/1/23 jakob lund :
>> Hi again
>> 
>> After fiddling some more with this, I came up with a simple solution.
>> Instead of a string, a LineBreakEvent is inserted into the lyric --
>> neither \lyricmode or \addlyrics complain about this, and the events
>> doesn't seem to appear in the music output. This removes the need for
>> the filter function.
>> 
>> The lyrics->list function then recognizes the placeholders and
>> replaces them with occurrences of the indicator string, which the
>> verse command then uses to split the lines.
>> 
>> It seems to work well, try it out.
>> 


lyrics-to-text.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix Issue 1035 -- Add context property for negative frets (issue4056041)

On Jan 23, 2011, at 10:54 AM, "n.putt...@gmail.com"  
 wrote:

> Hi Carl,
>
> Is moving `determine-frets-and-strings' required for the patch to  
> work?
> It makes reviewing the changes difficult.
>

If I don't move it, I will need to add an argument for either the  
context or the property value.  I think it's much cleaner to move  
determine-frets-and-strings inside the scope where context is defined.

It probably should have been there in the first place.

I could make a separate patch that moves it, and then compare against  
that patch, if you think it's worth it

Thanks,

Carl

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

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

Re: Fix issue 1376 ambitus two accidentals. (issue4099044)


Reviewers: Neil Puttock,

Message:
On 2011/01/23 18:00:23, Neil Puttock wrote:

LGTM.


Thanks!

I've uploaded patchset 3, which I believe fixes all these.

Cheers,
- Graham

Description:
Fix issue 1376 ambitus two accidentals.

Add regtest for 1376 ambitus accidentals.

When an ambitus consists of a single note with different alterations,
two accidentals should be printed, no matter the key signature.

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

Affected files:
  M input/regression/ambitus.ly
  M lily/ambitus-engraver.cc


Index: input/regression/ambitus.ly
diff --git a/input/regression/ambitus.ly b/input/regression/ambitus.ly
index  
03c6a776fbeb89de671ed5518cb94a505632783b..ea715f0e994e7baa093af712033fc926d2c2c9ad  
100644

--- a/input/regression/ambitus.ly
+++ b/input/regression/ambitus.ly
@@ -1,10 +1,12 @@
-\version "2.12.0"
+\version "2.13.47"

 \header {
   texidoc = "Ambitus indicate pitch ranges for voices.

 Accidentals only show up if they're not part of key
 signature.  @code{AmbitusNoteHead} grobs also have ledger lines.
+The noteheads are printed in overstrike, so there's only one
+visible; the accidentals are prevented from colliding.
 "
 }

@@ -25,4 +27,8 @@ signature.  @code{AmbitusNoteHead} grobs also have ledger  
lines.

 \key d \major
 cis as'
   }
+  \new Staff \relative c' {
+\time 2/4
+c4 cis
+  }
 >>
Index: lily/ambitus-engraver.cc
diff --git a/lily/ambitus-engraver.cc b/lily/ambitus-engraver.cc
index  
d4bc39e7283c2cd9ebcb34944635f1c0cf0a6a76..221c1e8881ee950c70da5af60b29f202236d30ef  
100644

--- a/lily/ambitus-engraver.cc
+++ b/lily/ambitus-engraver.cc
@@ -178,7 +178,11 @@ Ambitus_engraver::finalize ()
? robust_scm2rational (scm_cdr (handle), Rational (0))
: Rational (0);

- if (sig_alter == p.get_alteration ())
+ const Pitch other = pitch_interval_[-d];
+
+ if (sig_alter == p.get_alteration ()
+ && !((p.steps () == other.steps ())
+  && (p.get_alteration () != other.get_alteration (
{
  accidentals_[d]->suicide ();
  heads_[d]->set_object ("accidental-grob", SCM_EOL);



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

Re: patch organization

2011/1/23 Graham Percival :
> Developers: please bookmark this:
> http://code.google.com/p/lilypond/issues/listcan=2&q=label:patch-review

A question mark character is missing in this URL inside listcan, it
should be list[question mark]can.  Hopefully this will work:

http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch-review

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Fix issue 1376 ambitus two accidentals. (issue4099044)


LGTM.




http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly
File input/regression/ambitus.ly (right):

http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly#newcode8
input/regression/ambitus.ly:8: Two noteheads are displayed even for a
note with two different
Tthe noteheads are printed in overstrike, so there's only one visible;
the accidentals are prevented from colliding.

http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly#newcode30
input/regression/ambitus.ly:30: \new Staff \relative c'{
c' {

http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):

http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc#newcode184
lily/ambitus-engraver.cc:184: && !((p.steps () == other.steps ())
indent

http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc#newcode185
lily/ambitus-engraver.cc:185: && (p.get_alteration () !=
other.get_alteration (
indent

http://codereview.appspot.com/4099044/

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

Re: Fix Issue 1035 -- Add context property for negative frets (issue4056041)


Hi Carl,

Is moving `determine-frets-and-strings' required for the patch to work?
It makes reviewing the changes difficult.

Cheers,
Neil

http://codereview.appspot.com/4056041/

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

Re: Fixing issue 37 with extra position callback (issue3928041)


I noticed another nitpick.


http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly
File input/regression/beam-collision.ly (right):

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode1
input/regression/beam-collision.ly:1: \version "2.13.46"
2.13.47

http://codereview.appspot.com/3928041/

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

Re: Implement compound time signatures (issue3992042)



http://codereview.appspot.com/3992042/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/3992042/diff/1/Documentation/changes.tely#newcode77
Documentation/changes.tely:77: c c c c c c c
c8

http://codereview.appspot.com/3992042/diff/1/Documentation/changes.tely#newcode79
Documentation/changes.tely:79: c c c c c c c4 c8 c c
c8

http://codereview.appspot.com/3992042/diff/1/input/regression/compound-time-signatures.ly
File input/regression/compound-time-signatures.ly (right):

http://codereview.appspot.com/3992042/diff/1/input/regression/compound-time-signatures.ly#newcode20
input/regression/compound-time-signatures.ly:20: \repeat unfold 10 c8
\repeat unfold 20 c16\break
c16 \break

etc.

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

http://codereview.appspot.com/3992042/diff/1/ly/music-functions-init.ly#newcode219
ly/music-functions-init.ly:219: "Create compound time signatures. The
argument is a Scheme list of "
indent

(_i "one long docstring")

splitting the description up into separate strings means they're all
discarded apart from the first one:

#(display
  (procedure-documentation
   (ly:music-function-extract compoundMeter)))

-> Create compound time signatures. The argument is a Scheme list of

http://codereview.appspot.com/3992042/diff/1/ly/music-functions-init.ly#newcode234
ly/music-functions-init.ly:234: \once \override Staff.TimeSignature
#'stencil = #ly:text-interface::print
#(lambda (grob)
   (grob-interpret-markup grob (format-compound-time $args)))

http://codereview.appspot.com/3992042/diff/1/ly/music-functions-init.ly#newcode235
ly/music-functions-init.ly:235: \once \override Staff.TimeSignature
#'text = #(format-compound-time $args)
remove

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm
File scm/time-signature-settings.scm (right):

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode309
scm/time-signature-settings.scm:309:
;
;;;

etc.

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode313
scm/time-signature-settings.scm:313: (let* ((ll (reverse l)))
let

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode317
scm/time-signature-settings.scm:317: (join-markups (cons (car remaining)
(cons m markups)) (cdr remaining))
indent

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode320
scm/time-signature-settings.scm:320: ; Use a centered-column inside a
left-column, because the centered column
;;

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode321
scm/time-signature-settings.scm:321: ; moves its reference point to the
center, which the left-column undoes.
;;

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode334
scm/time-signature-settings.scm:334: (let* ((sigs (map
format-time-fraction time-sig)))
let

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode357
scm/time-signature-settings.scm:357: (let* ((sigs (map
calculate-time-fraction time-sig)))
let

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode361
scm/time-signature-settings.scm:361: (add-moment (ly:moment-add moment
(car remaining)) (cdr remaining))
indent

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode379
scm/time-signature-settings.scm:379: ((not (pair? time-sig)) 4)
indent

http://codereview.appspot.com/3992042/diff/1/scm/time-signature-settings.scm#newcode393
scm/time-signature-settings.scm:393: ; Normalize to given beat, extract
the beats and join them to one list
;;

http://codereview.appspot.com/3992042/

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

Re: Fixing issue 37 with extra position callback (issue3928041)


Looks good, but there's still some excessive beam translation in
slur-scoring.ly.


http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly
File input/regression/beam-collision.ly (right):

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode2
input/regression/beam-collision.ly:2: \header{
\header {

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode3
input/regression/beam-collision.ly:3: texidoc="@cindex Beam Collisions
indent

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode12
input/regression/beam-collision.ly:12: \time 4/4
indent

http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode13
input/regression/beam-collision.ly:13: << { s128 e [ s cis, ] } \\ { b''
[ s b ] } >> r8..
e[

etc.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc
File lily/beam-collision-engraver.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode24
lily/beam-collision-engraver.cc:24: #include "item.hh"
resort alphabetically

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode45
lily/beam-collision-engraver.cc:45: void process_acknowledged ();
remove

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode52
lily/beam-collision-engraver.cc:52:
Beam_collision_engraver::stop_translation_timestep()
timestep ()

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode54
lily/beam-collision-engraver.cc:54: for (vsize i=0; i <
covered_interior_grobs_.size (); i++)
i = 0 (etc.)

Why use a separate vector?  There's no difference in processing, so it
would make more sense to add all the grobs to covered_grobs_.

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode70
lily/beam-collision-engraver.cc:70: in auto beaming, end beams are
signaled with their beams at a later timestep.
acknowledge manual beams only instead, then there's no need for this
hack

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode96
lily/beam-collision-engraver.cc:96: active_beams_.erase
(active_beams_.begin() + j);
begin ()

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode103
lily/beam-collision-engraver.cc:103:
Beam_collision_engraver::Beam_collision_engraver() {}
engraver ()

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode106
lily/beam-collision-engraver.cc:106:
Beam_collision_engraver::process_acknowledged() {}
remove

http://codereview.appspot.com/3928041/diff/30001/lily/beam-collision-engraver.cc#newcode115
lily/beam-collision-engraver.cc:115:
Beam_collision_engraver::acknowledge_accidental (Grob_info i)
Since you're acknowledging noteheads, they already cache accidentals, so
you could extract them later.

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode969
lily/beam.cc:969: Stencil *stencil = unsmob_stencil
(covered_grob->get_property ("stencil"));
use

grob->is_live ()

then

grob->extent (common, axis)

instead of extracting stencil

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode974
lily/beam.cc:974: width = stencil->extent(X_AXIS)[RIGHT] -
stencil->extent(X_AXIS)[LEFT];
= extent (X_AXIS).length ()

http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode979
lily/beam.cc:979: height = stencil->extent(Y_AXIS)[UP] -
stencil->extent(Y_AXIS)[DOWN];
= extent (Y_AXIS).length ()

http://codereview.appspot.com/3928041/diff/30001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/3928041/diff/30001/scm/define-grob-properties.scm#newcode972
scm/define-grob-properties.scm:972: (covered-grobs ,ly:grob-array? "Note
heads that could potentially
Grobs

http://codereview.appspot.com/3928041/diff/30001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/3928041/diff/30001/scm/define-grobs.scm#newcode380
scm/define-grobs.scm:380: ly:beam::move-to-avoid-collisions
fix indent (tabs)

http://codereview.appspot.com/3928041/

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

Re: critical issues

On Sun, Jan 23, 2011 at 10:29:11AM -0500, Boris Shingarov wrote:
> The Lilypond project has a very specific set of objectives.  There
> is a defined set of procedures, a roadmap, a set of criteria of
> what is acceptable to go into the codebase, etc.

This is true of any (well-organized) project.

> When these rules contradict Lilypond rules, I
> follow the history research project's rules, not the Lilypond
> project's rules, because it is the music history research project
> that pays me.

That is entirely appropriate.  :)

> What they (and
> your Norwegian friends with their 17th century songs) care about,
> is whether or not it is possible to typeset Norwegian lyrics.
> Which it isn't -- and it's not even Lilypond's fault: SRFI-13
> in Guile does not work with Unicode.

eh?  We've had utf-8 lyrics for a while.  Anyway, that's an aside.

> So we have all this work done, but it would be an even bigger
> effort to merge it back.

This is a general problem with all software projects --
commercial, open source, in-house, world-wide, etc.  I've read
comments on programming forums or blogs saying that it takes 5
times the effort to merge something upstream than it does to
implement it in the first place.  There's lots of discussion
online about sending linux kernel patches upstream, or gcc
patches, etc.

> However, I am making aggressive steps to change this.  As we
> attract more attention from serious organizations, we get into
> position to bring forward some conditions for the next project.
> Namely, it will become imperative that all contributions get
> merged back into the community codebase.

Yes.

Basically, it's a trade-off.  If you work by yourself (or with a
small group of programmers), you can do whatever you want.  Focus
on just the features you want, break other stuff, use shortcuts
that could potentially cause problems later on but aren't relevant
yet, etc.  There's nothing wrong with this -- I work in this
manner quite often on my own personal research projects.

However, if you work by yourself, then it's more difficult to
share your code with other people (if you want to), and you can't
get improvements that other people have made (if you care about
those).

Now, in your case, your group doesn't care about piano music or
orchestra stuff.  That's totally fine!  But what if the guile 2.0
change could speed up your processing?  Or maybe your group could
benefit from Benko Pal's "black mensural notation and coloratio in
white mensural notation" work?  Well, the more your source tree
diverges from the main lilypond git tree, the harder it will be to
get those changes.

*shrug*
I'm not saying that it's worth trying to merge your patches.
That's really a question of how much work you want to do on
general maintenance, how long you think your group will be working
on this projects (or related future ones), etc etc.  In the very
long term, I think that merging things with main git will be less
work.  Once we accept a patch, we'll turn down other patches that
break your features, so that aspect of maintenance is now *our*
problem (or the next patch submitter's problem), not yours.

However, by "very long term", I'm thinking "5-10 years".  If
you're only doing a 2-year project, with regular deadlines, and
don't expect to be doing anything else like this after 2 years,
then I honestly think it would be irrational of you to spend
time+effort merging patches with main lilypond git.

As you know, we're trying to make it easier for contributors,
easier to discuss+merge new features, etc., but it's not an easy
process  If it's not worth merging stuff now, it might still be
worth it in 6 months.  This is really a question between you and
the people who sign your paychecks... another option might be to
allocate a short amount of time (say, 2 hours a week?) to spend on
merging patches.  That way, at least you (and your bosses) know
how much time you'll lose on this task.

Cheers,
- Graham

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

Re: remove bar-size and replace its usage by bar-extent (issue4025044)


Looks good to me!

NB: I'm not vouching for the quality of the scheme or C++ code; that's
outside of my expertise.  But the .ly files look fine, and the results
(in the form of the regtest comparison) look fine.

http://codereview.appspot.com/4025044/

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

Re: remove bar-size and replace its usage by bar-extent (issue4025044)

2011-01-23 Thread benko . pal


On 2011/01/23 15:00:28, Graham Percival wrote:

Passes regtests, but a few minor nitpicks.


thanks, Graham; all observations implemented.

http://codereview.appspot.com/4025044/

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

Re: critical issues

2011-01-23 Thread Boris Shingarov


On 11-01-01 03:24 AM, Graham Percival wrote:

or an
art history / research grant.  I think the latter is more
likely... for example, if somebody got a grant to typeset 17th
century Norweigan folk songs, and decided to use lilypond, and
spent x% of the grant towards "improving community-oriented tools
for folk music archival", etc.

This is exactly what we have been doing here for a while.  In
act, it absolutely amazes me how closely you are describing our
project.  Only 100 years off (16th century instead of 17th),
and only a few hundred kilometers off.

But as I was trying to explain last summer, there are some problems.

The Lilypond project has a very specific set of objectives.  There
is a defined set of procedures, a roadmap, a set of criteria of
what is acceptable to go into the codebase, etc.

The music history research project, has its own set of objectives.
And its own set of rules.  And procedures.  And criteria of what
is acceptable.  When these rules contradict Lilypond rules, I
follow the history research project's rules, not the Lilypond
project's rules, because it is the music history research project
that pays me.  How contradictory are these rules, and how big is
the problem?

Well on one hand, none of today's Critical Issues in Lilypond,
are on the list of priorities for our project.  So even if we had
20 full-time developers, it wouldn't help with releasing the next
stable version.

On the other hand, we have implemented some major new
functionality.  Seamless markup-to-embedded-score integration,
automatic endnotes, merging and visual indication of used sources,
and a lot of other things.  Can it be contributed back?  Hardly
in its current form.  It causes a ton of regressions: basically,
it does not work on anything but Gregorian plainchant.  It will
immediately crash on any piano music or orchestral music.  Will
I fix it?  Not unless someone pays me to, and I know the music
historians will not, because they don't care.  What they (and
your Norwegian friends with their 17th century songs) care about,
is whether or not it is possible to typeset Norwegian lyrics.
Which it isn't -- and it's not even Lilypond's fault: SRFI-13
in Guile does not work with Unicode.

So we have all this work done, but it would be an even bigger
effort to merge it back.  Who will do it?  In the current
situation, I don't know.

However, I am making aggressive steps to change this.  As we
attract more attention from serious organizations, we get into
position to bring forward some conditions for the next project.
Namely, it will become imperative that all contributions get
merged back into the community codebase.  It still does not
mean helping with things like releasing the next stable version
of Lilypond, or similarly, with any part of Lilypond agenda;
although I am not sure if it is a bad thing -- if we want to
transition from being "a volunteer project with limited
resources" to "professional open-source", we will need to face
the fact that there are things which customers are willing to
pay for, and things which no-one finds important enough to
either work on themselves or pay for.

But first we will have to be successful to engage in the new
project.  It is still unclear whether it will happen or not.
I will keep you posted.

Boris



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

Re: remove bar-size and replace its usage by bar-extent (issue4025044)


Passes regtests, but a few minor nitpicks.


http://codereview.appspot.com/4025044/diff/10001/input/regression/bar-extent.ly
File input/regression/bar-extent.ly (right):

http://codereview.appspot.com/4025044/diff/10001/input/regression/bar-extent.ly#newcode1
input/regression/bar-extent.ly:1: \version "2.12.3"
I think this should be 2.13.47 ?

http://codereview.appspot.com/4025044/diff/10001/input/regression/bar-extent.ly#newcode2
input/regression/bar-extent.ly:2:
Sorry for missing this earlier: we need a \header { \texidoc=""}} thing.
 Take a look at any of the other regtests.  :)

http://codereview.appspot.com/4025044/diff/10001/input/regression/drums.ly
File input/regression/drums.ly (right):

http://codereview.appspot.com/4025044/diff/10001/input/regression/drums.ly#newcode10
input/regression/drums.ly:10: \version "2.13.46"
2.13.47

http://codereview.appspot.com/4025044/diff/10001/input/regression/grid-lines.ly
File input/regression/grid-lines.ly (right):

http://codereview.appspot.com/4025044/diff/10001/input/regression/grid-lines.ly#newcode8
input/regression/grid-lines.ly:8: \version "2.13.46"
2.13.47

http://codereview.appspot.com/4025044/diff/10001/input/regression/lyrics-bar.ly
File input/regression/lyrics-bar.ly (right):

http://codereview.appspot.com/4025044/diff/10001/input/regression/lyrics-bar.ly#newcode1
input/regression/lyrics-bar.ly:1: \version "2.13.46"
2.13.47

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

http://codereview.appspot.com/4025044/diff/10001/ly/engraver-init.ly#newcode19
ly/engraver-init.ly:19: \version "2.13.46"
2.13.47

http://codereview.appspot.com/4025044/

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

patch organization

So I've declared myself Patch Meister for the immediate future.  Once
2.14 is out, we'll have a discussion about how this should work, and
find somebody else to do it.  Until then, just roll with it.

I've replaced label:patch with a few subcategories on the google issue tracker.

1)  patch-review: the patch has nothing "obviously" wrong with it.
"obvious" means a failure to apply to git master, failing regtests,
debugging code, etc.  In short, it means that the patch is ready for a
serious review.

Developers: please bookmark this:
http://code.google.com/p/lilypond/issues/listcan=2&q=label:patch-review

it's a list of all patches that need review.  The goal is that this
list should have 0 issues.
NB: I am slowly working through the backlog, checking patches, etc.
Please DO NOT add your patch to this list unless you have git push
ability.  Contributors: please be patient.  I'll get to your patch.

2) patch-needs_work: after a problem(s) have been found with a patch,
we'll change the patch-review label to patch-needs_work.  It should be
obvious to everybody (potential reviewers, and the patch author) that
we're waiting for the submitter to take action.

3) patch-abandoned: if we don't hear anything from the submitter after
a few months, and/or if the submitter annouces that he's giving up,
I'll switch patch-needs_work to patch-abandoned.

4) patch-new: all new patches from contributors should have this label.


Cheers,
- Graham

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

Re: Fw: Pentatonic Diatonic Transposition?

On Sun, Jan 23, 2011 at 11:03:55AM -, Trevor Daniels wrote:
> The code below seems to satisfy a request
> seen several times on -user.  Assuming the code
> is good I'd prefer to see this added to the LP
> distribution rather than the LSR.

Sure.  Please create a patch in the way that James Lowe is
currently doing for merging rests.  Or just wait until he's
finished with that patch, and then he'll probably be willing to do
this one in the same way (especially since he'll be more familiar
with the procedure).

Cheers,
- Graham

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

Re: Fix critical regressions to lyric spacing (issue4061043)


I think we have a convert-ly problem.


http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/lyrics-old-spacing-settings.ly
File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right):

http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/lyrics-old-spacing-settings.ly#newcode19
Documentation/snippets/new/lyrics-old-spacing-settings.ly:19: % VERSE
ONE
This differs from our normal indentation style... and in particular, it
conflicts with the two-space indentation style that you used above in
the global section... but meh, go ahead.

We'll have an auto-ly-indenter soon, so let's not fuss with this
manually.

http://codereview.appspot.com/4061043/diff/1/input/regression/baerenreiter-sarabande.ly
File input/regression/baerenreiter-sarabande.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/baerenreiter-sarabande.ly#newcode174
input/regression/baerenreiter-sarabande.ly:174:
obsolete-between-system-space = 25\mm  system-system-spacing
#'basic-distance = #(/ obsolete-between-system-space staff-space)
score-system-spacing #'basic-distance = #(/
obsolete-between-system-space staff-space)
woah, what happened here?  Could we get some linebreaks? (is this some
weird osx-linebreaks+git malfunction?)

http://codereview.appspot.com/4061043/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/mozart-hrn-3.ly#newcode51
input/regression/mozart-hrn-3.ly:51: obsolete-between-system-space = 20
\mm  system-system-spacing #'basic-distance = #(/
obsolete-between-system-space staff-space)  score-system-spacing
#'basic-distance = #(/ obsolete-between-system-space staff-space)
ditto.  hmm, maybe Keith's recent convert-ly patch has a problem?

http://codereview.appspot.com/4061043/diff/1/input/regression/page-spacing.ly
File input/regression/page-spacing.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/page-spacing.ly#newcode71
input/regression/page-spacing.ly:71: obsolete-between-system-space = 1.0
 system-system-spacing #'basic-distance = #(/
obsolete-between-system-space staff-space)  score-system-spacing
#'basic-distance = #(/ obsolete-between-system-space staff-space)
ditto.

http://codereview.appspot.com/4061043/diff/1/input/regression/page-top-space.ly
File input/regression/page-top-space.ly (right):

http://codereview.appspot.com/4061043/diff/1/input/regression/page-top-space.ly#newcode25
input/regression/page-top-space.ly:25: obsolete-page-top-space = 3 \cm
top-system-spacing #'basic-distance = #(/ obsolete-page-top-space
staff-space)
ditto.

http://codereview.appspot.com/4061043/

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

Re: Black mensural notation

On 1/23/11 6:20 AM, "Boris Shingarov"  wrote:

> This looks like Issue 1098.  That one was closed due to lack of
> reproducible scenario: my scores, too, were crashing Lilypond after
> growing above a certain size, but just like in your case, I can not
> reproduce it with a simple \repeat.

Please check out issue 1475.  It has a reproducible Tiny example, and a
comment from Joe on why the issue occurs.  You might get some ideas for how
you could check to see if the problem with your score is related to 1475.

Thanks,

Carl

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

Re: Has anything been done about implementing music streams?

On 1/23/11 6:22 AM, "Bernard Hurley"  wrote:

> Hi,
> 
> In order to understand the lily code better I read Erik Sandberg¹s
> master's thesis. The idea of a music stream seems very interesting. Is
> this anywhere near being implemented?

Yes, music streams are currently implemented in LilyPond.

You will see Stream_event listed in the C++ code.

Thanks,

Carl

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

Has anything been done about implementing music streams?

2011-01-23 Thread Bernard Hurley

Hi,

In order to understand the lily code better I read Erik Sandberg’s
master's thesis. The idea of a music stream seems very interesting. Is
this anywhere near being implemented?

Cheers,

/Bernard


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

Re: Black mensural notation

2011-01-23 Thread Boris Shingarov

This looks like Issue 1098.  That one was closed due to lack of 
reproducible scenario: my scores, too, were crashing Lilypond after 
growing above a certain size, but just like in your case, I can not 
reproduce it with a simple \repeat.


On 11-01-16 12:57 PM, Benkő Pál wrote:

following up myself:

[ after complaining about my large scores ]


This seems to work (at least, the regtests are OK and it doesn't
appear to break the interaction between page-count and
systems-per-page):

[...]

I don't know why, though. :)

it works for me in the sense that there's no memory problem,
but doesn't work in the sense that now I get an overflow message.

those larger scores mean about 30 pages, chunked into 14 \score's.
when I comment them out one by one, there's a stage (at about 10
\score's over 27 pages) when compilation with the official version
achieves similar results: gets through without swapping but with
overflow messages.  when compiling, about 30 seconds are needed to
reach the "Fitting music on 26 or 27 pages..." message, then for
3 more minutes nothing happens (even memory usage is at the same
level (minus a slight increase from 864m to 906mat half time)),
then it's over in about 10 seconds.  adding one more score induces
immediate swapping in the "Fitting music..." stage - I've killed
compilation at 44 seconds after eating 3600m.
after applying your patch the breaks are different, the overall
result is of about the same quality, but the middle section takes
3 seconds instead of minutes.

unfortunately I couldn't reproduce this behaviour with a file
with \repeat unfold music copy-pasted into 20 \score's.  I'll
try to understand what goes on, but am not too confident.

if needed, I can post my .ly files.

p

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





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

Re: Vocal headword

2011/1/23 Jean-Charles Malahieude :

> I'll take care of it for French, since I'm in a full review of the French
> version and wishing to have it up to date with 2.14.

Pushed in English and Spanish only.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Vocal headword

2011-01-23 Thread Jean-Charles Malahieude


Le 23/01/2011 12:20, Francisco Vila disait :

2011/1/23 Trevor Daniels:


Francisco Vila wrote Sunday, January 23, 2011 10:01 AM


The patch (attached) for English docs only; compiles fine.


Not my most favourite piece of vocal music,


I think the same :-)


but it
makes a fine headword!

LG to push TM.


OK, I'll include it in all languages.


I'll take care of it for French, since I'm in a full review of the 
French version and wishing to have it up to date with 2.14.


Cheers,
Jean-Charles

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

Re: Vocal headword

2011/1/23 Trevor Daniels :
>
> Francisco Vila wrote Sunday, January 23, 2011 10:01 AM
>
>> The patch (attached) for English docs only; compiles fine.
>
> Not my most favourite piece of vocal music,

I think the same :-)

> but it
> makes a fine headword!
>
> LG to push TM.

OK, I'll include it in all languages.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Vocal headword

2011-01-23 Thread Trevor Daniels



Francisco Vila wrote Sunday, January 23, 2011 10:01 AM


The patch (attached) for English docs only; compiles fine.


Not my most favourite piece of vocal music, but it
makes a fine headword!

LG to push TM.

Trevor



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

Re: Vocal headword