Re: an LM update

[Trevor Daniels]

James, you wrote Monday, March 23, 2009 7:59 PM


Am 23.03.2009 um 18:03 schrieb Trevor Daniels:



James E. Bailey wrote Monday, March 23, 2009 4:45 PM


Am 23.03.2009 um 16:48 schrieb Trevor Daniels:


James E. Bailey wrote Monday, March 23, 2009 2:15 PM


In any event, hopefully this is an acceptable patch. Whether 
or not
introduction of single-staff polyphony should be kept at this 
point
in the LM (since doing so does not follow Documentation 
policy)

is a
different conversation.


The good news is the patch works fine and the docs still
compile with it applied.  So I've applied it and
pushed it to origin/master.  I can't say I'm wild about it,
as it uses so many concepts which have not been introduced
at that point, so it will probably be moved when I get back
to working on the LM, but in an odd-numbered release I'm
prepared to accept it.


But, as I said before, I think that removing it altogether is
also a
bad idea. Perhaps a simple warning that the section introduces
several new concepts that haven't been fully explained with
links to
the appropriate sections that do explain them fully would be
enough.


Would you like to prepare another patch which does this?
That would be an improvement.


I don't really understand how to do links in I guess this is
TexInfo (?) format.


Yes:(  Hardly the world's best mark-up language.  There's
an introduction to it in CG 3 which is sufficient for LP
docs.  (Actually I can't see the @ref{} command and friends
there.  Are they in the CG, Graham?)

You know, I'd read the relevant sections before, but it didn't
explain the @-commands too well, so I was left feeling like I 
hadn't
learned anything I didn't already know. I also took a short look 
at
the Texinfo link there, but that seemed like it would be far too 
much

reading for what would amount to such a small change.


I can write the paragraph explaining that it introduces 
concepts
not yet discussed, and that it may be confusing. But the @ 
things

just look funny to me.


They're not too bad really.  There are plenty of examples
in the docs!  Why not have a go at formatting your
paragraph?  All you need is an @ref{} to do a link to a section
in the same manual.  Just copy one of the examples.  I'll check
your patch through and make sure it compiles before pushing
it to origin/master.

Well, my attempt is attached. I don't really know if it works, but
you can tell me that.


Thanks!

It almost worked.  I had to change @ruser{}, which adds
a ref to the Notation Reference, to @ref{} which adds a
ref to the current manual.  If you refresh your git
repository from origin/master you'll see your and my
commits.  For future reference (no pun intended), could
you preface your commit message with "Docs: " and spread
it out over more than one line if it is long.  Normally
we prefer a short one line summary, then a blank line,
then more lines giving the details.

I think you're ready to tackle LM 3.2 now :P

Trevor



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

Re: an LM update

[James E. Bailey]

Am 24.03.2009 um 10:55 schrieb Trevor Daniels:


James, you wrote Monday, March 23, 2009 7:59 PM


Am 23.03.2009 um 18:03 schrieb Trevor Daniels:



James E. Bailey wrote Monday, March 23, 2009 4:45 PM


Am 23.03.2009 um 16:48 schrieb Trevor Daniels:


James E. Bailey wrote Monday, March 23, 2009 2:15 PM


In any event, hopefully this is an acceptable patch. Whether  
or not
introduction of single-staff polyphony should be kept at this  
point

in the LM (since doing so does not follow Documentation policy)
is a
different conversation.


The good news is the patch works fine and the docs still
compile with it applied.  So I've applied it and
pushed it to origin/master.  I can't say I'm wild about it,
as it uses so many concepts which have not been introduced
at that point, so it will probably be moved when I get back
to working on the LM, but in an odd-numbered release I'm
prepared to accept it.


But, as I said before, I think that removing it altogether is
also a
bad idea. Perhaps a simple warning that the section introduces
several new concepts that haven't been fully explained with
links to
the appropriate sections that do explain them fully would be
enough.


Would you like to prepare another patch which does this?
That would be an improvement.


I don't really understand how to do links in I guess this is
TexInfo (?) format.


Yes:(  Hardly the world's best mark-up language.  There's
an introduction to it in CG 3 which is sufficient for LP
docs.  (Actually I can't see the @ref{} command and friends
there.  Are they in the CG, Graham?)

You know, I'd read the relevant sections before, but it didn't
explain the @-commands too well, so I was left feeling like I hadn't
learned anything I didn't already know. I also took a short look at
the Texinfo link there, but that seemed like it would be far too much
reading for what would amount to such a small change.



I can write the paragraph explaining that it introduces concepts
not yet discussed, and that it may be confusing. But the @ things
just look funny to me.


They're not too bad really.  There are plenty of examples
in the docs!  Why not have a go at formatting your
paragraph?  All you need is an @ref{} to do a link to a section
in the same manual.  Just copy one of the examples.  I'll check
your patch through and make sure it compiles before pushing
it to origin/master.

Well, my attempt is attached. I don't really know if it works, but
you can tell me that.


Thanks!

It almost worked.  I had to change @ruser{}, which adds
a ref to the Notation Reference, to @ref{} which adds a
ref to the current manual.


Yeah, see, those are those @-commands that I don't understand.


  If you refresh your git
repository from origin/master you'll see your and my
commits.


That means git pull, right?


  For future reference (no pun intended), could
you preface your commit message with "Docs: " and spread
it out over more than one line if it is long.  Normally
we prefer a short one line summary, then a blank line,
then more lines giving the details.


That is wonderful information to add to CG 1.3.1


I think you're ready to tackle LM 3.2 now :P


I like that you have a sense of humor.



Trevor


James


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

Re: an LM update

[Trevor Daniels]

James E. Bailey wrote Tuesday, March 24, 2009 11:55 AM


Am 24.03.2009 um 10:55 schrieb Trevor Daniels:


It almost worked.  I had to change @ruser{}, which adds
a ref to the Notation Reference, to @ref{} which adds a
ref to the current manual.


Yeah, see, those are those @-commands that I don't understand.


I've found them now - they're listed in CG 3.3.2


  If you refresh your git
repository from origin/master you'll see your and my
commits.


That means git pull, right?


Right


  For future reference (no pun intended), could
you preface your commit message with "Docs: " and spread
it out over more than one line if it is long.  Normally
we prefer a short one line summary, then a blank line,
then more lines giving the details.


That is wonderful information to add to CG 1.3.1


OK - added in git


I think you're ready to tackle LM 3.2 now :P


I like that you have a sense of humor.



Well, I'm sure you -could- do this.  But as an easy
starter how about a link to NR 1.5.2 from your new
para in the LM?  Perhaps prefaced by something like,
"a quick introduction to polyphony (without explanation)
is given in ...".

Trevor



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

Re: an LM update

[Graham Percival]

On Mon, Mar 23, 2009 at 05:03:28PM -, Trevor Daniels wrote:
>
> James E. Bailey wrote Monday, March 23, 2009 4:45 PM
>>
>> I don't really understand how to do links in I guess this is TexInfo 
>> (?) format.
>
> Yes:(  Hardly the world's best mark-up language.  There's
> an introduction to it in CG 3 which is sufficient for LP
> docs.  (Actually I can't see the @ref{} command and friends
> there.  Are they in the CG, Graham?)

Well, CG 3 came directly from the GDP helper text, so they
should be there somewhere...

... huh.  They're only used in the "order of items inside a
@section" part.  That's not ideal.  I've added it to syntax
survey.


But the most important part of this entire chapter is the @warning
in CG 3.2.1 -- "rule of thumb: follow the examples in the existing
docs".

Cheers,
- Graham


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

Re: an LM update

[Graham Percival]

On Mon, Mar 23, 2009 at 04:52:58PM +0100, Francisco Vila wrote:
> 2009/3/23 Francisco Vila :
> 
> > I have git version 1.5.6.3 and both git-format-patch and
> > git[nohyphen]format-patch do work.
> >
> > James, what's the output of git --version?
> 
> From your patch I see it is 1.6.2.1 ; has the hyphenated command been
> deprecated?

Yes.  This was discussed on this mailist in Dec or Jan; the CG was
updated accordingly.

Cheers,
- Graham


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

Re: an LM update

[James E. Bailey]

Am 24.03.2009 um 13:42 schrieb Trevor Daniels:James E. Bailey wrote Tuesday, March 24, 2009 11:55 AM Am 24.03.2009 um 10:55 schrieb Trevor Daniels: It almost worked.  I had to change @ruser{}, which addsa ref to the Notation Reference, to @ref{} which adds aref to the current manual. Yeah, see, those are those @-commands that I don't understand. I've found them now - they're listed in CG 3.3.2   If you refresh your gitrepository from origin/master you'll see your and mycommits. That means git pull, right? Right   For future reference (no pun intended), couldyou preface your commit message with "Docs: " and spreadit out over more than one line if it is long.  Normallywe prefer a short one line summary, then a blank line,then more lines giving the details. That is wonderful information to add to CG 1.3.1 OK - added in git I think you're ready to tackle LM 3.2 now :P I like that you have a sense of humor. Well, I'm sure you -could- do this.  But as an easystarter how about a link to NR 1.5.2 from your newpara in the LM?  Perhaps prefaced by something like,"a quick introduction to polyphony (without explanation)is given in ...".Trevor Leave it to me to take something easy and make it difficult. So, I had a conflict. I thought I resolved it, but now tutorial.itely looks funny. I don't know how to get back to just having the normal files without any changes that I've made, and I don't know if the conflict is resolved properly, but here's my next attempt. James E. Bailey

0003-Docs.patch
Description: Binary data
 ___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an LM update

[John Mandereau]

Hi James,
James E. Bailey a écrit :
Leave it to me to take something easy and make it difficult. So, I had 
a conflict. I thought I resolved it, but now tutorial.itely looks 
funny. I don't know how to get back to just having the normal files 
without any changes that I've made, and I don't know if the conflict 
is resolved properly, but here's my next attempt.
Please take half an hour to read sections "HOW CONFLICTS ARE PRESENTED" 
and "HOW TO RESOLVE CONFLICTS" in "git merge" documentation (the man 
page if you're on Linux, or in HTML on Git web site anyway), as 
suggested in the CG.  I know you've already been making significant 
effort to get used to Git and Texinfo, but that's really worth it: after 
this, you'll never be scared by conflicts any more.


Cheers,
John


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

Re: an LM update

[Trevor Daniels]

James, your wrote Tuesday, March 24, 2009 2:27 PM


Leave it to me to take something easy and make it difficult. So, I
had a conflict. I thought I resolved it, but now tutorial.itely 
looks
funny. I don't know how to get back to just having the normal 
files
without any changes that I've made, and I don't know if the 
conflict

is resolved properly, but here's my next attempt.


This isn't right.  It looks like you've edited the version of
tutorial.itely that you sent the last time, rather than the one
you should have pulled from origin/master, which has the
fix-ups I added.  That's why you had a conflict when you tried
to commit it.

Did you do a pull before starting the edit to get the latest
version of tutorial.itely?  If so, did you reload the file into
your editor?  These seem the two likely possibilities.

Have you come across git gui and gitk yet?  If not, this is a good
time to play with them.  There's an intro to them in CG 1.5.
Yes, I know this is git for Windows, but git gui and gitk work on
other systems too.  They make it far easier to visualise what is
happening, especially when you need to reset a branch, as I
think this is will be the easiest way to remove your incorrect
file.

Keep asking questions if you need to.

Trevor



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

odd configure error

[James E. Bailey]

I'm having a configure error, and I don't know how to solve it. I get  
this:


ERROR: Please install required programs:  /Users/lilydev/bin/ 
fontforge >= 20050624 (installed: .fontforge 20080927)


See INSTALL.txt for more information on how to build LilyPond

The version of fontforge installed is newer than the one required.  
Should I try and find an older version?


James E. Bailey



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

Re: an LM update

[James E. Bailey]

Am 24.03.2009 um 17:15 schrieb John Mandereau:


Hi James,
James E. Bailey a écrit :
Leave it to me to take something easy and make it difficult. So, I  
had a conflict. I thought I resolved it, but now tutorial.itely  
looks funny. I don't know how to get back to just having the  
normal files without any changes that I've made, and I don't know  
if the conflict is resolved properly, but here's my next attempt.
Please take half an hour to read sections "HOW CONFLICTS ARE  
PRESENTED" and "HOW TO RESOLVE CONFLICTS" in "git merge"  
documentation (the man page if you're on Linux, or in HTML on Git  
web site anyway), as suggested in the CG.  I know you've already  
been making significant effort to get used to Git and Texinfo, but  
that's really worth it: after this, you'll never be scared by  
conflicts any more.


Cheers,
John


You know, I found the page on the website and thought I had  
successfully followed it (that is, until I saw the funny file), but I  
guess it didn't work out so well. I'm just going to delete the folder  
and start again from scratch.


James E. Bailey



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

Re: Strange fret alignment

[Carl D. Sorensen]

On 3/24/09 2:29 PM, "Neil Puttock"  wrote:

> 2009/3/23 Carl D. Sorensen :
>> Yes, it has to do with the origins.  They're different for each orientation.
>> It's on my list to fix them.
> 
> Ah, I see.  Sorry for the noise. :)

Not at all!  I'm always glad to have somebody looking out for things like
this.

Carl



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

PATCH: GUB: Add pointer to Help web page to Windows installer

[Carl D. Sorensen]

Jan,

I've searched through the NSIS documentation, and I think I figured out how
to fix the installer.

I don't really want to get into the GUB configuration mess to try to get
this patch applied.

Would you be willing to apply the patch, do GUB build, and point me to a
download of the Mingw version so I can test it?

Thanks

Carl



0001-Add-message-to-Windows-intaller-pointing-to-Help-pag.patch
Description:  0001-Add-message-to-Windows-intaller-pointing-to-Help-pag.patch
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Is the description in IR for force-hshift incorrect?

[Neil Puttock]

Hi everybody,

The IR gives the following description for 'force-hshift:

`This specifies a manual shift for notes in collisions. The unit is
the note head width of the first voice note.'

Am I mistaken if I understand this to mean that any shifts are scaled
in terms of the noteheads in \voiceOne?

Every example I've tested points to the unit being the first head in
the lower voice (\voiceTwo).  Consider the following snippet:

\relative c'' {
  << {
c4*4
\once \override NoteColumn #'force-hshift = #1
c4*4
c1
  }
  \\
  {
a1
a1
\once \override NoteColumn #'force-hshift = #1
a4*4
  }
  >>
}

In the second bar, the upper voice is shifted to the right one
semibreve space, whereas the shifted lower voice in the third bar is
clearly moved the width of a filled notehead; both results imply the
unit to be the notehead in the lower voice.

Judging by the code in note-collision.cc, I can't imagine a situation
(at least in the polyphonic case) whereby the the upper voice will
determine the spacing increment; the following code always seems to
return the width of the first head in \voiceTwo:

 375   Real wid = 0.0;
 376   do
 377 {
 378   if (clash_groups[d].size ())
 379 {
 380   Grob *h = clash_groups[d][0];
 381   Grob *fh = Note_column::first_head (h);
 382   if (fh)
 383 wid = fh->extent (h, X_AXIS).length ();
 384 }
 385 }
 386   while (flip (&d) != UP);

Regards,
Neil
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix key signatures with accidentals in specific octave.

[joeneeman]

lgtm, except for the description "move check_pitch_against_signature ()
to SCM," since ly:check-pitch-against-signature is still implemented in
C++.

http://codereview.appspot.com/11052


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

Re: Fix key signatures with accidentals in specific octave.

[n . puttock]

Reviewers: joeneeman,

Message:
On 2009/03/24 23:06:42, joeneeman wrote:

lgtm, except for the description "move check_pitch_against_signature

() to SCM,"

since ly:check-pitch-against-signature is still implemented in C++.


Erk.

I misinterpreted that to mean exporting check_pitch_against_signature as
a Scheme function.

I guess it would be better to rework the whole thing in Scheme.

Description:
Fix key signatures with accidentals in specific octave.
- when testing whether a pitch matches the key signature, try using
  keySignature if no match is found in localKeySignature.

- move check_pitch_against_signature () to SCM, passing context instead
  of localKeySignature

- remove ly:find-accidentals-simple

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

Affected files:
  A input/regression/key-signature-scordatura-persist.ly
  M lily/accidental-engraver.cc
  M scm/music-functions.scm




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

GUB3 at the lilypond-installer stage

[Patrick McCarty]

Hi Jan,

I'm now building GUB3 with 64-bit Arch Linux, so I can no longer test
the 32-bit OS / 64-bit hardware quirks, but it seems like most of
those were ironed out.

The patch I posted here [1] still works for me on my new setup, i.e.
darwin-x86::gmp builds fine, if you want to apply it.

[1] http://lists.gnu.org/archive/html/lilypond-devel/2009-03/msg00019.html

I am running into some weird issues with darwin-ppc::guile and
darwin-x86::guile, but I can't reproduce them all the time, so I'll
post later about that.

Right now, at the lilypond-installer stage, GUB fails and attached is
the installer.log.


Thanks,
Patrick


 * Starting build: Tue Mar 24 14:01:08 2009
 *** Stage: build (installer, linux-x86)
invoking rm -fr 
/home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master-dbdir
invoking mkdir -p 
/home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master-dbdir
invoking mkdir -p 
/home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master
installing package: libtool-runtime
untarring: 
/home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup
Running read_pipe
  ('tar -t -z -f 
"/home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup"',)
  {}
invoking tar -C 
/home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master
 -p -x -z -f 
/home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup
/home/pnorcks/git/gub/target/tools/root/usr/bin/tar: tried to open () file 
/home/pnorcks/git/gub/.
allowed:
  /home/pnorcks/git/gub/target
  /tmp
  /dev/null

gzip: stdout: Broken pipe
Command barfed: tar -C 
/home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master
 -p -x -z -f 
/home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: Add link to help page to Windows download

[Carl D. Sorensen]

I've added a patch to put a reference to the non-graphical nature of
LilyPond on the Windows download page for 2.12.2.

I've checked it out as much as I can on my machine, where I don't have
inkscape available to the command line for purposes of handling the
graphics.  The website, sans graphics, seems to do want I want it to.

I'd like to have somebody who can build the website check the patch and make
sure it doesn't break the website, then apply it.

Otherwise, I'll apply it and hope it doesn't break the website (there's no
reason I can think of that it should).

Thanks,

Carl



0001-Add-link-to-help-page-to-Windows-download.patch
Description: 0001-Add-link-to-help-page-to-Windows-download.patch
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How do you run/open Lilypond?

[Carl D. Sorensen]

On 3/24/09 1:22 PM, "Trevor Daniels"  wrote:

> I agree with all you suggest, Carl.  How do we
> make this change?

OK, as far as I know, I've either pushed or proposed patches to implement
all my recommendations.

1) Patch to change Welcome_to_LilyPond.ly has been pushed to git.
2) Patch to add notification to installer window had been proposed to Jan
3) Patch to add link to help page on download page of website has been
proposed to -devel.

Items 1 and 2 will require a new release of 2.12 to become effective.

Item 3 can become effective immediately, as soon as the website is rebuilt.

Thanks,

Carl
> 
> Trevor
> 
> - Original Message -
> From: "Carl D. Sorensen" 
> To: "Jan Nieuwenhuizen" ; "Jonathan Kulp"
> 
> Cc: "Jeb" ; 
> Sent: Tuesday, March 24, 2009 6:53 PM
> Subject: Re: How do you run/open Lilypond?
> 
> 
> 
> 
> 
> On 3/24/09 9:13 AM, "Jan Nieuwenhuizen" 
> wrote:
> 
>> Op dinsdag 24-03-2009 om 09:55 uur [tijdzone -0500], schreef
>> Jonathan
>> Kulp:
>> 
>>> Check the third question/answer on this page:
>>> 
>>> http://lilypondwiki.tuxfamily.org/index.php?title=FAQ
>> 
>> Why do we have to send a mail to point to a faq on some off-site
>> wiki?
> 
> There is a Help link on lilypond.org, which tells the user exactly
> how to
> fix things.  So we don't need to have the mail point to the off-site
> wiki.
> It could point to
> 
> 
> 
> 
>> 
>> Can't we make lilypond pop-up a web page when invoked without
>> arguments
>> or something like that?
> 
> On my fresh installation of LilyPond 2.12 in Win XP, when I
> double-click on
> the LilyPond icon on my desktop, it opens up to the source file
> Welcome_to_LilyPond.ly which mentions the non-GUI nature of
> LilyPond.
> Granted, you have to read it carefully, because it's in the source,
> but...
> 
> Similarly, when I use the program menu to run LilyPond, it opens up
> Welcome_to_LilyPond.ly.
> 
> So I think we're already getting a pop up window, just not a pop-up
> html
> window.
> 
> Perhaps we need to put more explicit links in Welcome_to_LilyPond.ly
> Currently it reads:
> 
> %{
> Welcome to LilyPond
> ===
> 
> Congratulations, LilyPond has been installed successfully.
> 
> Now to take it for the first test run.
> 
>   1. Save this LilyPond file on your desktop with the name
> "test.ly".
> 
>   2. Pick it up from the desktop with your mouse pointer, drag and
> drop
>  it onto the LilyPond icon.
> 
>   3. LilyPond automatically produces a PDF file from the musical
> scale
>  below.
> 
>   4. To print or view the result, click on the newly produced file
>  called
> 
> test.PDF
> 
> 
> That's it.
> 
> LilyPond's interface is text-based. Please read the documentation.
> 
> For more information, visit http://lilypond.org .
> %}
> 
> \version "2.12.0"  % necessary for upgrading to future LilyPond
> versions.
> 
> \header{
>   title = "A scale in LilyPond"
> }
> 
> \relative c' {
>   c d e f g a b c
> }
> 
> %% END OF ORIGINAL FILE
> 
> What if we changed it to:
> 
> %{
> Welcome to LilyPond
> ===
> 
> Congratulations, LilyPond has been installed successfully.
> 
> Now to take it for the first test run.
> 
>   1. Save this LilyPond file on your desktop with the name
> "test.ly".
> 
>   2. Pick it up from the desktop with your mouse pointer, drag and
> drop
>  it onto the LilyPond icon.
> 
>   3. LilyPond automatically produces a PDF file from the musical
> scale
>  below.
> 
>   4. To print or view the result, click on the newly produced file
>  called
> 
> test.PDF
> 
>5.  If you see a piece of music with a scale, LilyPond is
> performing
>properly.
> 
>  Next, you'll want to get started on your own scores.  To do this,
> you'll
>need to learn about using LilyPond.
> 
> LilyPond's interface is text-based, rather than graphical.  Please
> visit
>the help page at http://lilypond.org/web/help.  This will point
> you to
>a quick tutorial and extensive documentation.
> 
>  Good luck with LilyPond!
> 
> %}
> 
> \version "2.12.0"  % necessary for upgrading to future LilyPond
> versions.
> 
> \header{
>   title = "A scale in LilyPond"
>subtitle = "For more information on using LilyPond, please see
> http://lilypond.org/web/help/";
> }
> 
> \relative c' {
>   c d e f g a b c
> }
> 
> %%%  END OF REVISED FILE
> 
> Maybe we could also put a comment on the download page for Windows.
> For
> FreeBSD, there is a comment that talks about what to do when you
> download
> the file.  Perhaps it could say something like "After installing,
> please
> visit http://lilypond.org/web/help";
> 
> Perhaps we could also put a message in the main installing box for
> Windows.
> Right now it's blank.  It could read:  "Please note that LilyPond is
> a
> command-line application, not a GUI application.  After
> installation, please
> visit http://lilypond.org/web/help";
> 
>> 
>> I can imagine that not everyone who hits this goes throu

[PATCH] Fix misalignment when merging 8ths (up) & half notes (down)

[Neil Puttock]

Hi,

Please review this patch:

http://codereview.appspot.com/27108/show

I haven't added a regtest since I believe it's covered by
collision-merge-differently-headed.ly (see attached).

Regards,
Neil
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Fix misalignment when merging 8ths (up) & half notes (down)

[Han-Wen Nienhuys]

LGTM.

2009/3/24 Neil Puttock :
> Hi,
>
> Please review this patch:
>
> http://codereview.appspot.com/27108/show
>
> I haven't added a regtest since I believe it's covered by
> collision-merge-differently-headed.ly (see attached).
>
> Regards,
> Neil
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>



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