Re: RFC: new vertical layout engine
"Anthony W. Youngman" writes: > In message <20090725.163011.184567355...@gnu.org>, Werner LEMBERG > writes >>Indeed, I just see that @frenchspacing is only used for French and >>Japanese (the latter only partially). It should be activated for all >>languages except, perhaps, English. Note that I don't care what you >>native speakers actually decide for English :-) > > As a native English speaker (that's English, not American), I'd say > that two spaces are wrong, too. @nonfrenchspacing does _not_, I repeat _not_, cause a larger space to appear by _default_ at sentence endings. However, when TeX does line justification, it will (if necessary) stretch the space after sentence endings more than the interword space when @nonfrenchspacing is being used. So it distributes justification space, a sometimes necessary ugliness, differently when using @nonfrenchspacing. Since the interword space tears the flow of reading apart worse than the intersentence space, I consider that a sensible idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/25 Werner LEMBERG : > I don't object to add it to the font, so please add it as a feature > request. Given that the shape is basically only a rectangle, this should be easy to do. I've got a patch more or less ready but there are a couple of small questions: - What is a good name for the new articulation? - What should be the precise shape (width/height ratio)? Currently I use height = 1 staff_space and width = 1/5 staff_space (see attached sample). Opinions? - Should the corners of the rectangle be sharp (as in the sample file) or rounded; if the latter, by which amount? Thanks, Max line-articulation.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
John's getting a PhD! (was: something about building stuff)
On Sat, Jul 25, 2009 at 09:25:01PM +0200, John Mandereau wrote: > I strive to update the CG and maintenance scripts and push this > on Monday; now I know I've been awarded a PhD grant at math > department of Pisa University (Italy), Congratulations! There seems to be a strong correlation between working on lilypond and getting PhDs. Are you starting in Sep 2009? If so, we'll have to race to see who finishes first. ;) > I'm going to spend for LilyPond the time I may probably no > longer have for three years, not counting the delay of all what > I have already promised to do for months :-P In this case, updating the CG (eventually -- once all the build stuff and translation infrastructure is finished) is even more important. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sat, Jul 25, 2009 at 08:20:45AM -0400, Kieren MacMillan wrote: > Hi Werner (et al,), > >> Please use two spaces after a full stop in documentation strings for >> consistence. > > Since this is incorrect typographical practice, and Lilypond prides > itself on beautiful typography, I'm surprised this is the standard in > the docs — why/how was this decision made? I made the decision, since it's my father's religious preference and I follow his grammatical, typographical, and spelling rules unless presented with overwhelming evidence to the contrary[1]. I therefore offer to engage you with a robust round of fisticuffs in order to settle the matter. :) [1] the only thing that comes to mind at the moment is using the American "z" in words rather than the British "s". I just think that "-ize" looks cooler than "-ise". I could ask him for references tomorrow if you want. Cheers, - Graham PS this debate includes a built-in compromise: since I mostly look at the docs in texinfo form, I don't notice the atrocities that HTML performs on my carefully-crafted double-spaced periods. So if we continue with the status quo (double-space in the texinfo), you single-space heathens can get the spacing you want while reading the docs, while I get the spacing I want while reviewing the doc source. PPS like most religious beliefs, I can't understand why on earth anybody would propose single-spaced sentences. They look so ugly! "Hey guys! Let's deliberately write stuff. Stuff that is ugly. And harder to read. And all-round badder." ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sat, Jul 25, 2009 at 07:28:33PM +0100, Anthony W. Youngman wrote: > In message <20090725.163011.184567355...@gnu.org>, Werner LEMBERG > writes >> Indeed, I just see that @frenchspacing is only used for French and >> Japanese (the latter only partially). It should be activated for all >> languages except, perhaps, English. Note that I don't care what you >> native speakers actually decide for English :-) > > As a native English speaker (that's English, not American), I'd say that > two spaces are wrong, too. Oh, in case anybody was wondering: my father is pure native British, educated at Oxford, and considers the 1978 Fowler's Modern English second revised edition (printed in Oxford) to be the definitive guide to English writing. There's no American influence here! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ppppp but no fffff
On Sat, Jul 25, 2009 at 10:31:35AM -0700, Mark Polesky wrote: > > Although, it just struck me, what does MIDI do when it gets a > dynamic it doesn't recognize? Maybe it's written somewhere; I > haven't checked. MIDI doesn't get "dynamics" in terms of mffpf. Rather, note events have a include "velocity" number from 0-127. Interestingly, both noteOn and noteOff events have this velocity figure, although very few programs/hardware do anything with the velocity of a noteOff message. (and actually, many programs just use noteOn with a velocity of 0 instead of an actual noteOff message!) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Graham, I could ask him for references tomorrow if you want. Like most religious beliefs, your father's bible (whatever reference it may be) will never convince me that my bible (Robert Bringhurst's "The Elements of Typographic Style") is anything except mao's own truth. =) PPS like most religious beliefs, I can't understand why on earth anybody would propose single-spaced sentences. They look so ugly! "Hey guys! Let's deliberately write stuff. Stuff that is ugly. And harder to read. And all-round badder." Exactly! Except in reverse, of course. ;) Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Graham, Oh, in case anybody was wondering: my father is pure native British, educated at Oxford, and considers the 1978 Fowler's Modern English second revised edition (printed in Oxford) to be the definitive guide to English writing. There's no American influence here! So what does Fowler's (both 1978 and the most recent edition) say about the matter? I don't have access to it directly... but the document at www.brand.uottawa.ca/documents/style-guide.pdf>, which lists Fowler's in the bibliography, calls [sensibly] for single-spaced sentences. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Hi David, @nonfrenchspacing does _not_, I repeat _not_, cause a larger space to appear by _default_ at sentence endings. However, when TeX does line justification, it will (if necessary) stretch the space after sentence endings more than the interword space when @nonfrenchspacing is being used. Interesting... this seems to conflict with the TeX references I read earlier (in particular, Knuth's original intention on the matter). Where did you get this information/specification? Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to view console on Windows?
Mark Polesky wrote: Jonathan Kulp wrote: You can run it from the dos cmd prompt. Just do "lilypond foobar.ly" and it should work. Yes it does... thank you, that helps. But shouldn't the output be sent to the log file? I wish it were. Does anyone know how to do that? Thanks. - Mark $ lilypond -dgui ? By the way, you can get a terminal screen up by using the key combination Flag + R and typing cmd into the dialogue box. Cheers Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
At 02:27 on 26 Jul 2009, Graham Percival wrote: > [1] the only thing that comes to mind at the moment is using the > American "z" in words rather than the British "s". I just think > that "-ize" looks cooler than "-ise". Um, that's not actually American... http://en.wikipedia.org/wiki/Oxford_spelling -- Mark Knoop ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Does \hspace need a vertical extent?
Given the following input, the height of the brackets does not match
the height of the enclosed text.
\version "2.13.2"
\markup {
\bracket {
\concat {
\hspace #1
FOO
\hspace #1
}
}
}
This is because \hspace has a vertical extent. I'm assuming that
this vertical extent is unnecessary; if so, the problem can be solved
by this trivial patch:
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index 8c057c6..c2eb778 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -398,8 +398,8 @@ Create an invisible object taking up horizontal space
@var{amount}.
}
@end lilypond"
(if (> amount 0)
- (ly:make-stencil "" (cons 0 amount) '(-1 . 1))
- (ly:make-stencil "" (cons amount amount) '(-1 . 1
+ (ly:make-stencil "" (cons 0 amount) '(0 . 0))
+ (ly:make-stencil "" (cons amount amount) '(0 . 0
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Joe Neeman writes:
> On Fri, 2009-07-10 at 17:09 +0200, Reinhold Kainhofer wrote:
>> Am Montag, 22. Juni 2009 15:31:14 schrieb Joe Neeman:
>> > A quick update on the new vertical spacing: [...]
>> > Anything I've missed?
>>
>> While the new vertical spacing looks great for full scores (one system per
>> page), I have now run into a case where the old system worked much better.
>> In
>> particular, the spacing between the systems is too small with the new
>> system,
>> while in the old system it was easy to see where the systems end and new
>> systems begin. (On the positive side: The piano staff looks much better with
>> the new system).
>
> Fixed now. Also, we use the whole page now instead of leaving those gaps
> at the top and the bottom.
I've noticed a couple of problems with the default system spacing. If I
were to compile this file:
-8<--
\version "2.13.4"
\score{
\repeat unfold 150 {a' b' c' d' }
\layout{
ragged-bottom = ##t
}
}
-8<--
I end up with three pages. The final page, which consists of only three
systems, is spaced naturally and comfortably. The other pages, however,
have eight systems which are spaced very far apart. I imagine the three
systems on the final page could easily have been squeezed on to them.
I've also run into a similar problem that I don't appear to be able to
replicate minimally. A score I am working on should fit on to one page,
but unexpectedly page breaks about half way through so that the first
page has six systems and the second four. The systems are spaced
naturally, but there is a huge amount of space atthe bottom of each
page.
If you want me to send the file off list, Joe, let me know (I won't post
it here due to copyright issues).
BTW, what is the best place to report bugs with the new code? I'm
assuming that -bug is for mainstream code and problems with experimental
versions should be discussed here.
--
Cameron Horsburgh
Blog: http://spiritcry.wordpress.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Hi David, Well, the TeX book says: Excellent reference — thanks! so there _is_ extra natural space for a space factor of 2000 and larger. Perhaps the best compromise, then, would be to set the space factor at 1999 — that way, the single-spacers (a.k.a. star-bellied Sneeches) would be somewhat satisfied because the extra natural space would not come into play, and the double-spacers (a.k.a. non-star-bellied Sneeches) would be somewhat satisfied because the space factor is larger than normal word space (via justification stretch)? Cheers, Kieren. p.s. Thanks for the fun and fascinating discussion: I'm learning a bunch about TeX that I never knew before! ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Kieren MacMillan writes:
> Hi David,
>
>> @nonfrenchspacing does _not_, I repeat _not_, cause a larger space to
>> appear by _default_ at sentence endings. However, when TeX does line
>> justification, it will (if necessary) stretch the space after sentence
>> endings more than the interword space when @nonfrenchspacing is being
>> used.
>
> Interesting... this seems to conflict with the TeX references I read
> earlier (in particular, Knuth's original intention on the matter).
Huh? What makes you think that? Period spacing is done by manipulating
\spacefactor, and that only affects stretchability, not natural spacing.
> Where did you get this information/specification?
Well, the TeX book says:
When \TeX\ is processing a horizontal list of boxes and glue, it
keeps track of a positive integer called the current ``^{space
factor}.'' The space factor is normally 1000, which means that the
interword glue should not be modified. If the space factor $f$ is
different from 1000, the interword glue is computed as follows: Take
the normal space glue for the current font, and add the extra space
if $f\ge2000$. \ (Each font specifies a normal space, normal
stretch, normal shrink, and extra space; for example, these
quantities are $3.3\pt$, $1.6\pt$, $1.1\pt$, and
$1.1\pt$, respectively, in ^|cmr10|. We'll discuss such font
parameters in greater detail later.) \ ^^|\fontdimen| Then the
stretch component is multiplied by $f/1000$, while the shrink
component is multiplied by $1000/f$.
\ddanger However, \TeX\ has two parameters ^|\spaceskip| and
^|\xspaceskip| that allow you to override the normal spacing of the
current font. If $f\ge2000$ and if\/ |\xspaceskip| is nonzero, the
|\xspaceskip| glue is used for an ^{interword space}. Otherwise if\/
|\spaceskip| is nonzero, the |\spaceskip| glue is used, with stretch
and shrink components multiplied by $f/1000$ and $1000/f$. For
example, the ^|\raggedright| macro of plain \TeX\ uses |\spaceskip|
and |\xspaceskip| to suppress all stretching and shrinking of
interword spaces.
Well, so there _is_ extra natural space for a space factor of 2000 and
larger. With nonfrenchspacing, the space factor for a period and
several other punctuation characters is 3000, so the extra space comes
into play.
I stand somewhat corrected.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
On 7/26/09 1:33 AM, "Maximilian Albert" wrote: > 2009/7/25 Werner LEMBERG : > >> I don't object to add it to the font, so please add it as a feature >> request. I think that Werner was saying the feature request is to add a glyph to the font. But while we wait for that to happen, to add a drawn rectangle is a definite benefit. > > Given that the shape is basically only a rectangle, this should be > easy to do. I've got a patch more or less ready but there are a couple > of small questions: > > - What is a good name for the new articulation? > - What should be the precise shape (width/height ratio)? Currently I > use height = 1 staff_space and width = 1/5 staff_space (see attached > sample). Opinions? > - Should the corners of the rectangle be sharp (as in the sample file) > or rounded; if the latter, by which amount? The corners of the rectangle should *definitely* be rounded (all of LilyPond engraving is rounded). The standard radius is half of line-thickness. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request (\cueNotes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 25. Juli 2009 11:51:23 schrieb Werner: > I really would be glad, if there was a possibility to make notes (including > heads, stems, beams, flags, slurs, clefs, accidentals, ...) smaller. > > Unfortunately the \small, \tiny, \set fontSize commands don't affect all > parts of notes (beams, ... are not affected). > > Something like > \cueNotes or just \cue with How about using \new CueVoice? 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKbG/sTqjEwhXvPN0RAgY6AKCVbtE7tbIvGXDgZNmX2lnL6wXJAQCfdx7c +w3lD31oD8/1DOYciAo4TE4= =fOye -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Weird make error
Hi Carl, Le samedi 25 juillet 2009 à 18:14 -0600, Carl Sorensen a écrit : > make runs through the creation of the .o and the executable. It finishes > the fonts, then when it starts compiling the snippets it ends with: This log is cumbersome to read, because "make" doesn't print "entering/leaving directory foo/bar/baz" lines. Which version and which binary of make have you installed? > make PACKAGE=LILYPOND package=lilypond -C J.S.Bach all && make > PACKAGE=LILYPOND package=lilypond -C F.Schubert all && make > PACKAGE=LILYPOND package=lilypond -C E.Satie all && make PACKAGE=LILYPOND > package=lilypond -C W.A.Mozart all && make PACKAGE=LILYPOND > package=lilypond -C R.Schumann all && true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > mkdir -p ./out > touch ./out/dummy.dep > echo '*' > ./out/.gitignore > true > make[2]: *** No rule to make target `all'. Stop. > make[1]: *** [all] Error 2 > make: *** [all] Error 2 This log doesn't tell me which directory has failed, so I can't do much to fix this. I'm hopefully pushing cleanup in mutopia stepmake template along with other changes in half an hour if my working tree builds and installs well. > How can I track this down? Try to find the directory where it fails, and/or try to cleanly rebuild when I have pushed my changes. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/26 Carl Sorensen : > I think that Werner was saying the feature request is to add a glyph to the > font. But while we wait for that to happen, to add a drawn rectangle is a > definite benefit. I was talking about adding a glyph to the font, too. But the glyph is basically just a rectangle, and there already exists a function for drawing these (to wit, draw_rounded_block() in feta-macros.mf), so it's not a big deal. It's just a question of fiddling with the parameters and finding a nice name for the glyph. Hence my questions. > The corners of the rectangle should *definitely* be rounded (all of LilyPond > engraving is rounded). The standard radius is half of line-thickness. OK, thanks. Any suggestions for a name? I can't think of a good one which concisely captures the glyph's meaning (mainly because I don't know what that meaning is :-P). Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How can I use git to help me merge a patch with the new directory structure
Hi, On Sat, 25 Jul 2009, Carl Sorensen wrote: > As you're aware, I've been working on a patch for autobeaming. > > It affects c++, scheme, and documentation files. > > Now I want to apply the patch to master. But the problem is that all of > the documentation files have moved to Documentation/ISOLANG/notation > instead of Documentation/ISOLANG/user > > So this seems to break any means of making my patch apply. > > Any git gurus out there who have an idea of how I can do this without > having to manually apply patches made between the files in the different > directories? You should be ablt to use "git cherry-pick " on the branch you want to port this commit to. This will perform a rename-aware 3-way merge. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How can I use git to help me merge a patch with the new directory structure
Le samedi 25 juillet 2009 à 22:37 -0600, Carl Sorensen a écrit : > Any git gurus out there who have an idea of how I can do this without having > to manually apply patches made between the files in the different > directories? If marvellous renames detection capacity of Git enabled by default when merging doesn't work for you (maybe you have to specify it manually when you rebase, if this option ever exists in rebase, see the man pages), make a patch file or your commit, or backup your patch file if you don't have it in your Git repo, then try sed -i -e '#/user#/notation#g' your_patch_file This manual way with sed would probably be the only reasonable option with a VCS like CVS. > Any help would be appreciated; right now I feel like all of my work on > autobeaming is in shambles and I'm going to have to do it all over again. Don't worry, all your fantastic work on autobeaming certainly needn't be redone just for a few doc files moved :-) Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: John's getting a PhD! (was: something about building stuff)
Le dimanche 26 juillet 2009 à 02:02 -0700, Graham Percival a écrit : > Congratulations! There seems to be a strong correlation between > working on lilypond and getting PhDs. Maybe, but in my case it looks more like a coincidence between my translations meister role in LilyPond and studies, even if one of my supervisors Carlos Agon often says he and other people at the IRCAM love LilyPond. > Are you starting in Sep > 2009? If so, we'll have to race to see who finishes first. ;) Ha! I don't know when I start, actually :-P I'm only sure I start not later than January 2010. > In this case, updating the CG (eventually -- once all the build > stuff and translation infrastructure is finished) is even more > important. Oh, please don't tell me that, except if you don't mind I update the CG in one year. Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sun, 2009-07-26 at 21:46 +1000, Cameron Horsburgh wrote:
> Joe Neeman writes:
>
> > On Fri, 2009-07-10 at 17:09 +0200, Reinhold Kainhofer wrote:
> >> Am Montag, 22. Juni 2009 15:31:14 schrieb Joe Neeman:
> >> > A quick update on the new vertical spacing: [...]
> >> > Anything I've missed?
> >>
> >> While the new vertical spacing looks great for full scores (one system per
> >> page), I have now run into a case where the old system worked much better.
> >> In
> >> particular, the spacing between the systems is too small with the new
> >> system,
> >> while in the old system it was easy to see where the systems end and new
> >> systems begin. (On the positive side: The piano staff looks much better
> >> with
> >> the new system).
> >
> > Fixed now. Also, we use the whole page now instead of leaving those gaps
> > at the top and the bottom.
>
> I've noticed a couple of problems with the default system spacing. If I
> were to compile this file:
>
> -8<--
>
> \version "2.13.4"
>
> \score{
> \repeat unfold 150 {a' b' c' d' }
> \layout{
> ragged-bottom = ##t
> }
> }
>
> -8<--
>
> I end up with three pages. The final page, which consists of only three
> systems, is spaced naturally and comfortably. The other pages, however,
> have eight systems which are spaced very far apart. I imagine the three
> systems on the final page could easily have been squeezed on to them.
>
> I've also run into a similar problem that I don't appear to be able to
> replicate minimally. A score I am working on should fit on to one page,
> but unexpectedly page breaks about half way through so that the first
> page has six systems and the second four. The systems are spaced
> naturally, but there is a huge amount of space atthe bottom of each
> page.
>
> If you want me to send the file off list, Joe, let me know (I won't post
> it here due to copyright issues).
Please do send me the files. But first, check to see if they give the
same behaviour with current git. I pushed some changes yesterday that
may have helped.
>
> BTW, what is the best place to report bugs with the new code? I'm
> assuming that -bug is for mainstream code and problems with experimental
> versions should be discussed here.
I think this thread is a good place.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contrib Guide not built
Le samedi 25 juillet 2009 à 19:25 -0700, Patrick McCarty a écrit : > I can confirm. The entire "split" version of the CG is not being built > either. I have not checked this before cleaning up Documentation/GNUmakefile today, but the link to the split HTML CG from devel.html was wrong. This should be fixed in Git. > The same thing appears to be happening with changes.tely (the former > NEWS.tely): the big page and translated big pages are generated, but > not the split version. Huh, have we ever had a splitted HTML NEWS document? Thanks to you and Jonathan for the report, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
Maximilian Albert wrote: > OK, thanks. Any suggestions for a name? I can't think of a good one > which concisely captures the glyph's meaning (mainly because I don't > know what that meaning is :-P). Michael Käppler, in his original post for this thread suggested that it implies some extra "weight" given to the note, but I'd like to find some documented description of this in the primary literature (baroque treatises, etc.) before committing to something. http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00567.html In the classic 1752 treatise "Essay of a Method for Playing the Transverse Flute" by Johann Joachim Quantz, Chapter 27, Section 2, Subsection 27, it says this: If the word "staccato" appears in a piece, all the notes must be played with a short and detached bow. Since, however, an entire piece is at present rarely composed in a single species of notes, and we take care to indicate a good mixture of different types, little strokes are written above notes which require the staccato. This is taken from the English translation; I don't know if something was lost in translating the German word for "strokes". If anyone happens to have access to the original German version, I'd be curious to hear how it reads. Also, the Oxford Companion to Music has this in the entry for "staccato": ...marked in notation in different ways: with a dot (the most common method), a vertical stroke, a small wedge, or a horizontal line (implying an accent). Can anyone find any other references to this? I find no mention of it in the notation manuals by Gardner Read and Kurt Stone. Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs and new web site reorganization steps
Le samedi 25 juillet 2009 à 13:05 -0700, Patrick McCarty a écrit : > However, I just tried `make install' after `make all', and I get the > attached output. Thanks for the report, fixed in Git. Gee, this made me realize OMF stuff had been broken since 'out-www' was stripped from the docball (i.e. for years). Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs and new web site reorganization steps
Hi John, I've just tried to invoke makelsr.py to update a snippet in one of my Rietveld patchsets, and I'm getting the following error message: Traceback (most recent call last): File "scripts/auxiliar/makelsr.py", line 8, in os.environ['PYTHONPATH'] += ':python' File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__ raise KeyError(key) KeyError: 'PYTHONPATH' Should I have a PYTHONPATH environment variable set? Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Hi Joe, 2009/7/26 Joe Neeman : > Please do send me the files. But first, check to see if they give the > same behaviour with current git. I pushed some changes yesterday that > may have helped. Have you carried these changes over from dev/jneeman? The reason I ask is that I'm now getting the same assertion failure on a particular file (using --disable-optimising) with both branches: lilypond: simple-spacer.cc:234: Real Simple_spacer::compress_line(): Assertion `fabs (configuration_length (cur_force) - cur_len) < 1e-6' failed. I can send you the file if you'd like to take a look at it. I've tested a few examples of piano music, and apart from the spacing between staves being very tight, I'm encountering some strange issues associated with cross-staff beaming; sometimes they force the staves apart, other times (mainly associated with existing cross-staff beaming bugs) they trigger a collision with the next system. When I set fixed distances using alignment-distances, I find that systems with three staves sometimes break the page breaking algorithm: systems spill off the bottom of the page, when it would be much better to move one on to the next page. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory structure for docs and web site
Le mercredi 22 juillet 2009 à 21:46 -0700, Graham Percival a écrit : > I disagree; @lilypond blocks have a few problems for this case: > - this is a really "courageous" regression test. Ok, ideally we'd > never merge any patches that break any regtests, but it happens > from time to time -- especially since IMO nobody is actually > checking the regtest comparisons. > (yes, getting this started again is a priority in GOP) > It's one thing to have some bugs show up in the manual; it's > another thing to have a bug resulting in ugly examples on the > Introduction page! I think putting more responsability for releases, which is not such a bad thing IMHO. Hey, this would probably mean the web site should be build in stable branch, which fits the need to make links from the web site to *stable* docs by default. > - requires lilypond (could be problems for a distinct web repo) But this won't be in a distinct repo, and you designed lilypond-general Texinfo document so it would be difficult to do anything else :-) > - we DO NOT want to show the input code. Why not? > - we want to show an expanded image upon click (possibly via > javascript). This feature needn't Javascript. > All in all, we'd need to check the output all the time, write a > special rule for @lilypond when running texi2html on the website > (actually, I guess this would need to be a special-case option for > lilypond-book), etc etc. And for what benefit? So that we can > avoid adding 704 Kb to the git tracker? This will make 704 Kb evey time the examples are updated. If you compare this with current master branch history weight (a bit less than 60 Mb), that can potentially bloat up the history. I prefer to hack lilypond-book. > I agree that generated files shouldn't be added to source > repositories as a general rule, but I really think that this is a > special case that merits an exemption. We'd (and by "we", I mean > "you" ;P) need to add little quirks to so many portions of the > build system, not to mention the ongoing risk or ongoing "check > the output on Examples" task. I'm still questioning this. I don't and I can't put my veto on this, but I might refuse to do it myself without stronger justifications. > Hmm... ok. I'm slightly concerned about the downloadable tarball > (it might be nice to offer downloadable HTML and pdf tarballs). Unlike the web site, this will work out of the box. > For those tarballs, we'd want to generate HTML files that point to > HTML files within the tarball, whereas in the for-upload html > files, we'd want to point lilypond-general links at ../../ > > I have no suggestions about how to do this in a nice way, but as > long as you're aware of the issue, I'm sure that you can find a > nicer solution than mine, anyway. :) Oh, I'm almost sure that it will be ugly, whoever does it: this will likely be a hack in postprocess_html.py:hack_urls() or the like :-P I hope we're done for now with brain surgery on docs, so as far as I'm concerned I declare the docs in a releasable state again, modulo a few buglets that may remain (broken HTML links, missing manuals in splitted HTML :-). The next things I plan for the docs infrastructure : translating node names directly in docs, split out the essay and add lilypond-general, make docs maintenance scripts use a real Texinfo parser and optimize makefiles -- in this order, maybe the two last items in parallel. Speaking of lilypond-general (it will be the info document name), are you OK with naming it general.texi? This will avoid adding yet another ad-hoc makefile hack. This will produce general/index.html and general-big-page.html in the docball, and this name won't appear for the online web site of course. Until it's ready to replace the old web site (this means in particular: at least translated in the languages which have active translators by the end of August), I propose not to add links to lilypond-general from Documentation/index.html nor from anywhere, so people who are aware of its existence will be able to see the output on kainhofer.com or in the released docball without having to build it themselves. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs and new web site reorganization steps
Le dimanche 26 juillet 2009 à 19:50 +0100, Neil Puttock a écrit : > I've just tried to invoke makelsr.py to update a snippet in one of my > Rietveld patchsets, and I'm getting the following error message: > os.environ['PYTHONPATH'] += ':python' > KeyError: 'PYTHONPATH' > > Should I have a PYTHONPATH environment variable set? Oops. I was concerned by a possible leading colon in this case anyways. Fixed in Git. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request (\cueNotes)
Reinhold Kainhofer kainhofer.com> writes:
> How about using \new CueVoice?
Thanks for the hint!
It indeed seems to be nearly what I'm looking for.
(But I miss an easy example in the docs - it is so complicated there! So I even
didn't find nor understand it. They explain there more cueDuring then cueVoice
and everything quite sophisticated.)
But in the following example unfortunately the CueVoice, which should be a
second voice with stems down, behaves like a OneVoice (stems up and down).
{es?4 es' << {es'4 d8 d~ | d4 f cis8 a f es | d4 c' c h8 b~ | b1 | } \\ \new
CueVoice { es,4 d8 d~ | d4 f cis8 a f es | d4 c' c h8 b~ | b1 | } >> r4 r8 b'
a4. g8 }
So I have to add \stemDown and \stemNeutral.
Greetings
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs and new web site reorganization steps
2009/7/26 John Mandereau : > Oops. I was concerned by a possible leading colon in this case anyways. > Fixed in Git. Lovely, thank you. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sun, 2009-07-26 at 20:02 +0100, Neil Puttock wrote: > Hi Joe, > > 2009/7/26 Joe Neeman : > > > Please do send me the files. But first, check to see if they give the > > same behaviour with current git. I pushed some changes yesterday that > > may have helped. > > Have you carried these changes over from dev/jneeman? No, the changes I recently committed to master were a few small things that I thought were safe. > The reason I > ask is that I'm now getting the same assertion failure on a particular > file (using --disable-optimising) with both branches: > > lilypond: simple-spacer.cc:234: Real Simple_spacer::compress_line(): > Assertion `fabs (configuration_length (cur_force) - cur_len) < 1e-6' > failed. > > I can send you the file if you'd like to take a look at it. Please. > > I've tested a few examples of piano music, and apart from the spacing > between staves being very tight, I'm encountering some strange issues > associated with cross-staff beaming; sometimes they force the staves > apart, other times (mainly associated with existing cross-staff > beaming bugs) they trigger a collision with the next system. Could you please send me some examples? > > When I set fixed distances using alignment-distances, I find that > systems with three staves sometimes break the page breaking algorithm: > systems spill off the bottom of the page, when it would be much better > to move one on to the next page. This must be because I'm not using alignment-distances in the page-breaking stage, but only in the layout stage; I know how to fix this one. Thanks, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On 26 Jul 2009, at 13:41, Joe Neeman wrote: Please do send me the files. But first, check to see if they give the same behaviour with current git. I pushed some changes yesterday that may have helped. I have a book of 243 scores that could use better vertical spacing. Are there development builds for download anywhere? (I would need OS X 10.5 Intel. Command line only is fine.) All I see in the official download site is releases (e.g. 2.13.3-0). In case you are interested in trying it yourself, I've put the source at http://faithful.be/sheet-music/books.tar.bz2 . "make ZH PARTS=violin" should build out/ZH/pdf/violin.pdf. If you're not interested, I'll just wait until the change makes its way into a release. (It's not that I'm afraid of building Lilypond, it's just that spending three days installing the prerequisites is currently low on my list of priorities.) Regards, -- Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
Hello Joe (et al.), Are there development builds for download anywhere? +1 [OS X 10.4 Intel] (It's not that I'm afraid of building Lilypond, it's just that spending three days installing the prerequisites is currently low on my list of priorities.) I've spent about two days trying, and I'm still running into problems which I don't have the time or savvy to decode right now... =\ I'd love to give Joe's spacing algos a whirl immediately, but if I have to wait for the next release so be it. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contrib Guide not built
2009/7/26 John Mandereau : > Le samedi 25 juillet 2009 à 19:25 -0700, Patrick McCarty a écrit : >> I can confirm. The entire "split" version of the CG is not being built >> either. > > I have not checked this before cleaning up Documentation/GNUmakefile > today, but the link to the split HTML CG from devel.html was wrong. This > should be fixed in Git. Thanks. >> The same thing appears to be happening with changes.tely (the former >> NEWS.tely): the big page and translated big pages are generated, but >> not the split version. > > Huh, have we ever had a splitted HTML NEWS document? No, I don't know why I said that. :-) When you get a chance, could you also try "make dist" again? It looks like there are some more makefiles that need adjustments for the NEWS.tely --> changes.tely transition. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
how is NR F. "LilyPond command index" generated?
How is NR F. "LilyPond command index" generated? I see this on line 215 of Documentation/notation.tely, but I don't understand how it works: @printindex ky Can someone explain? Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New markup command `parenthesize'
Here is a patch which defines `parenthesize', a new markup command
which works like `bracket'. It's mainly useful for parenthesizing
columns containing several lines of text.
Please let me know about anything you see that could be done better!
commit c46fa73ed53ccc6f550e549fdec20df7003c3582
Author: Thomas Morgan
Date: Mon Jul 6 16:08:06 2009 +0200
New markup command `parenthesize' in `scm/define-markup-commands.scm'.
This works like the `bracket' markup command but makes parentheses
instead of brackets.
New procedures `parenthesize-stencil' and `make-parenthesis-stencil'
in `scm/stencil.scm'.
In `scm/define-grob-properties.scm', define property `angularity'
that controls the shape of parentheses. Add this property
to TextScript grob definition in `scm/define-grobs.scm' and
to text script interface in `lily/script-interface.cc'.
Thanks to Carl Sorensen for great advice and criticism.
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index 59737b5..6bdd069 100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -112,6 +112,7 @@ ADD_INTERFACE (Text_script,
/* properties */
"add-stem-support "
+ "angularity "
"avoid-slur "
"script-priority "
"slur "
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index 0c65d45..7155b2c 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -38,6 +38,8 @@ be created below this bar line.")
(alteration ,number? "Alteration numbers for accidental.")
(alteration-alist ,list? "List of @code{(@var{pitch}
. @var{accidental})} pairs for key signature.")
+ (angularity ,number? "Angularity of grob shape.
+Typical values range from 0 (not angular) to 1 (angular).")
(annotation ,string? "Annotate a grob for debug purposes.")
(arpeggio-direction ,ly:dir? "If set, put an arrow on the
arpeggio squiggly line.")
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index e511f24..f829a33 100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -1889,6 +1889,7 @@
(slur-padding . 0.5)
(script-priority . 200)
(cross-staff . ,ly:script-interface::calc-cross-staff)
+ (angularity . 0)
;; todo: add X self alignment?
(meta . ((class . Item)
(interfaces . (text-script-interface
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index e953774..17a24a6 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -3021,6 +3021,38 @@ Draw vertical brackets around @var{arg}.
(let ((th 0.1) ;; todo: take from GROB.
(m (interpret-markup layout props arg)))
(bracketify-stencil m Y th (* 2.5 th) th)))
+
+(define-builtin-markup-command (parenthesize layout props arg)
+ (markup?)
+ graphic
+ ()
+ "
+...@cindex placing parentheses around text
+
+Draw parentheses around @var{arg}. This is useful for parenthesizing
+a column containing several lines of text.
+
+...@lilypond[verbatim,quote]
+\\markup {
+ \\parenthesize {
+\\column {
+ foo
+ bar
+}
+ }
+}
+...@end lilypond"
+ (let* ((markup (interpret-markup layout props arg))
+(size (chain-assoc-get 'size props 1))
+(width (* size (chain-assoc-get 'width props 0.25)))
+(thickness (* (chain-assoc-get 'line-thickness props 0.1)
+ (chain-assoc-get 'thickness props 1)))
+(half-thickness (min (* size 0.5 thickness)
+ (* (/ 4 3.0) width)))
+(angularity (chain-assoc-get 'angularity props 0))
+(padding (chain-assoc-get 'padding props half-thickness)))
+(parenthesize-stencil
+ markup half-thickness width angularity padding)))
;; Delayed markup evaluation
diff --git a/scm/stencil.scm b/scm/stencil.scm
index fcf5434..5b83631 100644
--- a/scm/stencil.scm
+++ b/scm/stencil.scm
@@ -70,6 +70,84 @@
(ly:stencil-combine-at-edge lb (other-axis axis) 1 stil padding))
stil))
+(define (make-parenthesis-stencil
+y-extent half-thickness width angularity)
+ "Create a parenthesis stencil.
+...@var{y-extent} is the Y extent of the markup inside the parenthesis.
+...@var{half-thickness} is the half thickness of the parenthesis.
+...@var{width} is the width of a parenthesis.
+The higher the value of number @var{angularity},
+the more angular the shape of the parenthesis."
+ (let* ((line-width 0.1)
+;; Horizontal position of baseline that end points run through.
+(base-x
+ (if (< width 0)
+ (- width)
+ 0))
+;; Farthest X value (in relation to baseline)
+;; on the outside of the curve.
+(outer-x (+ base-x width))
+(x-extent (ordered-cons base-x outer-x))
+(bottom-y (interval-start y
Re: New markup command `parenthesize'
Thomas Morgan wrote: > Here is a patch which defines `parenthesize', a new markup command > which works like `bracket'. It's mainly useful for parenthesizing > columns containing several lines of text. > > Please let me know about anything you see that could be done better! There already is a command named parenthesize defined on line 604 of ly/music-functions-init.ly. I think you need to rename it to avoid conflicts. Perhaps "parenthesize-markup"? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sun, Jul 26, 2009 at 04:24:03PM -0400, Kieren MacMillan wrote: > Hello Joe (et al.), > >> (It's not that I'm afraid of building Lilypond, it's just that >> spending three days >> installing the prerequisites is currently low on my list of >> priorities.) > > I've spent about two days trying, and I'm still running into problems > which I don't have the time or savvy to decode right now... =\ > I'd love to give Joe's spacing algos a whirl immediately, but if I have > to wait for the next release so be it. Given that we know it's an improvement, and it's being done by a very reliable developer, I'm perfectly happy having this merged in now. Including it in GUB 2.13 binaries is the only way to reach widespread testing, after all. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup command `parenthesize'
There are many other commands that have the same name in markup and normal context. Mark Polesky írta: Thomas Morgan wrote: Here is a patch which defines `parenthesize', a new markup command which works like `bracket'. It's mainly useful for parenthesizing columns containing several lines of text. Please let me know about anything you see that could be done better! There already is a command named parenthesize defined on line 604 of ly/music-functions-init.ly. I think you need to rename it to avoid conflicts. Perhaps "parenthesize-markup"? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how is NR F. "LilyPond command index" generated?
On Sun, Jul 26, 2009 at 02:42:17PM -0700, Mark Polesky wrote: > > How is NR F. "LilyPond command index" generated? > > I see this on line 215 of Documentation/notation.tely, but I don't > understand how it works: > > @printindex ky > > Can someone explain? It's done with texinfo's index generation. All @funindex foo entries are collected and genereated into the index. Internally, our @funindex macro is expanded to @findex and @kindex. If you're wondering because you want to improve the readibility of the index, that would require patches to texinfo/makeinfo and texi2html. :( We've had a few requests for this, but it's outside our control. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
In message <20090726092704.ga3...@nagi>, Graham Percival writes [1] the only thing that comes to mind at the moment is using the American "z" in words rather than the British "s". I just think that "-ize" looks cooler than "-ise". Actually, "s" is FRENCH, not English :-) Bearing in mind The Times is one of the oldest English newspapers, I gather someone did a study of old editions, and it used zed (not zee!) when zed was the norm long long ago. And it CONTINUED using zed right up to the 1970s, when it finally gave into public pressure and adopted the French ess, some 100 or 150 years after most of the rest of the publishing industry. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how is NR F. "LilyPond command index" generated?
Graham Percival wrote: > It's done with texinfo's index generation. All > @funindex foo > entries are collected and genereated into the index. Internally, > our @funindex macro is expanded to @findex and @kindex. > > If you're wondering because you want to improve the readibility of > the index, that would require patches to texinfo/makeinfo and > texi2html. :( We've had a few requests for this, but it's > outside our control. No, I'm wondering because I updated the syntax with a new command in a recent patch of mine: Add dynamic script f; update docs. http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=a905c95c63cffb9c551e599e0fa5bf1840bb737c Will the new \f command automagically appear in NR F? If not, I wonder how many other commands are defined but not @funindex'ed? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how is NR F. "LilyPond command index" generated?
On Sun, Jul 26, 2009 at 03:05:43PM -0700, Mark Polesky wrote: > > Graham Percival wrote: > > > It's done with texinfo's index generation. All > > @funindex foo > > entries are collected and genereated into the index. Internally, > > our @funindex macro is expanded to @findex and @kindex. > > No, I'm wondering because I updated the syntax with a new command > in a recent patch of mine: Ah, I see. No, of course it won't. The index is built purely from @funindex. Ralph Palmer is gradually indexing material, but of course he wouldn't notice this addition to Dynamics (he's finished that). I guess we should have rejected that patch of yours. :P Once John says it's safe to do doc work again, I'll add a checklist for doc modification. (if there's a new command, did you add a @funindex) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
To the NEWS: [Fwd: ANN: LilyPondTool 2.12.879 Plugin Central Release]
Wouldn't it be a good idea to post these announcement to the NEWS of the LilyPond homepage? The latest version of LilyPondTool has been released to the jEdit plugin repository. Now it supports Virtual Piano and MIDI input, and a dockable PDF viewer with advanced point-and-click support. To get it, in JEdit 4.3pre16 or later (www.jedit.org) go to Plugins > Plugin Manager and choose LilyPondTool from the Install tab. For more information check http://lilypondtool.organum.hu Thanks, Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how is NR F. "LilyPond command index" generated?
Graham Percival wrote: > > No, I'm wondering because I updated the syntax with a new > > command in a recent patch of mine: > > Ah, I see. No, of course it won't. The index is built purely > from @funindex. Ralph Palmer is gradually indexing material, > but of course he wouldn't notice this addition to Dynamics (he's > finished that). > > I guess we should have rejected that patch of yours. :P Well, now we know. I'm glad that I caught the issue now and not later. > Once John says it's safe to do doc work again, I'll add a > checklist for doc modification. (if there's a new command, > did you add a @funindex) Definitely put that on your TODO list or put a stub there or something. I wonder if there's a good way to find un-indexed commands that are floating in the source ether... - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sun, 2009-07-26 at 15:57 -0400, Dan Eble wrote: > On 26 Jul 2009, at 13:41, Joe Neeman wrote: > > > Please do send me the files. But first, check to see if they give the > > same behaviour with current git. I pushed some changes yesterday that > > may have helped. > > I have a book of 243 scores that could use better vertical spacing. > Are there development builds for download anywhere? (I would need OS > X 10.5 Intel. Command line only is fine.) All I see in the official > download site is releases (e.g. 2.13.3-0). No. I suppose I should learn how to build packages, but I think it's more productive right now if I try to finish this patch. > In case you are interested in trying it yourself, I've put the source at > http://faithful.be/sheet-music/books.tar.bz2 . > "make ZH PARTS=violin" should build out/ZH/pdf/violin.pdf. If you're > not interested, I'll just wait until the change makes its way into a > release. Thanks, I'll use this for testing. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Weird make error
On 7/26/09 9:51 AM, "John Mandereau" wrote: > Hi Carl, > Le samedi 25 juillet 2009 à 18:14 -0600, Carl Sorensen a écrit : >> make runs through the creation of the .o and the executable. It finishes >> the fonts, then when it starts compiling the snippets it ends with: > > This log is cumbersome to read, because "make" doesn't print > "entering/leaving directory foo/bar/baz" lines. Which version and which > binary of make have you installed? Oh, my mistake. I didn't give the log file, I gave the console output. I'll try again, and if I still have the problem, I'll use the log file not the console output. So even though you didn't directly answer my question, you really did. The answer is "look at the log file, not the console output". Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contrib Guide not built
On Sun, Jul 26, 2009 at 01:28:12PM -0700, Patrick McCarty wrote: > 2009/7/26 John Mandereau : > > Le samedi 25 juillet 2009 à 19:25 -0700, Patrick McCarty a écrit : > >> I can confirm. The entire "split" version of the CG is not being built > >> either. > > > > I have not checked this before cleaning up Documentation/GNUmakefile > > today, but the link to the split HTML CG from devel.html was wrong. This > > should be fixed in Git. > > Thanks. > > >> The same thing appears to be happening with changes.tely (the former > >> NEWS.tely): the big page and translated big pages are generated, but > >> not the split version. > > > > Huh, have we ever had a splitted HTML NEWS document? > > No, I don't know why I said that. :-) > > When you get a chance, could you also try "make dist" again? It looks > like there are some more makefiles that need adjustments for the > NEWS.tely --> changes.tely transition. Oops, I forgot to attach the log. Here it is. Thanks, Patrick rm -rf /home/pnorcks/git/lilypond/./out/lilypond-2.13.4 make --no-builtin-rules local-dist /home/pnorcks/git/lilypond/./out/lilypond-2.13.4 make[1]: Entering directory `/home/pnorcks/git/lilypond' make -C python make[2]: Entering directory `/home/pnorcks/git/lilypond/python' make PACKAGE=LILYPOND package=lilypond -C auxiliar all && true make[3]: Entering directory `/home/pnorcks/git/lilypond/python/auxiliar' true make[3]: Leaving directory `/home/pnorcks/git/lilypond/python/auxiliar' make[2]: Leaving directory `/home/pnorcks/git/lilypond/python' make -C Documentation/topdocs/ README_TOP_FILES="AUTHORS INSTALL README NEWS" txt-files make[2]: Entering directory `/home/pnorcks/git/lilypond/Documentation/topdocs' make[2]: *** No rule to make target `out/NEWS.txt', needed by `txt-files'. Stop. make[2]: Leaving directory `/home/pnorcks/git/lilypond/Documentation/topdocs' make[1]: *** [top-doc] Error 2 make[1]: Leaving directory `/home/pnorcks/git/lilypond' make: *** [dist] Error 2 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How can I use git to help me merge a patch with the new directory structure
On 7/26/09 11:35 AM, "Johannes Schindelin"
wrote:
> Hi,
>
> On Sat, 25 Jul 2009, Carl Sorensen wrote:
>
>> As you're aware, I've been working on a patch for autobeaming.
>>
>> It affects c++, scheme, and documentation files.
>>
>> Now I want to apply the patch to master. But the problem is that all of
>> the documentation files have moved to Documentation/ISOLANG/notation
>> instead of Documentation/ISOLANG/user
>>
>> So this seems to break any means of making my patch apply.
>>
>> Any git gurus out there who have an idea of how I can do this without
>> having to manually apply patches made between the files in the different
>> directories?
>
> You should be ablt to use "git cherry-pick " on the branch you
> want to port this commit to. This will perform a rename-aware 3-way
> merge.
I tried that, but I don't know how to make it work properly.
sorensen2:lilypond-working Carl$ git cherry-pick new-beam-settings
warning: too many files (created: 526 deleted: 717), skipping inexact rename
detection
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add ' or 'git rm ' and
commit the result.
When commiting, use the option '-c bd43152' to retain authorship and
message.
So far, so good, I think.
sorensen2:lilypond-working Carl$ git mergetool
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge
vimdiff
Merging the files: Documentation/es/user/rhythms.itely
Documentation/fr/user/rhythms.itely
Documentation/topdocs/NEWS.tely
Documentation/user/music-glossary.tely
input/lsr/chordchanges-for-fretboards.ly
input/lsr/making-slurs-with-complex-dash-structure.ly
input/lsr/non-default-tuplet-numbers.ly
input/lsr/non-traditional-key-signatures.ly
scm/define-context-properties.scm
scm/define-music-display-methods.scm
Deleted merge conflict for 'Documentation/es/user/rhythms.itely':
{local}: deleted
{remote}: modified
Use (m)odified or (d)eleted file, or (a)bort?
So at this point, I get the choice to use the modified file (which will be
in the wrong directory), or the deleted file (which is in the right
directory). Neither choice seems to be right.
If I choose d, the file never gets added to the commit (but there should be
modifications to the file).
If I choose m, the file gets added to the commit as a *new* file, in the
*old* path.
The files that didn't have merge conflicts appear to have worked just fine,
with modified commits in the new directory locations. But the files with
merge conflicts don't seem to be working properly.
Any detailed suggestions you could give me would be much appreciated.
Thanks,
Carl
>
> Ciao,
> Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How can I use git to help me merge a patch with the new directory structure
On 7/26/09 11:35 AM, "John Mandereau" wrote: > Le samedi 25 juillet 2009 à 22:37 -0600, Carl Sorensen a écrit : >> Any git gurus out there who have an idea of how I can do this without having >> to manually apply patches made between the files in the different >> directories? > > If marvellous renames detection capacity of Git enabled by default when > merging doesn't work for you (maybe you have to specify it manually when > you rebase, if this option ever exists in rebase, see the man pages), > make a patch file or your commit, or backup your patch file if you don't > have it in your Git repo, then try > > sed -i -e '#/user#/notation#g' your_patch_file > > This manual way with sed would probably be the only reasonable option > with a VCS like CVS. I used vim, instead of sed, but did that conversion. When done, git wouldn't apply it. I should have saved the results, but didn't. So I guess I shouldn't even be wasting bandwidth saying this; without the output there's nothing anybody can do to help. I'll keep working, and when I get a solid error, I'll post again. > > >> Any help would be appreciated; right now I feel like all of my work on >> autobeaming is in shambles and I'm going to have to do it all over again. > > Don't worry, all your fantastic work on autobeaming certainly needn't be > redone just for a few doc files moved :-) I know that; that's why I asked. I'm sure git can do it; I just don't know *how* to make it happen right now. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Sun, Jul 26, 2009 at 06:49:13AM -0400, Kieren MacMillan wrote: > Graham, > >> Oh, in case anybody was wondering: my father is pure native >> British, educated at Oxford, and considers the 1978 Fowler's >> Modern English second revised edition (printed in Oxford) to be >> the definitive guide to English writing. There's no American >> influence here! > > So what does Fowler's (both 1978 and the most recent edition) say about > the matter? We didn't end up looking in it, since he pointed out that it was a guide about English writing, not typography. He admitted that "all" commercial printers use one space in their works, although he suggested that it might depend on the type of font. The wikipedia page about this also notes that the effect of double-spacing a fixed-width font is similar to the effect of an em space (which some people use in single-spaced proportional fonts). So: we will continue to double-space sentences in the doc source, but generate single-spaced output. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request (\cueNotes)
On Sun, Jul 26, 2009 at 07:23:56PM +, Werner wrote:
> Reinhold Kainhofer kainhofer.com> writes:
>
> > How about using \new CueVoice?
>
> It indeed seems to be nearly what I'm looking for.
> (But I miss an easy example in the docs - it is so complicated there! So I
> even
> didn't find nor understand it. They explain there more cueDuring then cueVoice
> and everything quite sophisticated.)
> But in the following example unfortunately the CueVoice, which should be a
> second voice with stems down, behaves like a OneVoice (stems up and down).
>
> {es?4 es' << {es'4 d8 d~ | d4 f cis8 a f es | d4 c' c h8 b~ | b1 | } \\ \new
> CueVoice { es,4 d8 d~ | d4 f cis8 a f es | d4 c' c h8 b~ | b1 | } >> r4 r8 b'
> a4. g8 }
>
> So I have to add \stemDown and \stemNeutral.
This is part of NR 1.6.3, and not slated for any kind of major
revision. Could you suggest a rewrite or addition to the docs,
and/or could Jonathan implement said suggestion or rewrite
something himself.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: John's getting a PhD! (was: something about building stuff)
On Sun, Jul 26, 2009 at 07:38:20PM +0200, John Mandereau wrote: > Le dimanche 26 juillet 2009 à 02:02 -0700, Graham Percival a écrit : > > Congratulations! There seems to be a strong correlation between > > working on lilypond and getting PhDs. > > Maybe, but in my case it looks more like a coincidence between my > translations meister role in LilyPond and studies, even if one of my > supervisors Carlos Agon often says he and other people at the IRCAM love > LilyPond. Oh, I didn't mean to suggest that it was lilypond-related. AFAIK, only Erik's Maters thesis had anything to do with lilypond. No, I was just saying that we have a lot of smart, academically-oriented people working on lilypond. :) > > In this case, updating the CG (eventually -- once all the build > > stuff and translation infrastructure is finished) is even more > > important. > > Oh, please don't tell me that, except if you don't mind I update the CG > in one year. I just meant for the translation maintenance -- explaining how to merge material from lilypond/translation into master. If anything needs to be explained, that is... the frequency? Solutions to any common problems? Etc. That's only necessary if you're too busy to do this work yourself, of course. If you anticipate having whatever time is required for the normal translation maintenance, then it's not really important to add stuff to the CG. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
> - What is a good name for the new articulation? I suggest `vertical stroke'. At least this seems to be the name referred to in the literature for the staccato-like symbol which Mozart uses. > - What should be the precise shape (width/height ratio)? Currently I > use height = 1 staff_space and width = 1/5 staff_space (see attached > sample). Opinions? For Mozart, the stroke should perhaps a bit shorter -- maybe two different symbols? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
More documentation restructure issues
Hi John, After doing a full "make web" from scratch, I noticed a couple other issues that are likely makefile-related: 1) The following directories are missing copies of the stylesheets: Documentation/changes/ input/regression/ input/regression/musicxml/ 2) The links for snippet images need to be fixed on this page: Documentation/changes/index.es.html Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how is NR F. "LilyPond command index" generated?
On Sun, Jul 26, 2009 at 03:23:53PM -0700, Mark Polesky wrote: > > Graham Percival wrote: > > > Once John says it's safe to do doc work again, I'll add a > > checklist for doc modification. (if there's a new command, > > did you add a @funindex) > > Definitely put that on your TODO list or put a stub there or > something. Yes. > I wonder if there's a good way to find un-indexed commands that > are floating in the source ether... It's certainly *possible*. Texinfo creates an index file. Write a python script that parses that file (I think it's in text). Write another one that parses the docs (looking for \commands). Compare the two resulting lists. I don't think it's worth it (so, as I would say to Valentin, "it's a crappy idea" :)... except that this would be an easy Python project. So if there were any contributors (or potential contributors) who wanted to learn python while still benefitting lilypond, this could qualify. I suppose that Valentin will now add this to the tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More documentation restructure issues
On Sun, Jul 26, 2009 at 09:30:44PM -0700, Patrick McCarty wrote: > Hi John, > > After doing a full "make web" from scratch ... That's what I thought, but not what I typed, of course. :-) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Implement tool to check sorting of lists, etc.
Hey everyone, here's my latest attempt at an idea I had a while ago. The idea was to find a way to quickly check if certain lists and alists appear in order in the source code itself. This will help to keep our code organized. I suppose there are other ways to do it, but for the way I ended up designing it, here's how a developer might use it: 1) compile (new file) check-sorting.ly. 2) look at the console output. 3) make changes to files if necessary. Note that this will identify some "problems" that should be ignored. For example, the all-internal-grob-properties list in define-grob-properties.scm appears to have some out-of- order properties. But if you look at the source, you will see that they're intentionally arranged in three groups: grobs & grob arrays other ancient notation But otherwise, I think this can be a useful time-saver for future code-janitors. In the attached patch, I've tested eight lists/alists from 6 different scm files as a demonstration. It shouldn't be too much trouble to add more. Can someone test this and let me know what they think? Feel free to intentionally move things out of order in the files affected to see how it works. Also, is there a more preferable way to do it? Thanks! - Mark ps. example output... define-context-properties.scm: * all-user-translation-properties (list) + Properly sorted. * all-internal-translation-properties (list) + Properly sorted. define-grob-properties.scm: * all-user-grob-properties (list) + Properly sorted. * all-internal-grob-properties (list) + All elements appear only once. - The following pairs of consecutive elements are out of order: Y-common adjacent-pure-heights use-breve-rest add-cauda define-grobs.scm: * all-grob-descriptions (alist) + All grob descriptions are pairs. + All meta fields are in proper tail position. - The following grobs have duplicate properties: TextScript: (direction) + All grobs are in order. - The properties of the following grobs are not in order. BarLine SpanBar + All grob interfaces are in order. define-music-display-methods.scm: * post-event-list (list) + Properly sorted. define-music-properties.scm: * all-music-properties (list) + Properly sorted. define-music-types.scm: * music-descriptions (alist) + Properly sorted. 0001-Implement-tool-to-check-sorting-of-lists-etc.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Rewrite the vertical layout of staves/systems.
I don't really understand the code from this patchset, but I just have
one quick comment.
Thanks,
Patrick
http://codereview.appspot.com/97119/diff/1/22
File lily/staff-grouper-engraver.cc (right):
http://codereview.appspot.com/97119/diff/1/22#newcode21
Line 21: {
Are engravers allowed to inherit code from other classes?
I'm asking because there is a comment in slur-engraver.cc:
(on principle, engravers don't use inheritance for code sharing)
If the inheritance is okay, then the comment (and others, if any) should
be removed from the slur-engraver.cc.
http://codereview.appspot.com/97119
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup command `parenthesize'
Mark Polesky writes: > There already is a command named parenthesize defined on line 604 > of ly/music-functions-init.ly. I think you need to rename it to > avoid conflicts. Perhaps "parenthesize-markup"? I could be wrong but I don't think they conflict, because music functions and markup commands have separate namespaces. The music function `parenthesize' and markup command `parenthesize' operate in different domains but have essentially the same meaning, which is why it seemed natural to me for them to have the same name. Does it cause too much confusion? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
