having trouble fetching all remote branches

[Janek Warchoł]

My local repository wasn't created with git clone, and i have only one
remote branch ('origin/master'); i cannot push to staging because of
that.  I've tried 'git fetch --all', but the other remote branches do
not appear, and i don't see a solution in git fetch description.  Any
help?

thanks in advance,
Janek

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

"m...@apollinemike.com"  writes:

> I'll look into doing 1.  Meanwhile, if someone can tell me how to push
> changes to a remote branch (after having created the branch), I'd be
> much obliged!

If it is a fast forward, just push like the initial push.  If it is not,
you can't push at all given the current repository settings.  Instead
you need to _delete_ the branch

git push origin :dev/skyline

and then push a fresh one

git push origin HEAD:refs/heads/dev/skyline

-- 
David Kastrup

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[janek . lilypond]

On 2012/02/06 19:25:34, mike_apollinemike.com wrote:

On Feb 6, 2012, at 8:00 PM, Joe Neeman wrote:



> Could you publicize work-in-progress patches like this as a git

branch instead

of a Rietveld issue?



Ok.  For the git-handicapped (me), how does one do this?


Push a private branch to our official repository?

git push origin local-branch-to-be-pushed:target-branch

if 'target-branch' does not exist, it will be created.

HTH,
Janek

http://codereview.appspot.com/5626052/

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

Re: utf-8-string

[Janek Warchoł]

2012/2/6 m...@apollinemike.com :
> Hey all,
>
> I see a shortcut for utf-8-strings in pango-font.cc.  This is all well and 
> good except that it is hard to do box approximations on these guys (it'd 
> require adding lots of code).  How mad would LilyPond be if I just deleted 
> all of the utf-8-string business?  I don't think it'd change the visual 
> output...it'd just get rid of a shortcut.  Does anyone have any justification 
> for keeping this shortcut?

This is just a wild guess: would deleting it mean that Pango would
treat all text on a letter-per-letter basis?  If so, there could be
problems with kerning; see how kerning is not applied to letters which
are in separate lyric syllabes:

\markup \sans { LTA <- proper kerning }
\repeat unfold 4 a'4
\addlyrics {
  \override LyricText #'font-family = #'sans
  LL -- TT -- AA }
\markup "lyric syllabes are treated as separate strings and even when
they touch, kerning is not applied"

hope this helps,
Janek

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 6, 2012, at 9:41 PM, m...@apollinemike.com wrote:

> On Feb 6, 2012, at 9:24 PM, Werner LEMBERG wrote:
> 
>>> To all interested parties, this work is now up on:
>>> 
>>> dev/skylines
>> 
>> Thanks.  A minor thing which causes me grief each time I see it:
>> Please configure your editor so that it automatically inserts a
>> newline character at EOF.
>> 
>> 
>>   Werner
> 
> OK.  I've cleaned up all of my cryptic commit messages and pushed a single 
> commit to dev/staging.
> I tried to rebase to remove the whitespace errors but to no avail.  If 
> someone knows how to do cleanup on this, please do!
> 
> Cheers,
> MS
> 

Some stats for Mozart's 2nd horn concerto (all averages).

Without the patch: 47s
With the patch: 1m
of which
16s are added on by the Scheme code
11s are gobbled up alone by (make-curves-for-glyph-and-cache d font name-style 
name)

So the skyline problems are minimal to non-existant.  It's the Scheme code 
that's slowing things down.
This can (should) be solved in two ways.

1) Do all of the calculations in make-curves-for-glyph-and-cache during the 
build of the fonts.  This will likely slow the font build down significantly as 
it'll need to be done on all of emmentaler, but it won't need to be redone 
unless someone changes a glyph.

2) Port a chunk of this code (if not all of this code) to C++.  I have no clue 
what time of time gains this'll bring.  In my naive mind, all of the scm_to_X 
and scm_from_X feels like it adds time because it means more lines of code and 
morphing things in and out of C++, but I'm guessing this has no basis and is 
still in fact faster.

I'll look into doing 1.  Meanwhile, if someone can tell me how to push changes 
to a remote branch (after having created the branch), I'd be much obliged!

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 6, 2012, at 9:24 PM, Werner LEMBERG wrote:

>> To all interested parties, this work is now up on:
>> 
>> dev/skylines
> 
> Thanks.  A minor thing which causes me grief each time I see it:
> Please configure your editor so that it automatically inserts a
> newline character at EOF.
> 
> 
>Werner

OK.  I've cleaned up all of my cryptic commit messages and pushed a single 
commit to dev/staging.
I tried to rebase to remove the whitespace errors but to no avail.  If someone 
knows how to do cleanup on this, please do!

Cheers,
MS


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Werner LEMBERG]

> To all interested parties, this work is now up on:
> 
> dev/skylines

Thanks.  A minor thing which causes me grief each time I see it:
Please configure your editor so that it automatically inserts a
newline character at EOF.


Werner

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 6, 2012, at 8:37 PM, David Kastrup wrote:

> It is rare that I encounter an algorithm that I can't speed up by a
> factor of at least 10 once I seriously try (and that does not mean
> coding in assembly or similar bad deals).  

Have at it!

To all interested parties, this work is now up on:

dev/skylines

A few gotchyas:

-) the code in axis-group-interface.cc add_grobs_of_one_priority has lots of if 
/ else that could likely be made easier to read.  not much of a speed up, but 
would help legibility.  basically, they're all flags for using skylines or not. 
 it can easily be divided into two different functions that are accessed as the 
result of one if/else statement.
-) in axis-group-interface.cc, anytime you use a skyline to do the job of a 
box, try it with and without a copy of the skyline.  moving the original around 
may screw things up if the skyline is reused.
-) if i had a guess as to the two places this could be sped up, its:
) caching glyph box data in a scm file when the fonts are built.  all the 
code is there in stencil-integral.scm - it'd just need to be called and written 
somewhere during the build process.  code could be added here to remove boxes 
that will never be part of a skyline (inside the white space of the treble 
clef, for example)
) speeding up skylines. specifically:
) the constructor
) merge
) distance
) touching_point
) height

Good luck!

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

"m...@apollinemike.com"  writes:

>> L'Isle joyeuse:
>> 
>> master: 0m30.432s
>> patched: 0m46.997s
>> 
>> Psalm 94 (Reubke):
>> 
>> master: 1m31.692s
>> patched: 2m0.817s
>
> Thanks!
> In my opinion, these times are too high to justify the gain that one
> gets from using fine-tuned vertical skylines.

It is rare that I encounter an algorithm that I can't speed up by a
factor of at least 10 once I seriously try (and that does not mean
coding in assembly or similar bad deals).  So don't go overboard with
limiting functionality, overrides, part enables and whatever before I
even had a chance to look at this.

Fork it out into a branch.  Makes it easier to work on with multiple
people.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Feb 6, 2012, at 8:00 PM, Joe Neeman wrote:
>
>> Could you publicize work-in-progress patches like this as a git
>> branch instead of a Rietveld issue?
>
> Ok.  For the git-handicapped (me), how does one do this?

Assuming you have a feature branch checked out at the moment, something
like

git push origin HEAD:dev/skylines

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 6, 2012, at 8:00 PM, Joe Neeman wrote:

> Could you publicize work-in-progress patches like this as a git branch 
> instead of a Rietveld issue?

Ok.  For the git-handicapped (me), how does one do this?

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Joe Neeman]

Could you publicize work-in-progress patches like this as a git branch
instead of a Rietveld issue? Git branches are easy for reviewers to check
out, fast-forward, revert, etc. That way, people can offer broad comments.
When the patch is "finished" (ie. you can't think of anything you need to
change), then upload it to rietveld, where it's easy to make specific,
in-line comments.

Avoiding rietveld until the patch is done will also prevent the situation
where someone makes a bunch of detailed comments to lines that you're in
the middle of changing anyway.

Cheers,
Joe

On Sat, Feb 4, 2012 at 1:28 PM,  wrote:

> Reviewers: ,
>
> Message:
> Sorry in advance for the whitespace errors.
>
> This patch provides a generic framework for building vertical skylines
> out of boxes by traversing through a stencil.  It currently only
> implements skylines for three stencil types (draw-line, named-glyph, and
> glyph-string) and can do more for other glyphs.  It is modular, so as
> skyline estimation improve for a given stencil, that function can be
> worked on alone w/o touching the other parts of stencil-integral.scm.
>
> The implementation for glyph-string is ugly and slightly incorrect for y
> heights of these stencils...it would be infinitely easier if the stencil
> could contain information about y extents, but unfortunately,
> PangoGlyphGeometry does not carry height information.  This error does
> not have a bearing on the visual results in this patch, but it'd be good
> to find a way to make the dimensions exact.
>
> I'm also not sure that line thickness is tacked on correctly for the
> draw-line boxes, but it seems to yield correct results.
>
> Cheers,
> MS
>
> Description:
> Gets vertical skylines from grob stencils
>
> Please review this at 
> http://codereview.appspot.com/**5626052/
>
> Affected files:
>  A 
> input/regression/tuplet-**bracket-vertical-skylines.ly
>  A 
> input/regression/volta-**bracket-vertical-skylines.ly
>  M lily/axis-group-interface.cc
>  A lily/box-scheme.cc
>  M lily/include/box.hh
>  M lily/include/skyline.hh
>  M lily/skyline-pair.cc
>  A lily/skyline-scheme.cc
>  M lily/skyline.cc
>  M lily/stencil-scheme.cc
>  M lily/tuplet-bracket.cc
>  M lily/volta-bracket.cc
>  M scm/define-grobs.scm
>  M scm/lily.scm
>  A scm/stencil-integral.scm
>
>
>
> __**_
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/**listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Graham Percival]

On Mon, Feb 06, 2012 at 07:45:47PM +0100, Werner LEMBERG wrote:
> > In my opinion, these times are too high to justify the gain that one
> > gets from using fine-tuned vertical skylines.
> 
> Yes, unfortunately.

+1

is it at all possible to make this a user-configurable option?
I know this would add complexity to the code base, but how bad
would it be?

- Graham

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Werner LEMBERG]

>> L'Isle joyeuse:
>> 
>> master: 0m30.432s
>> patched: 0m46.997s
>> 
>> Psalm 94 (Reubke):
>> 
>> master: 1m31.692s
>> patched: 2m0.817s
> 
> In my opinion, these times are too high to justify the gain that one
> gets from using fine-tuned vertical skylines.

Yes, unfortunately.


Werner

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

Re: Errors in examples

[David Kastrup]

"Phil Holmes"  writes:

>> No.  The real problem is that \voiceOne and/or \voiceTwo do not take
>> hold for some reason.  If they did, the example would just work fine.
>> Probably something grace-related.
>>
>> Please let us find and fix the real problem instead of meddling with its
>> symptoms.
>
> Good point - well spotted.  I'll have another look tomorrow.

In a nutshell:

\relative c'' { \voiceOne
\grace { c16 } \repeat unfold 16 c
  }

does not work.  Even more annoyingly, not even

\context Voice \with \settingsFrom \voiceOne
\relative c'' {
\grace { c16 } \repeat unfold 16 c
  }

works.  And not even

\relative c'' {
\grace { c16 } \repeat unfold 16 c
  }

\layout {
  \context {
\Voice
\settingsFrom \voiceOne
  }
}

which should also cover implicitly generated voices has a chance to get
its settings through to _any_ note.  There is something very rotten
going on here.

-- 
David Kastrup

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

Re: Errors in examples

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Monday, February 06, 2012 5:40 PM
Subject: Re: Errors in examples



David Kastrup  writes:


Graham Percival  writes:


On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote:

- Original Message - From: "Graham Percival"

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, February 05, 2012 3:08 PM
Subject: Re: Errors in examples

>Users aren't supposed to look at these, but sure, go ahead and fix
>those warnings if you want.  As long as the output looks the same,
>push directly to staging.

Given the 2 chords/notes near the end, both with downstems, I think
the only option is either use the ignore-collision override, or have
the upper notes stem-up using voiceOne.  It doesn't appear to be a
"famous" piece of music - there's no title, etc., so I'd actually
prefer the latter.


ok, sure.


No.  The real problem is that \voiceOne and/or \voiceTwo do not take
hold for some reason.  If they did, the example would just work fine.
Probably something grace-related.

Please let us find and fix the real problem instead of meddling with its
symptoms.


If you comment out the acciaccatura like

 \partial 4. %{ \acciaccatura c16 \glissando %} cis8 e4

the whole piece gets through fine with the intended voicing.  This is
really, _really_ fishy.

--
David Kastrup


See "Known Issues " etc. in 
http://lilypond.org/doc/v2.15/Documentation/notation/special-rhythmic-concerns . 
It's in the bug list somewhere


Ah yes.  http://code.google.com/p/lilypond/issues/detail?id=630

--
Phil Holmes



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

Re: Errors in examples

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Monday, February 06, 2012 5:01 PM
Subject: Re: Errors in examples



Graham Percival  writes:


On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote:

- Original Message - From: "Graham Percival"

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, February 05, 2012 3:08 PM
Subject: Re: Errors in examples

>Users aren't supposed to look at these, but sure, go ahead and fix
>those warnings if you want.  As long as the output looks the same,
>push directly to staging.

Given the 2 chords/notes near the end, both with downstems, I think
the only option is either use the ignore-collision override, or have
the upper notes stem-up using voiceOne.  It doesn't appear to be a
"famous" piece of music - there's no title, etc., so I'd actually
prefer the latter.


ok, sure.


No.  The real problem is that \voiceOne and/or \voiceTwo do not take
hold for some reason.  If they did, the example would just work fine.
Probably something grace-related.

Please let us find and fix the real problem instead of meddling with its
symptoms.

--
David Kastrup




Good point - well spotted.  I'll have another look tomorrow.

--
Phil Holmes



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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 6, 2012, at 6:36 PM, Neil Puttock wrote:

> On 6 February 2012 16:59,   wrote:
>> Should have added before: the most recent patch set is not bug free.
> 
> Cyclic dependencies for TextScript Y-offset.
> 
> But you've just fixed that by the look of it. ;)
> 

"fixed" is a generous word for what I've done...
I've removed the Y-offset check, but the issue now is that anything with 
outside-staff-priority and vertical-skylines will have its Y-offset ignored 
when it is being moved.
This means that it could come in lower than what it would be if the original 
offset were there.

if you add the line:
elements[i]->relative_offset (y_common, Y_AXIS);
anywhere in the loop from which I removed the Y-offset and then run 
volta-multi-staff.ly, you'll see a strange shift in the volta bracket.
i have absolutely no idea what is causing this - it'll take me some time to 
sort it out.
in the final patch, though, the relative_offset would need to be factored in so 
that grobs with outside staff priority could not dip below their 
relative_coordinate.

>> I'm fixing all of the regtest issues, but what I need most from other
>> people who have a few minutes are benchmarks.
> 
> L'Isle joyeuse:
> 
> master: 0m30.432s
> patched: 0m46.997s
> 
> Psalm 94 (Reubke):
> 
> master: 1m31.692s
> patched: 2m0.817s

Thanks!
In my opinion, these times are too high to justify the gain that one gets from 
using fine-tuned vertical skylines.  In the final version of the patch, I'll 
limit them to slurs, ties, tuplet-brackets, volta repeats, and treble clefs.  
Other grobs' vertical-skylines can be turned on via overrides for anyone who 
wants tighter spacing.  We can even create a tight-spacing.ly file that people 
can include to get the overrides in one fell swoop.

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

Re: Errors in examples

[David Kastrup]

David Kastrup  writes:

> Graham Percival  writes:
>
>> On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote:
>>> - Original Message - From: "Graham Percival"
>>> 
>>> To: "Phil Holmes" 
>>> Cc: "Devel" 
>>> Sent: Sunday, February 05, 2012 3:08 PM
>>> Subject: Re: Errors in examples
>>> 
>>> >Users aren't supposed to look at these, but sure, go ahead and fix
>>> >those warnings if you want.  As long as the output looks the same,
>>> >push directly to staging.
>>> 
>>> Given the 2 chords/notes near the end, both with downstems, I think
>>> the only option is either use the ignore-collision override, or have
>>> the upper notes stem-up using voiceOne.  It doesn't appear to be a
>>> "famous" piece of music - there's no title, etc., so I'd actually
>>> prefer the latter.
>>
>> ok, sure.
>
> No.  The real problem is that \voiceOne and/or \voiceTwo do not take
> hold for some reason.  If they did, the example would just work fine.
> Probably something grace-related.
>
> Please let us find and fix the real problem instead of meddling with its
> symptoms.

If you comment out the acciaccatura like

  \partial 4. %{ \acciaccatura c16 \glissando %} cis8 e4

the whole piece gets through fine with the intended voicing.  This is
really, _really_ fishy.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Neil Puttock]

On 6 February 2012 16:59,   wrote:
> Should have added before: the most recent patch set is not bug free.

Cyclic dependencies for TextScript Y-offset.

But you've just fixed that by the look of it. ;)

> I'm fixing all of the regtest issues, but what I need most from other
> people who have a few minutes are benchmarks.

L'Isle joyeuse:

master: 0m30.432s
patched: 0m46.997s

Psalm 94 (Reubke):

master: 1m31.692s
patched: 2m0.817s

Cheers,
Neil

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

Re: Errors in examples

[David Kastrup]

Graham Percival  writes:

> On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote:
>> - Original Message - From: "Graham Percival"
>> 
>> To: "Phil Holmes" 
>> Cc: "Devel" 
>> Sent: Sunday, February 05, 2012 3:08 PM
>> Subject: Re: Errors in examples
>> 
>> >Users aren't supposed to look at these, but sure, go ahead and fix
>> >those warnings if you want.  As long as the output looks the same,
>> >push directly to staging.
>> 
>> Given the 2 chords/notes near the end, both with downstems, I think
>> the only option is either use the ignore-collision override, or have
>> the upper notes stem-up using voiceOne.  It doesn't appear to be a
>> "famous" piece of music - there's no title, etc., so I'd actually
>> prefer the latter.
>
> ok, sure.

No.  The real problem is that \voiceOne and/or \voiceTwo do not take
hold for some reason.  If they did, the example would just work fine.
Probably something grace-related.

Please let us find and fix the real problem instead of meddling with its
symptoms.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Phil Holmes]

- Original Message - 
From: 

To: 
Cc: ; 
Sent: Monday, February 06, 2012 4:59 PM
Subject: Re: Gets vertical skylines from grob stencils (issue 5626052)



Should have added before: the most recent patch set is not bug free.
I'm fixing all of the regtest issues, but what I need most from other
people who have a few minutes are benchmarks.

Cheers,
MS

http://codereview.appspot.com/5626052/



Does this have to be complex input?   If not, make doc exercises lilypond 
quite a lot.


--
Phil Holmes



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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[mtsolo]

Should have added before: the most recent patch set is not bug free.
I'm fixing all of the regtest issues, but what I need most from other
people who have a few minutes are benchmarks.

Cheers,
MS

http://codereview.appspot.com/5626052/

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

Re: Errors in examples

[Graham Percival]

On Mon, Feb 06, 2012 at 04:12:55PM -, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> 
> To: "Phil Holmes" 
> Cc: "Devel" 
> Sent: Sunday, February 05, 2012 3:08 PM
> Subject: Re: Errors in examples
> 
> >Users aren't supposed to look at these, but sure, go ahead and fix
> >those warnings if you want.  As long as the output looks the same,
> >push directly to staging.
> 
> Given the 2 chords/notes near the end, both with downstems, I think
> the only option is either use the ignore-collision override, or have
> the upper notes stem-up using voiceOne.  It doesn't appear to be a
> "famous" piece of music - there's no title, etc., so I'd actually
> prefer the latter.

ok, sure.

- Graham

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[mtsolo]

Hey all,

Could people please try this patch out on a couple real world scores and
do some benchmarking compared to current master?  It adds a lot of
calculations to lilypond and a lot of them happen in Scheme, so I wanna
make sure lilypond doesn't take a large processing hit.

Cheers,
MS

http://codereview.appspot.com/5626052/

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

Re: Errors in examples

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, February 05, 2012 3:08 PM
Subject: Re: Errors in examples



On Sun, Feb 05, 2012 at 02:43:45PM -, Phil Holmes wrote:

In the source for http://lilypond.org/ly-examples/tab-example.png I
get the following compile errors:

Seems to me these really ought to compile clean?


Users aren't supposed to look at these, but sure, go ahead and fix
those warnings if you want.  As long as the output looks the same,
push directly to staging.

- Graham



Given the 2 chords/notes near the end, both with downstems, I think the only 
option is either use the ignore-collision override, or have the upper notes 
stem-up using voiceOne.  It doesn't appear to be a "famous" piece of music - 
there's no title, etc., so I'd actually prefer the latter.


--
Phil Holmes



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

Re: Where to document patchy?

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "Graham Percival" 
> To: "Phil Holmes" 
> Cc: "Devel" 
> Sent: Sunday, February 05, 2012 2:20 PM
> Subject: Re: Where to document patchy?
>
>
>> On Sun, Feb 05, 2012 at 02:15:31PM -, Phil Holmes wrote:
>>> http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling ?
>>>
>>> http://lilypond.org/doc/v2.15/Documentation/contributor/pushing-to-staging ?
>>>
>>> http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches
>>> ?
>>>
>>> I think it would be best to document both versions of patchy in the
>>> same place, but where?
>>
>> Dump it in administration.itexi, @node @section Patchy the
>> autobot.  Push directly to staging.
>
> Pushed as c0beab2f53c8244d101962517def952bab18189e.  Now running
> patchy-merge to pick up this and the other work of today.

Pointless of me to stay in the race then, even though I made good
progress.  But I should spend my comparatively measly resources on
test-patchy again instead since fewer people run that, and the version
of staging I am currently running on is older than yours anyway.
Aborting.

-rw-rw-r--  1 dak dak7011 2012-02-06 15:50 log-staging-configure.txt
-rw-rw-r--  1 dak dak   50071 2012-02-06 15:50 
log-staging-nice-make-clean--j3.txt
-rw-rw-r--  1 dak dak 2289658 2012-02-06 15:55 log-staging-nice-make--j3.txt
-rw-rw-r--  1 dak dak   74926 2012-02-06 16:07 
log-staging-nice-make-test--j3.txt
drwxrwxr-x 22 dak dak4096 2012-02-06 16:07 build
-rw-rw-r--  1 dak dak  161071 2012-02-06 16:40 log-staging-nice-make-doc--j3.txt



-- 
David Kastrup


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

Re: Where to document patchy?

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Sunday, February 05, 2012 2:20 PM
Subject: Re: Where to document patchy?



On Sun, Feb 05, 2012 at 02:15:31PM -, Phil Holmes wrote:

http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling ?

http://lilypond.org/doc/v2.15/Documentation/contributor/pushing-to-staging ?

http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches
?

I think it would be best to document both versions of patchy in the
same place, but where?


Dump it in administration.itexi, @node @section Patchy the
autobot.  Push directly to staging.


Pushed as c0beab2f53c8244d101962517def952bab18189e.  Now running 
patchy-merge to pick up this and the other work of today.



--
Phil Holmes



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

Adds stencil command suppressions to changes (issue 5633048)

[dak]

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

http://codereview.appspot.com/5633048/diff/1/Documentation/changes.tely#newcode67
Documentation/changes.tely:67: following stencil commands have been
suppressed:
"removed" or "eliminated" or "replaced" (depending on what you did).

But "suppressed" is definitely the wrong word.

http://codereview.appspot.com/5633048/

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

Re: Stops woodwind diagram info appearing on terminal (issue 5636048)

[dak]

On 2012/02/06 14:07:54, mail_philholmes.net wrote:


I didn't do that because I had no idea it would work.  As a snippet, I

think

it's easier to leave as is because the average user (e.g. me) would

not

understand the lambda stuff.


Well, the thing is that you could also write
(with-output-to-file "this/file/name" (lambda () ...

And you can't do that all that nicely with an extra argument (well, you
can open a file port, use it, then close it again, but that is more
cumbersome).

http://codereview.appspot.com/5636048/

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

Re: Stops woodwind diagram info appearing on terminal (issue 5636048)

[Phil Holmes]

- Original Message - 
From: 
To: ; ; 
; 

Cc: ; 
Sent: Monday, February 06, 2012 1:28 PM
Subject: Re: Stops woodwind diagram info appearing on terminal (issue 
5636048)





http://codereview.appspot.com/5636048/diff/1/Documentation/snippets/new/woodwind-diagrams-key-lists.ly
File Documentation/snippets/new/woodwind-diagrams-key-lists.ly (right):

http://codereview.appspot.com/5636048/diff/1/Documentation/snippets/new/woodwind-diagrams-key-lists.ly#newcode16
Documentation/snippets/new/woodwind-diagrams-key-lists.ly:16:
#(print-keys-verbose 'piccolo (current-error-port))
This is ugly and tiresome to change.  Why don't you wrap the whole
kaboodle in
#(with-output-to-port (current-error-port)
  (lambda ()
(print-keys-verbose 'flute)
(print-keys-verbose 'flute-b-extension)
...

I'd probably even do a for-each around the various instruments, but then
the snippet would not really look
all that instructive anymore.

http://codereview.appspot.com/5636048/



I didn't do that because I had no idea it would work.  As a snippet, I think 
it's easier to leave as is because the average user (e.g. me) would not 
understand the lambda stuff.


--
Phil Holmes



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

Re: Stops woodwind diagram info appearing on terminal (issue 5636048)

[dak]

http://codereview.appspot.com/5636048/diff/1/Documentation/snippets/new/woodwind-diagrams-key-lists.ly
File Documentation/snippets/new/woodwind-diagrams-key-lists.ly (right):

http://codereview.appspot.com/5636048/diff/1/Documentation/snippets/new/woodwind-diagrams-key-lists.ly#newcode16
Documentation/snippets/new/woodwind-diagrams-key-lists.ly:16:
#(print-keys-verbose 'piccolo (current-error-port))
This is ugly and tiresome to change.  Why don't you wrap the whole
kaboodle in
#(with-output-to-port (current-error-port)
  (lambda ()
(print-keys-verbose 'flute)
(print-keys-verbose 'flute-b-extension)
...

I'd probably even do a for-each around the various instruments, but then
the snippet would not really look
all that instructive anymore.

http://codereview.appspot.com/5636048/

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

utf-8-string

[m...@apollinemike.com]

Hey all,

I see a shortcut for utf-8-strings in pango-font.cc.  This is all well and good 
except that it is hard to do box approximations on these guys (it'd require 
adding lots of code).  How mad would LilyPond be if I just deleted all of the 
utf-8-string business?  I don't think it'd change the visual output...it'd just 
get rid of a shortcut.  Does anyone have any justification for keeping this 
shortcut?

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

Stops woodwind diagram info appearing on terminal (issue 5636048)

[PhilEHolmes]

Reviewers: dak, Graham Percival, Trevor Daniels, J_lowe,

Message:
Please review - especially changes to Documentation/notation/wind.itely

Description:
This patch has a couple of files from the LSR, which had minor changes
from my last LSR patch.  I've included them to keep the system in step.
The main changes are to /snippets/new/woodwind-diagrams-key-lists.ly
(and the associated changes to /snippets/woodwind-diagrams-key-lists.ly
created with makelsr) and Documentation/notation/wind.itely.  I'd like
someone with documentation experience to check this - I've taken out a
lilipond example, because as written it runs and dumps key information
to terminal when running make doc.  Just showing this as the code to be
run prevents this.

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

Affected files:
  M Documentation/notation/wind.itely
  M Documentation/snippets/formatting-lyrics-syllables.ly
  M Documentation/snippets/hymn-template.ly
  M Documentation/snippets/new/woodwind-diagrams-key-lists.ly
  M Documentation/snippets/partcombine-and-autobeamoff.ly
  M Documentation/snippets/woodwind-diagrams-key-lists.ly


Index: Documentation/notation/wind.itely
diff --git a/Documentation/notation/wind.itely  
b/Documentation/notation/wind.itely
index  
a9725fd7172391e37d629c06f0927ae5471701cf..a935aa121da5f79d712eb7bc5493ed86b9359386  
100644

--- a/Documentation/notation/wind.itely
+++ b/Documentation/notation/wind.itely
@@ -393,14 +393,10 @@ c1^\markup {
 @end lilypond

 The list of all possible keys and settings for a given instrument
-can be displayed on the console or in the log file, although they
-will not show up in the music output:
-
-@lilypond[verbatim,quote]
-
-#(print-keys-verbose 'flute)
-
-@end lilypond
+can be displayed on the console using
+@code{#(print-keys-verbose 'flute)} or in the log file using
+@code{#(print-keys-verbose 'flute (current-error-port))}, although
+they will not show up in the music output.

 New diagrams can be created by following the patterns in
 @file{scm/define-woodwind-diagrams.scm} and
Index: Documentation/snippets/formatting-lyrics-syllables.ly
diff --git a/Documentation/snippets/formatting-lyrics-syllables.ly  
b/Documentation/snippets/formatting-lyrics-syllables.ly
index  
fa99151b8e5b7ee8a1c699a04764d54dcd685c18..f64e9f012a2123236fc906850b62d53a0a0698d8  
100644

--- a/Documentation/snippets/formatting-lyrics-syllables.ly
+++ b/Documentation/snippets/formatting-lyrics-syllables.ly
@@ -16,7 +16,6 @@ zu formatieren.

 "
   doctitlede = "Silben im Gesangstext formatieren"
-
 %%  Translation of GIT committish: d9d1da30361a0bcaea1ae058eb1bc8dd3a5b2e4c
   texidocfr = "
 Le mode markup permet d'individualiser la mise en forme de certaines  
syllabes.

Index: Documentation/snippets/hymn-template.ly
diff --git a/Documentation/snippets/hymn-template.ly  
b/Documentation/snippets/hymn-template.ly
index  
d2d680e43dfea62090a156715ec1e9f0c6aa7c6a..b8af195da3061d7efafc9ed554bbdc6866882ef8  
100644

--- a/Documentation/snippets/hymn-template.ly
+++ b/Documentation/snippets/hymn-template.ly
@@ -27,7 +27,6 @@ strofe come testo separato sotto la musica.

 "
   doctitleit = "Modello per inno"
-
 %%Translation of GIT committish:  
ab9e3136d78bfaf15cc6d77ed1975d252c3fe506


   texidocde = "
Index: Documentation/snippets/new/woodwind-diagrams-key-lists.ly
diff --git a/Documentation/snippets/new/woodwind-diagrams-key-lists.ly  
b/Documentation/snippets/new/woodwind-diagrams-key-lists.ly
index  
bdb803cfd9c04e5c101deb8e69f33eda1b961672..0fcdecac584d302b2c221f6bc607e8327dab298b  
100644

--- a/Documentation/snippets/new/woodwind-diagrams-key-lists.ly
+++ b/Documentation/snippets/new/woodwind-diagrams-key-lists.ly
@@ -7,19 +7,24 @@
 The snippet below produces a list of all possible keys and key
 settings for woodwind diagrams as defined in
 @file{scm/define-woodwind-diagrams.scm}.  The list will be displayed
-on the console and in the log file, but not in the music.
+in the log file, but not in the music.  If output to the console
+is wanted, omit the @code{(current-error-port)} from the commands.
 "
   doctitle = "Woodwind diagrams key lists"
 }

-#(print-keys-verbose 'piccolo)
-#(print-keys-verbose 'flute)
-#(print-keys-verbose 'flute-b-extension)
-#(print-keys-verbose 'oboe)
-#(print-keys-verbose 'clarinet)
-#(print-keys-verbose 'bass-clarinet)
-#(print-keys-verbose 'low-bass-clarinet)
-#(print-keys-verbose 'saxophone)
-#(print-keys-verbose 'baritone-saxophone)
-#(print-keys-verbose 'bassoon)
-#(print-keys-verbose 'contrabassoon)
+#(print-keys-verbose 'piccolo (current-error-port))
+#(print-keys-verbose 'flute (current-error-port))
+#(print-keys-verbose 'flute-b-extension (current-error-port))
+#(print-keys-verbose 'tin-whistle (current-error-port))
+#(print-keys-verbose 'oboe (current-error-port))
+#(print-keys-verbose 'clarinet (current-error-port))
+#(print-keys-verbose 'bass-clarinet (current-error-port))
+#(print-keys-verbose 'low-bass-clarinet (current-error-port))
+#(p