Re: Translation request

[Jean-Charles Malahieude]

Le 11/02/2012 15:04, Phil Holmes disait :

Please see commit:

6c6f97dcb49afb3aaa9480eece124d11a6c48975

This changes the words around an illustration of the syntax of printing
woodwind key lists, replacing an inline snippet with text. The benefit
of this is that the snippet is no longer run during a make doc, and
therefore the key lists no longer appear in the terminal output during
make doc. There are some translated versions of this part of the manual
- could a translator update these to gain the full benefit, please?




Done as ead385538f648ca8f9fead37bdeeeadfbacb7c77

Cheers,
Jean-Charles

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

Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

Hi all,

SUMMARY: in order to participate in Google Summer of Code ($$$), we
need an Ideas List.

(to learn more about GSoC, go here
http://www.google-melange.com/gsoc/homepage/google/gsoc2012)

An Ideas List should be a list of suggested student projects.  This
list is meant to introduce contributors to the project's needs and to
provide inspiration to would-be student applicants.

For an example, go here:
http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_observation_planner_and_logging_feature

Below are my suggestions for our Ideas List.  Please comment on them
and give your suggested projects.



General student prerequisites: (basic?) git knowledge

1) Fixing problems with synchronization of grace notes, together with
all underlying architecture (issue 34). Requirements: C++, MIDI;
familiarity with basic music notation recommended

2) Adding comprehensive MusicXML import and export features, together
with test suites for it.  Requirements: ? (no idea in which language
this would be written), MusicXML, basic LilyPond and music notation
knowledge; familiarity with other scorewriters would be a nice bonus
(for cross-testing).  The goal would be considered achieved when a
(previously chosen) not-so-complicated score could be imported from
MusicXML and exported back with no (unintentional) loss of data.

3) Horizontal Spacing of Objects Attached to Notes, esp. Accidentals:
make spacing depend on tightness of the music.  This is thoroughly
explained in issues 2141, 2142, 2143 ans 2144.  Also, the
infrastructure needed to solve 2142 should be generic and extensible,
so as to cover other types of grobs like dots, arpeggios etc (see
comment 8 on issue 2142 -
http://code.google.com/p/lilypond/issues/detail?id=2142#c8).
Requirements:

4) Currently some glyphs come in two varieties: for use on staff lines
and between them (an example of noteheads with varying hole size is
here 
http://lilypond.googlecode.com/issues/attachment?aid=1839001&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1).
 It would be nice to add such variants to other glyphs, for example
accidentals and flags, together with a generic infrasctucture to
support them.  Also, narrower and shorter variants of some glyphs
would be handy, see
http://code.google.com/p/lilypond/issues/detail?id=2145 and
http://code.google.com/p/lilypond/issues/detail?id=2203. Requirements:
MetaFont, C++(?), good eye for details; basic LilyPond knowledge
recommended(?).

5) Build System Improvement: if we want to ever move away from make,
this would be a good opportunity.  Issues like thousands of errors and
warnings during compilation should be removed, all dependancies fixed
(so that one doesn't need to remove fonts folder to have fonts
rebuilt).  Requirements: Python, Make and (optionally) another build
system.

6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking
slurs and ties, ties on enharmonic notes are not supported { cis'~
des' }, ties "broken" by clef or staff change aren't supprted well,
etc. (as for bad shapes, i have a big report on ties halfway done, and
slur examples would need to be collected from mutopia or from users).
Requirements: C++, experience with writing heuristics; basic Scheme,
music notation and LilyPond knowledge recommended.  This project seems
really big to me, unless all of the research and testing would be done
by someone else (bad idea).

7) Grand Beam Project - there are cases of badly-looking beaming, even
in very simple snippets (again, i have a huge report on this matter
halfway-done). Also, beaming should depend on context and neighbor
notes (see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
section 2.2, i can also give some more examples).  Changing beam code
to do this looks like a fairly complicated matter. Requirements: C++,
experience with writing heuristics; basic music notation knowledge
recommended.

I have two more Grand Projects, but they are totally undocumented now.

cheers,
Janek

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

Re: Google Summer of Code - Ideas List, please discuss

[m...@apollinemike.com]

All of these look good.

On Feb 12, 2012, at 12:03 PM, Janek Warchoł wrote:

> General student prerequisites: (basic?) git knowledge
> 
> 1) Fixing problems with synchronization of grace notes, together with
> all underlying architecture (issue 34). Requirements: C++, MIDI;
> familiarity with basic music notation recommended
> 

I have no clue how broken this is as the last time I used a grace note in a 
MIDI was 1998, but it seems like it's a reasonable thing to fix.

> 2) Adding comprehensive MusicXML import and export features, together
> with test suites for it.  Requirements: ? (no idea in which language
> this would be written), MusicXML, basic LilyPond and music notation
> knowledge; familiarity with other scorewriters would be a nice bonus
> (for cross-testing).  The goal would be considered achieved when a
> (previously chosen) not-so-complicated score could be imported from
> MusicXML and exported back with no (unintentional) loss of data.
> 

I worked on this a little bit - it is totally possible and would likely weigh 
in @ 500-1000 lines of Scheme.  I'd recommend not worrying about placement data 
and stopping at the engraver level.  This is more or less the same thing as a 
MIDI plus stuff like articulations, slurs, etc..  Placement data would be 
doable but hard: it'd be better to just get the info from engravers first.

> 3) Horizontal Spacing of Objects Attached to Notes, esp. Accidentals:
> make spacing depend on tightness of the music.  This is thoroughly
> explained in issues 2141, 2142, 2143 ans 2144.  Also, the
> infrastructure needed to solve 2142 should be generic and extensible,
> so as to cover other types of grobs like dots, arpeggios etc (see
> comment 8 on issue 2142 -
> http://code.google.com/p/lilypond/issues/detail?id=2142#c8).
> Requirements:

This is a cool idea but wouldn't be a lot of work - in C++ it'd require 
20-50ish lines of code.

> 4) Currently some glyphs come in two varieties: for use on staff lines
> and between them (an example of noteheads with varying hole size is
> here 
> http://lilypond.googlecode.com/issues/attachment?aid=1839001&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1).
> It would be nice to add such variants to other glyphs, for example
> accidentals and flags, together with a generic infrasctucture to
> support them.  Also, narrower and shorter variants of some glyphs
> would be handy, see
> http://code.google.com/p/lilypond/issues/detail?id=2145 and
> http://code.google.com/p/lilypond/issues/detail?id=2203. Requirements:
> MetaFont, C++(?), good eye for details; basic LilyPond knowledge
> recommended(?).

This could be combined with the above to be a full project.

> 
> 5) Build System Improvement: if we want to ever move away from make,
> this would be a good opportunity.  Issues like thousands of errors and
> warnings during compilation should be removed, all dependancies fixed
> (so that one doesn't need to remove fonts folder to have fonts
> rebuilt).  Requirements: Python, Make and (optionally) another build
> system.
> 

No clue how this stuff works, but sounds like a good idea.

> 6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking
> slurs and ties, ties on enharmonic notes are not supported { cis'~
> des' }, ties "broken" by clef or staff change aren't supprted well,
> etc. (as for bad shapes, i have a big report on ties halfway done, and
> slur examples would need to be collected from mutopia or from users).
> Requirements: C++, experience with writing heuristics; basic Scheme,
> music notation and LilyPond knowledge recommended.  This project seems
> really big to me, unless all of the research and testing would be done
> by someone else (bad idea).

This would take the entire summer if you added intelligent non-convex slurs.  
Here I could most certainly help out - it was on my summer-of-lily list but I'd 
gladly delegate to someone else!

> 
> 7) Grand Beam Project - there are cases of badly-looking beaming, even
> in very simple snippets (again, i have a huge report on this matter
> halfway-done). Also, beaming should depend on context and neighbor
> notes (see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
> section 2.2, i can also give some more examples).  Changing beam code
> to do this looks like a fairly complicated matter. Requirements: C++,
> experience with writing heuristics; basic music notation knowledge
> recommended.
> 

Most beam problems that don't involve cross-staff or broken beams are fixable 
with 1-20 lines of code.  If you send me concrete examples, I can likely 
estimate how long it'd take.

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

Minor documentation nitpick

[Phil Holmes]

In notation/input.tely, line 1100 or so we have:

Automatic footnotes take three arguments; the @var{Layout Object} to be
annotated, the @var{(x . y)} position of the indicator and a

The texinfo manual says:

"Use the @var command to indicate metasyntactic variables" and so it doesn't 
like the parentheses, since I assume a parenthesis cannot be part of a 
variable name.  As a result it throws the following warning:


notation/input.texi:1350: warning: unlikely character ( in @var.

Ignore, replace the @var with @code, or what?

--
Phil Holmes



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

Re: Minor documentation nitpick

[David Kastrup]

"Phil Holmes"  writes:

> In notation/input.tely, line 1100 or so we have:
>
> Automatic footnotes take three arguments; the @var{Layout Object} to be
> annotated, the @var{(x . y)} position of the indicator and a
>
> The texinfo manual says:
>
> "Use the @var command to indicate metasyntactic variables" and so it
> doesn't like the parentheses, since I assume a parenthesis cannot be
> part of a variable name.  As a result it throws the following warning:
>
> notation/input.texi:1350: warning: unlikely character ( in @var.
>
> Ignore, replace the @var with @code, or what?

Looking at the Texinfo documentation, it would appear that @samp might
be a better fit.

-- 
David Kastrup


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

Re: Minor documentation nitpick

[Graham Percival]

On Sun, Feb 12, 2012 at 12:47:36PM -, Phil Holmes wrote:
> Automatic footnotes take three arguments; the @var{Layout Object} to be
> annotated, the @var{(x . y)} position of the indicator and a
>
> The texinfo manual says:
> 
> "Use the @var command to indicate metasyntactic variables" and so it
> doesn't like the parentheses, since I assume a parenthesis cannot be
> part of a variable name.

aha, that's where it comes from!  this has been bugging me for 7
or 8 years.

> Ignore, replace the @var with @code, or what?

Let's make it a

@c weird construct to avoid complaint about parentheses ()
@c inside @var
annotated, the @emph{@code{(x . y)}} position of the indicator and a


IIRC @var{} is displayed as @emph{@code{}}.  I don't like using
formatting commands directly, but let's do it anyway.

(oh, it might be nice to send a feature request to the texinfo
guys... but it's been years and years since they last had a
release, so let's use the workaround)

- Graham

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

Re: Minor documentation nitpick

[David Kastrup]

Graham Percival  writes:

> IIRC @var{} is displayed as @emph{@code{}}.

It isn't.  Not in Info.

> I don't like using formatting commands directly, but let's do it
> anyway.

Recipe for trouble with a multi-output format like Texinfo.  Either use
@var{position} or @samp{(x . y)}, those are intended forms.

-- 
David Kastrup


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

Re: Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

W dniu 12 lutego 2012 12:51 użytkownik m...@apollinemike.com
 napisał:
>
>> 3) Horizontal Spacing of Objects Attached to Notes, esp. Accidentals:
>> make spacing depend on tightness of the music.  This is thoroughly
>> explained in issues 2141, 2142, 2143 ans 2144.  Also, the
>> infrastructure needed to solve 2142 should be generic and extensible,
>> so as to cover other types of grobs like dots, arpeggios etc (see
>> comment 8 on issue 2142 -
>> http://code.google.com/p/lilypond/issues/detail?id=2142#c8).
>> Requirements:
>
> This is a cool idea but wouldn't be a lot of work - in C++ it'd require 
> 20-50ish lines of code.

Really?  All these issues, and extending this to all sorts of grobs?  Wow!

>> 4) Currently some glyphs come in two varieties: for use on staff lines
>> and between them (an example of noteheads with varying hole size is
>> here 
>> http://lilypond.googlecode.com/issues/attachment?aid=1839001&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1).
>> It would be nice to add such variants to other glyphs, for example
>> accidentals and flags, together with a generic infrasctucture to
>> support them.  Also, narrower and shorter variants of some glyphs
>> would be handy, see
>> http://code.google.com/p/lilypond/issues/detail?id=2145 and
>> http://code.google.com/p/lilypond/issues/detail?id=2203. Requirements:
>> MetaFont, C++(?), good eye for details; basic LilyPond knowledge
>> recommended(?).
>
> This could be combined with the above to be a full project.

And i would be glad to take it.

>> 6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking
>> slurs and ties, ties on enharmonic notes are not supported { cis'~
>> des' }, ties "broken" by clef or staff change aren't supprted well,
>> etc. (as for bad shapes, i have a big report on ties halfway done, and
>> slur examples would need to be collected from mutopia or from users).
>> Requirements: C++, experience with writing heuristics; basic Scheme,
>> music notation and LilyPond knowledge recommended.  This project seems
>> really big to me, unless all of the research and testing would be done
>> by someone else (bad idea).
>
> This would take the entire summer if you added intelligent non-convex slurs.  
> Here I could most certainly help out - it was on my summer-of-lily list but 
> I'd gladly delegate to someone else!

Great!

>> 7) Grand Beam Project - there are cases of badly-looking beaming, even
>> in very simple snippets (again, i have a huge report on this matter
>> halfway-done). Also, beaming should depend on context and neighbor
>> notes (see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
>> section 2.2, i can also give some more examples).  Changing beam code
>> to do this looks like a fairly complicated matter. Requirements: C++,
>> experience with writing heuristics; basic music notation knowledge
>> recommended.
>
> Most beam problems that don't involve cross-staff or broken beams are fixable 
> with 1-20 lines of code.  If you send me concrete examples, I can likely 
> estimate how long it'd take.

I have 500+ examples that need to be sorted, described and (in some
cases) decided how the proper beaming should look like...  Wanna
Catch'em All? :P
And i meant to include cross-staff beams of course :)

Thanks for review!
Janek

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

Re: Google Summer of Code - Ideas List, please discuss

[Graham Percival]

On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
> 2) Adding comprehensive MusicXML import and export features, together
> with test suites for it.  Requirements: ? (no idea in which language
> this would be written), MusicXML, basic LilyPond and music notation
> knowledge; familiarity with other scorewriters would be a nice bonus
> (for cross-testing).  The goal would be considered achieved when a
> (previously chosen) not-so-complicated score could be imported from
> MusicXML and exported back with no (unintentional) loss of data.

umm, you know that we already have musicxml2ly import, right?

I agree with having this on the ideas list, but it should
definitely mention musicxml2ly.py and basic familiarity with
python.  The export would most likely be in scheme, although it's
not impossible to imagine that somebody might write a relatively
simple scheme exporter to an intermediate format (or just use
\displaymusic{} ), then use python to construct the actual
musicxml file.

> 5) Build System Improvement: if we want to ever move away from make,
> this would be a good opportunity.  Issues like thousands of errors and
> warnings during compilation should be removed, all dependancies fixed
> (so that one doesn't need to remove fonts folder to have fonts
> rebuilt).  Requirements: Python, Make and (optionally) another build
> system.

I think this item needs rewriting.  If Phil and Julien want to
highlight exactly what is left, great; otherwise I'd be tempted to
leave it out.

Then again, it's just possible that Phil or Julien might be
interested in being student in GSoC, in which case we should
definitely include this as a project.

> 6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking

Don't call it "Grand".  It would be a big chunk of work, sure, but
don't underestimate how much can be done in full-time work.




I'd add another item to the list:
n+1) clean up compiler warnings, static code analysis, and
valgrind warnings.  Automatic code analysis tools (warnings in g++
and clang) and analysis tools like valgrind memory leak detection
and callgrind code profilers provide valuable information about
possible flaws in C++ code.  It would be great if somebody could
clean up those warnings, as this would allow us to automatically
reject any patch which introduced extra warnings.  Once compiler
warnings are fixed, analysis of memory leaks and profiling would
be great.

- Graham

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

alternate GUB repo giving out access

[Graham Percival]

I've forked the GUB repo so I can easily give push access to
people like Mike:
https://github.com/gperciva/gub

The CG has been updated.

- 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)

[David Kastrup]

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

> It'll go up on Rietveld in a couple days unless anyone has any other
> global suggestions.  Many thanks to Han-Wen, David, and Janek for
> their feedback.

What's with the translate_scale_rotate stuff?  You only ever use the
scale components, and it does not appear like the axis of the transform
(and consequently of the scale components) are put to any use.  And it
also looks like this depends on a certain form of the transform matrix
(not being happy with skew matrices, for example).

That looks fishy.  What are you trying to do here?

-- 
David Kastrup


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

Re: Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

W dniu 12 lutego 2012 15:13 użytkownik Graham Percival
 napisał:
> On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
>> 2) Adding comprehensive MusicXML import and export features, together
>> with test suites for it.  Requirements: ? (no idea in which language
>> this would be written), MusicXML, basic LilyPond and music notation
>> knowledge; familiarity with other scorewriters would be a nice bonus
>> (for cross-testing).  The goal would be considered achieved when a
>> (previously chosen) not-so-complicated score could be imported from
>> MusicXML and exported back with no (unintentional) loss of data.
>
> umm, you know that we already have musicxml2ly import, right?

Yes.  I had some issues with it - dynamics got attached to wrong
notes.  So i basically meant "improve import and add export".

> I agree with having this on the ideas list, but it should
> definitely mention musicxml2ly.py and basic familiarity with
> python.

Sure.

>> 5) Build System Improvement: if we want to ever move away from make,
>> this would be a good opportunity.  Issues like thousands of errors and
>> warnings during compilation should be removed, all dependancies fixed
>> (so that one doesn't need to remove fonts folder to have fonts
>> rebuilt).  Requirements: Python, Make and (optionally) another build
>> system.
>
> I think this item needs rewriting.  If Phil and Julien want to
> highlight exactly what is left, great; otherwise I'd be tempted to
> leave it out.
>
> Then again, it's just possible that Phil or Julien might be
> interested in being student in GSoC, in which case we should
> definitely include this as a project.

Students can add their own proposals, ideas list is more like a
guideline.  So there will be no problem leaving this out and then
having Phil or Julien formulate their own proposal when they apply.

> I'd add another item to the list:
> n+1) clean up compiler warnings, static code analysis, and
> valgrind warnings.  Automatic code analysis tools (warnings in g++
> and clang) and analysis tools like valgrind memory leak detection
> and callgrind code profilers provide valuable information about
> possible flaws in C++ code.  It would be great if somebody could
> clean up those warnings, as this would allow us to automatically
> reject any patch which introduced extra warnings.  Once compiler
> warnings are fixed, analysis of memory leaks and profiling would
> be great.

that's nice.

thanks,
Janek

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

Re: git repository for osx-lilypond

[Graham Percival]

2012/2/11 Carl Sorensen :
> In order to try to track this down, I'd like to have a git history to see
> how things have changed. [...]
> Can anybody tell me where I might find an up-to-date repository?

https://github.com/gperciva/lilypad

As of 2012 Feb 12, this is the latest repository for lilypad (the
build-in editors for lilypond on OSX and windows).

Notes:
- this is the code which is used for our official GUB binaries.
- does not contain work that Patrick did on 2010-01-19:
http://repo.or.cz/w/lilypad-macos.git
  the same commits appear in this repository:
https://github.com/pnorcks/lilypad-macos




I am adding this to the CG, and I will then search for the windows
lilypad code.

- Graham

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

Re: git repository for osx-lilypond

[Graham Percival]

On Sun, Feb 12, 2012 at 03:05:31PM +, Graham Percival wrote:
> https://github.com/gperciva/lilypad

I knew I forgot something.  :(


I have renamed the macos-lilypad branch on savannah to:
  archive/macos-lilypad
Please do not pull or fetch to that branch.  I was reluctant to
delete it entirely just in case I made a mistake when extracting
the commits into the github repository.

- Graham

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

Checks to see that stencil commands have the correct number of arguments. (issue 5649054)

[dak]

http://codereview.appspot.com/5649054/diff/1/lily/stencil-expression.cc
File lily/stencil-expression.cc (right):

http://codereview.appspot.com/5649054/diff/1/lily/stencil-expression.cc#newcode31
lily/stencil-expression.cc:31: nargs = scm_permanent_object (scm_cons
(scm_cons (ly_symbol2scm ("dummy"), SCM_EOL), SCM_EOL));
dummy?

The whole stuff is totally incomprehensible.  It is not clear what is
stored where and for what reason, and there is no documentation
whatsoever.  It was bad before, agreed, but it has become much worse.

http://codereview.appspot.com/5649054/

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

archive/ branches on savannah

[Graham Percival]

In case it's not totally obvious, don't push anything to an
archive/ branch.  I've renamed a few old branches that might
mislead people, namely:
  web->  archive/web
  web-gop->  archive/web-gop
  macos-lilypad  ->  archive/macos-lilypad

- Graham

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

extract-texi-filenames - missing directories

[Phil Holmes]

When make doc is run, it complains about 3 missing directories - 
Documentation/hu/included; Documentation/cs/included and 
Documentation/zh/included.  We could add these to the list of "known missing 
directories" in extract-texi-filename.py, but that would be bad if they were 
created.  Anyone object if I create these as empty directories?


--
Phil Holmes



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

Re: Minor documentation nitpick

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Sunday, February 12, 2012 1:00 PM
Subject: Re: Minor documentation nitpick



Graham Percival  writes:


IIRC @var{} is displayed as @emph{@code{}}.


It isn't.  Not in Info.


I don't like using formatting commands directly, but let's do it
anyway.


Recipe for trouble with a multi-output format like Texinfo.  Either use
@var{position} or @samp{(x . y)}, those are intended forms.

--
David Kastrup



Thanks David.  @samp it is.

--
Phil Holmes



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

Re: extract-texi-filenames - missing directories

[Graham Percival]

On Sun, Feb 12, 2012 at 03:44:31PM -, Phil Holmes wrote:
> When make doc is run, it complains about 3 missing directories -
> Documentation/hu/included; Documentation/cs/included and
> Documentation/zh/included.  We could add these to the list of "known
> missing directories" in extract-texi-filename.py, but that would be
> bad if they were created.  Anyone object if I create these as empty
> directories?

I won't object, but git certainly will.  You cannot have empty
directories.

... actually, come to think of it, the build system itself would
complain if you _did_ have an empty directory, because then it
wouldn't be part of make dist.

- Graham

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

Re: extract-texi-filenames - missing directories

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel Team" 
Sent: Sunday, February 12, 2012 4:04 PM
Subject: Re: extract-texi-filenames - missing directories



On Sun, Feb 12, 2012 at 03:44:31PM -, Phil Holmes wrote:

When make doc is run, it complains about 3 missing directories -
Documentation/hu/included; Documentation/cs/included and
Documentation/zh/included.  We could add these to the list of "known
missing directories" in extract-texi-filename.py, but that would be
bad if they were created.  Anyone object if I create these as empty
directories?


I won't object, but git certainly will.  You cannot have empty
directories.

... actually, come to think of it, the build system itself would
complain if you _did_ have an empty directory, because then it
wouldn't be part of make dist.

- Graham



Could put the standard Documentation/*/included/GNUmakefile in there?

--
Phil Holmes



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

Re: extract-texi-filenames - missing directories

[Graham Percival]

On Sun, Feb 12, 2012 at 04:13:42PM -, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> 
> To: "Phil Holmes" 
> Cc: "Devel Team" 
> Sent: Sunday, February 12, 2012 4:04 PM
> Subject: Re: extract-texi-filenames - missing directories

> >... actually, come to think of it, the build system itself would
> >complain if you _did_ have an empty directory, because then it
> >wouldn't be part of make dist.
> 
> Could put the standard Documentation/*/included/GNUmakefile in there?

That's be ok.

- Graham

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

Fwd: bar number collides with staff bracket when bass-clef is used

[Colin Hall]

Hi,

Reinhold has reported a bug against 2.15.30, which has not yet been released, 
so I'm forwarding this to the developer list.

Cheers,
Colin.


- Forwarded message from Reinhold Kainhofer  
-

Date: Sun, 12 Feb 2012 16:36:26 +0100
From: Reinhold Kainhofer 
To: bug-lilypond 
Subject: bar number collides with staff bracket when bass-clef is used

If the first staff of a score a group bracket uses a bass clef, the
bar number (when center-aligned) collides with the bracket. Attached
is an example.

Cheers,
Reinhold

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


\version "2.15.30"

\score {
  \new StaffGroup << 
\new Staff \relative c {
  \override Score.BarNumber #'self-alignment-X = #CENTER % center-aligned
%   \bar""
  \clef "bass"
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
}
\new Staff \relative c {
%   \bar""
  \clef "bass"
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
  c1 | c1 | c | c | \break
}

  >>
}


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


- End forwarded message -

-- 

Colin Hall
South Mains
West Linton
EH46 7AY
Scotland

Tel: 01968 661994
Mob: 07786 677582

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

Re: Dubious recommendation about ragged-last-bottom in spacing.itely

[Pavel Roskin]

Quoting David Kastrup :


2012/2/10 Pavel Roskin :

I believe the opposite should be suggested.  Large scores should set
ragged-last-bottom to false.  For a large score, it's easy to fill a
whole number of pages without much distortion.  Doing so increases
readability of the piece without increasing the number of the page
turns.


It depends on how well our penalty system works.  If you fill three
pages anyway, you want your breaks at places where a page turn makes
good sense.  Even if one page is short.  If LilyPond has no way to
figure out one page break being better than another, it might as well
spread the material evenly over pages.  But other than that, I don't see
that filling the last page should necessarily "increase readability".

Just having choices #f and #t is also not really optimal.


I agree that having more choices would be good.  But since there is a  
suggestion in the documentation, let's suggest the best of what we can  
offer.  Now that the issue 2102 has been fixed, ragged-last-bottom=#f  
can be a reasonable suggestion for large pieces with no manual page  
breaks.  It's still a suggestion; it can be safely ignored.  It's not  
even the default.


Speaking of the defaults, the default system-to-system distance is too  
short for my taste.  It may be OK it would save a page turn.  However,  
it's used on the last page with ragged-last-bottom=#t even if there is  
enough space on the page to use the same system-to-system distance as  
on the previous page.  Often the last page has the worst layout  
compared to previous pages.


--
Regards,
Pavel Roskin

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

Re: Dubious recommendation about ragged-last-bottom in spacing.itely

[David Kastrup]

Pavel Roskin  writes:

> Speaking of the defaults, the default system-to-system distance is too
> short for my taste.  It may be OK it would save a page turn.  However,
> it's used on the last page with ragged-last-bottom=#t even if there is
> enough space on the page to use the same system-to-system distance as
> on the previous page.  Often the last page has the worst layout
> compared to previous pages.

Huh?

http://code.google.com/p/lilypond/issues/detail?id=1377>

Fixed_2_15_23

-- 
David Kastrup


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

Re: extract-texi-filenames - missing directories

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel Team" 
Sent: Sunday, February 12, 2012 4:30 PM
Subject: Re: extract-texi-filenames - missing directories



On Sun, Feb 12, 2012 at 04:13:42PM -, Phil Holmes wrote:

- Original Message - From: "Graham Percival"

To: "Phil Holmes" 
Cc: "Devel Team" 
Sent: Sunday, February 12, 2012 4:04 PM
Subject: Re: extract-texi-filenames - missing directories



>... actually, come to think of it, the build system itself would
>complain if you _did_ have an empty directory, because then it
>wouldn't be part of make dist.

Could put the standard Documentation/*/included/GNUmakefile in there?


That's be ok.

- Graham


Pushed to staging as 18cfd801fa7fcd698e924f3b530862714f3e3013

Also - confirming that this does remove the errors.


--
Phil Holmes



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

Re: Minor documentation nitpick

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: ; "David Kastrup" 
Sent: Sunday, February 12, 2012 3:46 PM
Subject: Re: Minor documentation nitpick


- Original Message - 
From: "David Kastrup" 

To: 
Sent: Sunday, February 12, 2012 1:00 PM
Subject: Re: Minor documentation nitpick



Graham Percival  writes:


IIRC @var{} is displayed as @emph{@code{}}.


It isn't.  Not in Info.


I don't like using formatting commands directly, but let's do it
anyway.


Recipe for trouble with a multi-output format like Texinfo.  Either use
@var{position} or @samp{(x . y)}, those are intended forms.

--
David Kastrup



Thanks David.  @samp it is.

--
Phil Holmes


Pushed to staging as 18cfd801fa7fcd698e924f3b530862714f3e3013

Also - confirming that this does remove the errors.



--
Phil Holmes



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

Re: git repository for osx-lilypond

[Christian Hitz]

Am 11.02.2012 um 19:57 schrieb Carl Sorensen:

> On 2/11/12 5:30 AM, "Graham Percival"  wrote:
> 
>> On Sat, Feb 11, 2012 at 09:32:11AM +0100, Janek Warchoł wrote:
>>> 2012/2/11 Carl Sorensen :
 In order to try to track this down, I'd like to have a git history to
>>> see
 how things have changed. [...]
 Can anybody tell me where I might find an up-to-date repository?
>> 
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads
>> /macos-lilypad
>> 
>> but the two-line fix for 10.4 ppc support would occur in GUB, not
>> in osx-lilypad.
> 
> Yes, and I'm aware of that two-line fix.  It gives ppc support, but I
> think it also gives a bad version of LilyPond when the About menu item is
> checked.  I may be wrong on this.  I want to check the sources before I
> make the final decision.

The app bundle contains the version that was current at the time of the
creation of the bundle.
If I understood GUB correctly the version should be corrected in the 
Info.plist file when building the installer package right here:

https://github.com/janneke/gub/blob/master/gub/installer.py#L341

But when I compare these instructions to the version strings I have put 
into the 0.6 bundle, it becomes clear why the version is not being updated:

- for the Info.plist I omitted the build suffix (only 2.15.22 instead of 
2.15.22-1)
- at some time I have bumped the version string in Credits.html and 
  Welcome-to-LilyPond-MacOS.ly to 2.14 but installer.py expects 2.12

Should I tune osx-lilypad-universal-0.6.tar.gz to be compatible with GUB's 
installer.py?

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

Re: Dubious recommendation about ragged-last-bottom in spacing.itely

[Pavel Roskin]

Quoting David Kastrup :


Pavel Roskin  writes:


Speaking of the defaults, the default system-to-system distance is too
short for my taste.  It may be OK it would save a page turn.  However,
it's used on the last page with ragged-last-bottom=#t even if there is
enough space on the page to use the same system-to-system distance as
on the previous page.  Often the last page has the worst layout
compared to previous pages.


Huh?

http://code.google.com/p/lilypond/issues/detail?id=1377>

Fixed_2_15_23


Indeed, I confirm it.  I still use Lilypond 2.14.2 for scores I intend  
to submit to Mutopia, so I remembered that the last pages didn't look  
good.  So I checked the documentation about ragged bottom and found  
that it should be true.  It just occurred to me recently that the  
documentation likely meant "false".


By the way, the documentation still needs to be updated:
http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-_005cpaper-variables


If a page has a ragged bottom, the resulting distance is the largest of:

basic-distance,
minimum-distance, and
padding plus the smallest distance necessary to eliminate collisions.


Not anymore, and it's a good thing!

--
Regards,
Pavel Roskin

___
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 12, 2012, at 3:40 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> It'll go up on Rietveld in a couple days unless anyone has any other
>> global suggestions.  Many thanks to Han-Wen, David, and Janek for
>> their feedback.
> 
> What's with the translate_scale_rotate stuff?  You only ever use the
> scale components, and it does not appear like the axis of the transform
> (and consequently of the scale components) are put to any use.  And it
> also looks like this depends on a certain form of the transform matrix
> (not being happy with skew matrices, for example).
> 
> That looks fishy.  What are you trying to do here?

Account for line thickness.  I actually have no clue how thickness works.  Is 
thickness in PS and SVG always added perpendicularly on either side (meaning 
thick/2 on both sides) of the line that is the slope of a curve at a given 
point?

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

PATCH: Countdown to 20120214

[Colin Campbell]

For 20:00 MST Tuesday, February 14: surprise your Valentine!

Critical:
Issue 2301 
: Patch: Fixes 
cross stem glissandi - R 5646043 


Enhancement:
 Issue 2308 
: Patch: Checks 
to see that stencil commands have the correct number of arguments. - R 
5649054 
 Issue 2310 
: Patch: some 
comments and complaints on the code - R 5651069 

 Issue 2312 
: Patch: Doc: 
recommend setting ragged-last-bottom to false for large scores - R 
5651077 


Patch:
Issue 2311 
: Patch: Final 
redirection of texi output - R 5650064 




On reflection, a thoughtful patch review might *not* be the best thing 
for your valentine, unless they develop lilypond code!


Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: PATCH: Countdown to 20120214

[Colin Campbell]

On 12-02-12 06:55 PM, Colin Campbell wrote:

For 20:00 MST Tuesday, February 14: surprise your Valentine!

Critical:
Issue 2301 
: Patch: 
Fixes cross stem glissandi - R 5646043 



Enhancement:
 Issue 2308 
: Patch: 
Checks to see that stencil commands have the correct number of 
arguments. - R 5649054 
 Issue 2310 
: Patch: some 
comments and complaints on the code - R 5651069 

 Issue 2312 
: Patch: Doc: 
recommend setting ragged-last-bottom to false for large scores - R 
5651077 


Patch:
Issue 2311 
: Patch: 
Final redirection of texi output - R 5650064 




On reflection, a thoughtful patch review might *not* be the best thing 
for your valentine, unless they develop lilypond code!





In fact, in the spirit of the occasion, let's add one more which I 
overlooked:


Maintainability:
Issue 2092 
: lily-git.tcl 
should using a "working" branch - R 5504092 




Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: some comments and complaints on the code (issue 5651069)

[joeneeman]

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc#newcode211
lily/accidental-placement.cc:211: * @return A vector of
Accidental_placement_entrys
On 2012/02/11 12:27:31, Milimetr88 wrote:

Do you mean @param and @return or the comment to the function? What

comment

would you propose?


I'm complaining about the @return comment, since it's redundant (ie. no
need to change it, just remove that line). I'm ok with the @param
comment, because you can't tell from the function signature that accs is
supposed to be a list.

http://codereview.appspot.com/5651069/

___
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]

On Thu, Feb 9, 2012 at 9:50 AM, m...@apollinemike.com  wrote:

> On Feb 7, 2012, at 6:47 PM, m...@apollinemike.com wrote:
>
>
> I did some experiments with caching that are up on:
> dev/skylines-cached
>
>
> Hey all,
>
> Fresh branch up at dev/skylines-cached.  This patch should only increase
> compilation time of a LilyPond score by 1-2 seconds for every minute.
>

Wow, that's quite some work you've done. I haven't read it carefully yet,
but here are some broad suggestions/comments:

Regarding your comment in axis-group-interface.cc:802, if it gets called
twice, there's a bug (usually caused because we've asked for the extent of
a cross-staff grob before line-breaking has happened). I'm fine with trying
to detect the bug and continue, but I think there should be a
programming_error (at least for NDEBUG builds; see the way cyclic
dependencies are reported in grob-property.cc).

Since you seem to be expanding the scope of skylines, you may want to add
some more flexible constructors instead of doing everything with boxes. For
example, it should be easy to add a skyline constructor that builds a
skyline from a collection of line segments. Then you can approximate
beziers with line segments instead of boxes. I think I even had some code
for this lying around, but I can't find it now...

add_grobs_of_one_priority looks ok, but a bit complicated. It would be
simpler if you got rid of the boxes altogether and only used skylines. You
could "hardcode" ly:grob::vertical-skylines-from-stencil as a default for
vertical-skylines in the same way that ly:grob::stencil-height is hardcoded
as a default for Y-extent. Then you can assume that every grob has a
skyline.

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