Re: Guidelines for bounding boxes?
Werner LEMBERG w...@gnu.org writes: Are there any guidelines LilyPond adheres to for creating bounding boxes? No. For example, when I adjusted the bbox for the \eyeglasses markup command, I _underestimated_ the bbox. Should I have slightly _overestimated_ instead? Attached is a PNG displaying the bbox. I think overestimation is better. Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. What you call `bounding boxes' aren't real bboxes but the metrics boxes of the glyphs. In case of the bass clef, for example, the top shape is treated as with many other rounded glyphs in normal fonts: The `overshoot' sticks out. On the other hand, the height has been enlarged so that it covers the staff vertically. One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
Neil Puttock wrote Monday, August 10, 2009 12:31 AM 2009/8/10 Patrick McCarty pnor...@gmail.com: I wonder why we are seeing different beaming patterns? I think all of your manually-beamed patterns are correct though. Trevor's using the MinGW build I posted a few days ago, so it's missing Carl's last changes to beam-settings.scm. Aah, thanks for reminding me, Neil. I'd forgotten those. I'll fish them out and apply them to my current LP. Sorry for the confusion, Carl. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
On Sun, Aug 09, 2009 at 04:48:45PM -0700, Graham Percival wrote: On Sun, Aug 09, 2009 at 11:45:05PM +0200, John Mandereau wrote: Le samedi 08 août 2009 à 13:55 -0600, Carl Sorensen a écrit : As a practical matter, -r first applies the changes that were made on origin (since your branch was checked out), then applies your changes on top of the current origin. The prevents an extra commit to merge your branch with origin, and keeps the git history cleaner. My recommendation is to always use it; it makes things much nicer. I agree, except when docs in English are edited and translations committishes are updated before edited docs in English are pushed. ? And even worse, the difference between those two commands depends on what kind of update the contributor is working on?! After spending a while reading and re-reading your addition to the CG git stuff, it sounds like this only applies to translated docs -- i.e. as long as I don't mess with anything in de/ es/ fr/ etc/, it's safe to git pull -r. Is that correct? If so, I'll amend the warning to begin translators: if you have changed committishes... Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
Le dimanche 09 août 2009 à 16:48 -0700, Graham Percival a écrit : Mao. So that means that we don't want to add git config --global branch.autosetuprebase always to the git setup, and we still have to tell people to do git pull -r instead of git pull ? You didn't read the end of the paragraph I added in the CG. Actually, we could make this option standard (except for people who merge master and lilypond/translation), if and only if contributors are required to use committishes in the head of translated files exclusively from git.sv.gnu.org master branch. I'm thinking about adding a command (a make target, actually) to update committishes in a way that meets this requirement. And even worse, the difference between those two commands depends on what kind of update the contributor is working on?! Yes, except if we have the requirement explained above. As all translators eventually mess up committishes (I already did), this would be saner. 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: the r in git pull -r
Le lundi 10 août 2009 à 00:56 -0700, Graham Percival a écrit : After spending a while reading and re-reading your addition to the CG git stuff, it sounds like this only applies to translated docs -- i.e. as long as I don't mess with anything in de/ es/ fr/ etc/, it's safe to git pull -r. This is even broader: as long as you don't touch committishes in files in de/ es/ fr/ etc., it's safe to git pull -r. This distinction is important, because doc contributors and developers are supposed to edit docs in all languages in some cases, but after thinking again about it, I needn't ask people other than translators and me to mess up with committishes. Is that correct? If so, I'll amend the warning to begin translators: if you have changed committishes... You may amend this paragraph anyway. 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: parser variables persist beyond { } scope
Le dimanche 09 août 2009 à 16:43 -0600, Carl Sorensen a écrit : How about \afterGraceSpacing spacing music music? That's OK for me; unless there is any objection on the command name, I'll add the function with this name. 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: the r in git pull -r
On Mon, Aug 10, 2009 at 08:45:22AM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, August 10, 2009 12:48 AM I maoing hate git. Git is fine; the complexity comes from the baroque structures in LilyPond. Let's be thankful Git has tools to cope :) Oh? Didn't you comment that if you had to use git at the beginning, you wouldn't have ever started contributing? Remember Tim's first reaction when he saw the instructions for starting to help the website -- criminity on a crutch: http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00288.html We've lost 50% of potential contributors to the website because of git. Now, it's an open question whether those potentials were actually serious or not. However, I know that it took one serious contributor almost a week to reach the state of being able to send me good updates. Even disregarding the offers of help that dried up when git was mentioned, I do *not* think that spending a week fighting git is very motivating. My vitriolic hatred of git isn't for my own sake -- I can bludgeon it into doing whatever I need. If necessary, I'll break down and read the manual. And I'm not going to leave lilypond because of git. But as the person most involved with new contributors -- both GDP and trying to encourage others to work on the website -- I see helpful people disappearing after I point them at the git instructions time and time again. Granted, some people's good intentions only last as far sending emails... but I'm sure that *some* of them would have become actual contributors if the initial burden were lessened. Wouldn't another 3 or 4 people working on the docs be nice? I don't care if git log or merging patches from one branch to another is complicated. But simple things like get source, update source, upload my changes should be simple. svn does this quite well. I've heard nice things about bazaar. But git? Apparently git pull -r is the best way to update... in /most/ cases... but lilypond-devel only discovered this a few years ago. And we have at least one git developer on this list! That's why I want the CG to have the **minimum** required to do those simple things in git. Pretend that you've just discovered a few typos in the docs. Being a helpful person, you want to fix them, and you know that a patch is the easiest thing for us to work with. How much git should you suffer through in order to create that patch? IMO, the minimum is: - download and install git. - download source code. (copypaste from CG 1.1.1) - update source code. (copypaste from CG 1.2.2) - spend time editing the files. (this is what we want contributors to spend time doing!) - send us their changes. (copypaste from CG 1.3.1) We want people working on lilypond, not working at understanding git. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation question
Le lundi 10 août 2009 à 06:40 +0200, Werner LEMBERG a écrit : It would be sufficient for me if `make all' simply aborts with a message configure.in has been modified! Please rerun `autogen.sh', then `make all' again. or something like that. Done. INSTALL.txt and the Contributors Guide explain in detail what the message says. 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: Guidelines for bounding boxes?
One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). Yes, this problem already bites us. I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation question
configure.in has been modified! Please rerun `autogen.sh', then `make all' again. Done. Thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
slur information available within callback?
Is there any possibility to retrieve informations about slurs being
adjacent from a callback?
For example
\displayMusic { c4 ( c ) ( c ) c }
shows
[...]
(make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'pitch
(ly:make-pitch -1 0 0))
(make-music
'SlurEvent
'span-direction
1)
(make-music
'SlurEvent
'span-direction
-1)))
[...]
so the two appearances of a 'SlurEvent with opposite sign shows that a
slur end and starts on the same note.
Can I retrieve this kind of information from within a callback?
#(define-public (slur::test grob)
(let* ((left-bound (ly:spanner-bound grob LEFT))
(right-bound (ly:spanner-bound grob RIGHT))
(left-note (ly:grob-property left-bound 'cause))
(right-note (ly:grob-property right-bound 'cause)))
(display \nleft note: )(display (event-cause left-note))(newline)
(ly:slur::print grob)))
The console output shows only informations about duration, pitch etc.,
but nothing about the corresponding
slurs. Is this information still accesible at this step, and if yes, how?
Thanks in advance
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
Hi, On Mon, 10 Aug 2009, Graham Percival wrote: On Mon, Aug 10, 2009 at 08:45:22AM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, August 10, 2009 12:48 AM I maoing hate git. Git is fine; the complexity comes from the baroque structures in LilyPond. Let's be thankful Git has tools to cope :) Oh? Didn't you comment that if you had to use git at the beginning, you wouldn't have ever started contributing? Remember Tim's first reaction when he saw the instructions for starting to help the website -- criminity on a crutch: http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00288.html We've lost 50% of potential contributors to the website because of git. Now, it's an open question whether those potentials were actually serious or not. However, I know that it took one serious contributor almost a week to reach the state of being able to send me good updates. Even disregarding the offers of help that dried up when git was mentioned, I do *not* think that spending a week fighting git is very motivating. Fair enough. Maybe it is time to suggest an easy interface to Git? You could even write a very simple wrapper around Git that _just_ downloads the current version of LilyPond, allows the user to edit the files and then click another button to send the patch. For Windows, it would be even easier: I could make a custom version of the Git installer just for you, which comes with a Tcl/Tk interface (or uses Git GUI right away). Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
On Mon, Aug 10, 2009 at 10:34:11AM +0200, Johannes Schindelin wrote: On Mon, 10 Aug 2009, Graham Percival wrote: We've lost 50% of potential contributors to the website because of git. Fair enough. Maybe it is time to suggest an easy interface to Git? You could even write a very simple wrapper around Git that _just_ downloads the current version of LilyPond, allows the user to edit the files and then click another button to send the patch. Seriously?! That would be **fantastic**! I don't think it needs to be a GUI, though. A program or script that downloads the latest material on the master/ branch, then produces a patch upon request. Like: $ git-easy get (produces lilypond/ with the current master/ branch) $ cd lilypond/ $ git-easy update (downloads any updates) $ vi Documentation/learning.itely $ git-easy commit (produces a patch in ../ ) $ git-easy reset (reverts to exactly the online master/ branch) I know that a command-line app would be a bit unfamiliar for windows users, but I'm ok asking them to learn that much. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit : We've lost 50% of potential contributors to the website because of git. And we've lost the same percentage of potential French translators; I'm sorry to remark that most of them who didn't spend the effort to master Git and stopped contributing didn't spend much effort either to look for accurate translation of musical and other technical terms, or even respecting Texinfo format editing (I once got a translation in ODT!) which is yet far simpler and comfortable than XML-based formats or PO. Of course, simplifying version control system usage is still very important to help translators who spend enough effort be more productive. IMO, the minimum is: - download and install git. - download source code. (copypaste from CG 1.1.1) - update source code. (copypaste from CG 1.2.2) - spend time editing the files. (this is what we want contributors to spend time doing!) - send us their changes. (copypaste from CG 1.3.1) We want people working on lilypond, not working at understanding git. Agreed. Many people are scared by just using command line, and I doubt we'll manage to get the procedure above simpler, so the only solution is providing another way to contribute, e.g. a web interface that is not read-only but that allows retrieval and submission of individual files or file sets, or a GUI that makes command-line usage completely optional but that offers a limited subset of Git features... like Johannes just proposed ;-) I slightly prefer the Web interface option, as it's cross-platform (GNU/Linux users can have difficulty with Git) and work even with poor internet connexions that filter everything but DNS, HTTP and HTTPS. 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: the r in git pull -r
Graham Percival wrote Monday, August 10, 2009 9:18 AM On Mon, Aug 10, 2009 at 08:45:22AM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, August 10, 2009 12:48 AM I maoing hate git. Git is fine; the complexity comes from the baroque structures in LilyPond. Let's be thankful Git has tools to cope :) Oh? Didn't you comment that if you had to use git at the beginning, you wouldn't have ever started contributing? Remember Tim's first reaction when he saw the instructions for starting to help the website -- criminity on a crutch: http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00288.html Yes, but the solution to that was for you to manage git, and for me to send you edited files. That worked fine, and that is what I'd prefer for git-challenged *doc* contributors. As I've said before, I'm happy to manage the git interface for such people. I'd rather have complete edited doc files sent to me rather than trying to help people install git via a recipe and then teaching them how to make valid diffs. Once they've mastered texinfo, are still keen and looking for more challenging work is when git should be mentioned. For potential contributors to the *code* the situation is different. Anyone capable of modifying LP code should have little problem understanding git and using it fully. Although I admit a gentle introduction would be helpful :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
On Mon, Aug 10, 2009 at 10:50:09AM +0200, John Mandereau wrote: Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit : We've lost 50% of potential contributors to the website because of git. And we've lost the same percentage of potential French translators; I'm sorry to remark that most of them who didn't spend the effort to master Git and stopped contributing didn't spend much effort either to look for accurate translation of musical and other technical terms, or even respecting Texinfo format editing (I once got a translation in ODT!) which is yet far simpler and comfortable than XML-based formats or PO. I agree that there's a correlation between willingness to learn git and quality of work. I'm not opposed to asking contributors to jump through _some_ hurdles; I just think we don't have the right balance yet. Off the top of my head, I'd guess that we want to discourage 25% of potential contributors. We want people working on lilypond, not working at understanding git. Agreed. Many people are scared by just using command line, and I doubt we'll manage to get the procedure above simpler, so the only solution is providing another way to contribute, e.g. a web interface that is not read-only but that allows retrieval and submission of individual files or file sets, IIRC you or Valentin have mentioned this in the past. How would this work with, say, documentation? Would a potential contributor retrieve the doc file set (autogen.sh + Documentation/, potentially trimming out the translations)? I'm not eager to drop the does it compile? question for contributors, even for documentation. Apart from people on windows who *cannot* compile the docs, I'd still ask doc contributors to build the docs locally. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is now issue #829. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
On 10/08/2009 09:03, John Mandereau wrote: Le dimanche 09 août 2009 à 16:43 -0600, Carl Sorensen a écrit : How about \afterGraceSpacingspacing music music? That's OK for me; unless there is any objection on the command name, I'll add the function with this name. Best, John I still think it's a shame we need to have a separate function but. . . Maybe we should call this one \afterGraceSpaced or \afterGraceWithSpacing? That way the name says we are using afterGrace notes and are choosing to space them. \afterGraceSpacing implies it's just a function to set the \afterGraceFraction variable. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spacing over a new piece beginning is too small
On Mon, 2009-08-10 at 11:00 +0200, Reinhold Kainhofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yet another small issue with the vertical layout: It seems that where one piece ends and another one begins, the piece title is completely ignored for spacing. Even worse, Sometimes the spacing between the last staff of a piece and the first staff of the next piece is LESS than for staves inside a piece. As an example, attached is some output I'm getting: The staves where Ecce panis starts are spaced less than the other staves instead of more, and the piece titles In figuris and Bone pastor are crammed in without any visual effect on the staff spacing. This is because the default stretchable space for before-title-spacing and after-title-spacing is too small. Could you find a value that works better? The overlap between Ecce panis and Allegro is due to a bug (that you and Werner have already found) regarding rehearsal marks not being counted in the spacing problem. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Le lundi 10 août 2009 à 00:36 +0100, Ian Hulin a écrit :
So providing we could stitch this into the lilypond parsing, you could get
\afterGrace #(5.16) {c'1} {d16[ e16]) ;or
\afterGrace {c1} {d16[ e16]} ; or even
\afterGrace #:fraction #(5.16} #main: {c1} #grace {d16[ e 16]} ; and
\afterGrace #:main {c1} #:grace {d16[ e16]}
If you added the keyword clauses to the definition. Keywords would get
round the problem of having to order the parameters to make sure the
music expressions are at the end.
Keywords may be going a bit far, but is the optional parameter idea
maybe a runner?
I'm not sure I know why all languages I know (including Scheme) that
support optional arguments require them after mandatory arguments, but I
think it's not worth fighting against this by trying to support optional
arguments first in ly music functions.
IMHO keyword arguments are not worth the effort, patches might be
welcome to prove the contrary.
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: Spacing over a new piece beginning is too small
The overlap between Ecce panis and Allegro is due to a bug (that you and Werner have already found) regarding rehearsal marks not being counted in the spacing problem. You haven't fixed this, right? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Hi Werner, if you can explain me what should I do, I would try to make it. -- Marek Klein http://gregoriana.sk 2009/8/10 Werner LEMBERG w...@gnu.org I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is now issue #829. Werner ___ 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
Dead lyrics context still occupies vertical space
Hello. The example below shows that the new vertical engine makes dead
lyrics contexts to occup space. This did not happen before, IMO the
new lyrics should (IF it has enough room) to align with the previous
one.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com
dead-lyrics-context-takes-vertical-space.pdf
Description: Adobe PDF document
\version 2.13.4
\header { title= Dead lyrics context takes vertical space
subtitle = b40e3a4336e9c Mon Aug 10 09:36:27 2009 }
#(ly:set-option 'point-and-click #f)
music = \relative f' {
\new Voice =main { c1 c c }
\new Voice = fork { c1 c c c }
}
mainlyrics = \lyricmode { A A A }
forklyricsOne = \lyricmode { B B B B }
forklyricsTwo = \lyricmode { C C C C }
\score {
\new Staff { \music }
\new Lyrics \lyricsto main { \mainlyrics }
\new Lyrics \lyricsto fork { \forklyricsOne }
\new Lyrics \lyricsto fork { \forklyricsTwo }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
2009/8/10 Graham Percival gra...@percival-music.ca: On Mon, Aug 10, 2009 at 10:50:09AM +0200, John Mandereau wrote: Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit : We've lost 50% of potential contributors to the website because of git. And we've lost the same percentage of potential French translators; I'm sorry to remark that most of them who didn't spend the effort to master Git and stopped contributing didn't spend much effort either to look for accurate translation of musical and other technical terms, or even respecting Texinfo format editing (I once got a translation in ODT!) which is yet far simpler and comfortable than XML-based formats or PO. I agree that there's a correlation between willingness to learn git and quality of work. I'm not opposed to asking contributors to jump through _some_ hurdles; I just think we don't have the right balance yet. Off the top of my head, I'd guess that we want to discourage 25% of potential contributors. We want people working on lilypond, not working at understanding git. Agreed. Many people are scared by just using command line... Sometimes we forget that LilyPond is a command-line app. We already are losing users that do not want to write code. So, if you hate command lines or writing code, you'll hate LilyPond. LilyPond code is very easy for beginners and I have proved it. Git basics are only slightly more difficult. Potential contributors who previously qualify as frequent LP users are very used to write code, so they will find as a natural extension to learn git basics and start making patches whenever they want. I personally find more complicated to understand overrides or to write lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png myfile.ly to obtain a decent cropped PNG than git pull + edit + git format-patch to contribute to the docs. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
Hi,
On Mon, 10 Aug 2009, Graham Percival wrote:
On Mon, Aug 10, 2009 at 10:34:11AM +0200, Johannes Schindelin wrote:
On Mon, 10 Aug 2009, Graham Percival wrote:
We've lost 50% of potential contributors to the website because of
git.
Fair enough. Maybe it is time to suggest an easy interface to Git? You
could even write a very simple wrapper around Git that _just_ downloads
the current version of LilyPond, allows the user to edit the files and
then click another button to send the patch.
Seriously?! That would be **fantastic**!
I don't think it needs to be a GUI, though. A program or script
that downloads the latest material on the master/ branch, then
produces a patch upon request. Like:
$ git-easy get
(produces lilypond/ with the current master/ branch)
$ cd lilypond/
$ git-easy update
(downloads any updates)
This could be combined into a single call that automagically checks if
lilypond.git was already cloned/initremote added.
$ vi Documentation/learning.itely
$ git-easy commit
(produces a patch in ../ )
$ git-easy reset
(reverts to exactly the online master/ branch)
I'd actually make throw-away branches under the hood, so that it is easy
to get at previous commits if need be (although this will need a little
hand-holding by a Git-savvy person).
I know that a command-line app would be a bit unfamiliar for windows
users, but I'm ok asking them to learn that much.
It is _so_ easy to make a simple Tcl/Tk GUI.
Example:
-- snip --
#!/usr/bin/wish
package require Tk
wm title . LilyPond Contributor's GUI
set lily_dir $env(HOME)/lilypond
proc call_git {args} {
global lily_dir
set args [linsert $args 0 git --git-dir=$lily_dir]
puts execing $args
if {[catch {eval [eval exec $args]} msg]} {
tk_messageBox -type ok -message $msg
}
}
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
call_git clone git://repo.or.cz/lilypond.git
} else {
call_git pull
}
}
button .update -text Clone/Update LilyPond -command update_lilypond
pack .update
-- snap --
Of course, this is not really a fully functional script:
- it needs to check if the user name and email is set correctly, and ask
the user for this information otherwise,
- it needs to get a button for committing and sending the patch (renaming
the branch to a unique name (probably based on the commit message) and
re-checking out the 'master'),
- it probably should not clone, but do a shallow fetch of the correct
branch, and
- it needs to show the progress of the command in a text area.
But you get the idea. I do not expect this script to be larger than 3kB,
tops.
Ciao,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
On 10/08/2009 10:52, John Mandereau wrote:
Le lundi 10 août 2009 à 00:36 +0100, Ian Hulin a écrit :
So providing we could stitch this into the lilypond parsing, you could get
\afterGrace #(5.16) {c'1} {d16[ e16]) ;or
\afterGrace {c1} {d16[ e16]} ; or even
\afterGrace #:fraction #(5.16} #main: {c1} #grace {d16[ e 16]} ; and
\afterGrace #:main {c1} #:grace {d16[ e16]}
If you added the keyword clauses to the definition. Keywords would get
round the problem of having to order the parameters to make sure the
music expressions are at the end.
Keywords may be going a bit far, but is the optional parameter idea
maybe a runner?
I'm not sure I know why all languages I know (including Scheme) that
support optional arguments require them after mandatory arguments, but I
think it's not worth fighting against this by trying to support optional
arguments first in ly music functions.
IMHO keyword arguments are not worth the effort, patches might be
welcome to prove the contrary.
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
John,
I'm away from home at the moment but I'll have a play with this after
tomorrow when I get back. We could try something like
(define* afterGrace (parser location #:optional (fraction (3.4))
( main (ly:error Main notes music expression required for \afterGrace)
grace (ly:error Aftergraces music expression required for
\afterGrace) )
(pair? music? music?)
;; fraction gets defaulted to (3.4) if not coded
;; mainnotes parameter throws error if not coded
;; aftergraces parameter throws error if not coded
;
; rest of function body
)
I suppose your next observation would be the error messages would need
to be in translatable string definitions . . .
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spacing over a new piece beginning is too small
On Mon, 2009-08-10 at 12:27 +0200, Werner LEMBERG wrote: The overlap between Ecce panis and Allegro is due to a bug (that you and Werner have already found) regarding rehearsal marks not being counted in the spacing problem. You haven't fixed this, right? I have now :) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
if you can explain me what should I do, I would try to make it. OK. However, it seems to be more complicated than thougth at a first glance. Anyway, here a rough outline how it could be done. 1. Metafont is called for those fonts: feta11.mf, feta13.mf, ..., feta-braces-a.mf, feta-braces-b.mf, ..., feta-alphabet11.mf, feta-alphabet13.mf, ..., parmesan11.mf, parmesan13.mf, ... Except of the feta-alphabetXX fonts, all fonts cause warnings since they contain more than 15 different heights and depths. The idea is now to split up feta, feta-brace, and parmesan into smaller fonts. Let's look into feta11.mf: It reads feta-autometric for some macros, sets the design size, then reads the generic driver file feta-generic.mf. This file in turn reads the following files: feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I could now imagine to replace feta11 with feta-eindelijk11, feta-toevallig11, feta-arrow11, ... Similar things should be done for the other sub-families. feta-eindelijk11.mf would look like this: input feta-autometric; design_size := 11.22; subfont := feta-eindelijk; input feta-generic; end. The `subfont' variable is then used in feta-generic; instead of the large number of `input ...' lines you would just have scantokens (input subfont); [`input' doesn't expand its argument; you have to use the above trick as explained in The METAFONT book, page 180.] 2. Update `aybabtu.pe.in'. 3. You have to update `scripts/build/mf-to-table.py' to add a new command line option so that all its arguments are recognized as subfonts, sending the output data to a single file instead of multiple files. 4. Update scripts/build/gen-emmentaler-scripts.py to load all subfonts. 5. Update GNUmakefile. To see what's going on I recommend that you compile lilypond from scratch, diverting stdin and stderr to a file like this: make all make.all.log A further refinement would be to make the Makefile generate the Metafont driver files on the fly to avoid zillions of input files. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB guile download broken
Op donderdag 30-07-2009 om 20:23 uur [tijdzone -0700], schreef Graham Percival: Hi Graham, Whenever you get a chance, could you take a look at this? I cleaned out the GUB dir (rm -rf *; git reset --hard origin) and now it can't download guile. This is the console message; I could send more details from other logs if you want. Fixed/worked around in master. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing configure with Autoconf 2.64
On Thu, 2009-08-06 at 10:53 -0700, Patrick McCarty wrote: On Thu, Aug 06, 2009 at 06:22:05PM +0200, John Mandereau wrote: Le mercredi 05 août 2009 à 21:03 -0700, Patrick McCarty a écrit : I need this patch to run ./autogen.sh with the latest Autoconf version (2.64). The only earlier version I am able to test is 2.63, which works fine with the patch. The warnings I am seeing and workarounds are here: http://www.gnu.org/software/hello/manual/autoconf/Expanded-Before-Required.html Okay to apply? (or is there a better fix?) Shouldn't AC_PROG_CC be AC_PROG_CXX? :-) That's actually a good point. But since we've always used AC_PROG_CC, and there haven't been any reports of this not working, I think we should just keep using the same macro. Other than this it works for me. I'm not an expert with autoconf, so I' don't know about possible better fixes. After looking into this some more, I think this fix is perfectly safe for any Autoconf version. Autoconf 2.64 catches cases of incorrect macro nesting, so expanding AC_PROG_CC before stepmake is initialized should be all that's needed. I'll push. This seems to have broken the --disable-optimising argument to configure. With commit 74bdeea4, I get $ ./autogen.sh --disable-optimising $ grep O2 config.make (nothing) With this patch (40911543), I get $ ./autogen.sh --disable-optimising $ grep O2 config.make CONFIG_CFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) CONFIG_CXXFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) My autoconf is version 2.63 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
Trevor Daniels wrote Monday, August 10, 2009 8:49 AM
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty pnor...@gmail.com:
I wonder why we are seeing different beaming patterns? I think
all of
your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing Carl's last changes to beam-settings.scm.
Aah, thanks for reminding me, Neil. I'd forgotten those. I'll
fish
them out and apply them to my current LP.
With all Carl's mods applied just the expected two inconsistencies
remain:
\relative c'' {
a8 a a16 a a8 a a a a16 a | % wrong, should be ...
a8 a a16[ a a8] a a a[ a16 a] |
a32 a a16 a a a a32 a a16 a a a a32 a a16 a a a a32 a | % wrong,
should be ...
a32[ a a16 a a] a[ a32 a a16 a] a[ a a32 a a16] a a a a32 a
}
The second of these can be fixed (bypassed really) with
\overrideBeamSettings #'Score #'(4 . 4) #'end #'(((1 . 32) . (8 8 8
8)))
which I think is a more acceptable beaming anyway,
but the first is a more fundamental problem which cannot be
fixed by any override which preserves beam breaks at
1/4, 1/2 and 3/4 AFAICS.
Trevor
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilycontrib.tcl, was Re: the r in git pull -r
Hi,
On Mon, 10 Aug 2009, Johannes Schindelin wrote:
On Mon, 10 Aug 2009, Graham Percival wrote:
On Mon, Aug 10, 2009 at 10:34:11AM +0200, Johannes Schindelin wrote:
On Mon, 10 Aug 2009, Graham Percival wrote:
We've lost 50% of potential contributors to the website because of
git.
Fair enough. Maybe it is time to suggest an easy interface to Git?
You could even write a very simple wrapper around Git that _just_
downloads the current version of LilyPond, allows the user to edit
the files and then click another button to send the patch.
Seriously?! That would be **fantastic**!
Okay, I could not resist, so here is something more capable. It actually
only gives you a Clone/Update button that makes sure that a local clone
(hardcoded to $HOME/lilypond) is up-to-date, but at least it has a
progress bar, and I verified that it works even on Windows (what with its
ridiculous insistence to put everything into directories containing
spaces).
From here, it should be _relatively_ easy to extend (read: I will be
available for assistance, but I do not plan to work further on this, at
least not alone):
-- snipsnap --
#!/usr/bin/wish
package require Tk
# create the GUI
wm title . LilyPond Contributor's GUI
button .update -text Clone/Update LilyPond -command update_lilypond
panedwindow .output
text .output.text -width 80 -height 15 \
-xscrollcommand [list .output.horizontal set] \
-yscrollcommand [list .output.vertical set]
scrollbar .output.horizontal -orient h -command [list .output.text xview]
scrollbar .output.vertical -orient v -command [list .output.text yview]
pack .output.horizontal -side bottom -fill x
pack .output.vertical -side right -fill y
pack .output.text -expand true -anchor nw -fill both
pack .update .output
# the callbacks
set lily_dir $env(HOME)/lilypond
proc write_to_output {f} {
if {[eof $f]} {
global git_command
fconfigure $f -blocking true
if {[catch {close $f} err]} {
tk_messageBox -type ok -message Git aborted: $err
}
unset git_command
} else {
.output.text insert insert [read $f 24]
.output.text see end
}
}
# naming this function git allows cute calls: they look like shell
proc git {args} {
global lily_dir git_command
set git_command [linsert $args 0 |git --git-dir=$lily_dir/.git]
set git_command $git_command 2@1
#.output.text insert end $git_command\n
set git [open $git_command r]
fconfigure $git -blocking false
fileevent $git readable [list write_to_output $git]
vwait git_command
}
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
file mkdir $lily_dir
git init
git config core.bare false
git remote add -t master \
origin git://repo.or.cz/lilypond.git
git fetch --depth 1
git checkout -b master origin/master
} else {
git pull
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG wrote: feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I've always wished those were in English. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New instrument name posititioning in scheme displays instr. name for haraiki'ed staves
Since the patch b8a1b9b174a3b68f05bb3e08fb5f754649b92574, short instrument
names for harakiried staves are still printed (above each other, at the top of
the system).
Example attached.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.13.4
\pointAndClickOff
\score {
\new StaffGroup
\new Staff {
\set Staff.shortInstrumentName = A 1
c''1 \break c''1
}
\new Staff {
\set Staff.shortInstrumentName = B 2
R1*2
}
\new Staff {
\set Staff.shortInstrumentName = C 3
R1*2
}
\layout {
\context { \RemoveEmptyStaffContext }
}
}
iname.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New instrument name posititioning in scheme displays instr. name for haraiki'ed staves
2009/8/10 Reinhold Kainhofer reinh...@kainhofer.com: Since the patch b8a1b9b174a3b68f05bb3e08fb5f754649b92574, short instrument names for harakiried staves are still printed (above each other, at the top of the system). Oh dear, that's not good. :) It looks like I should have paid more attention to `instrument-name-hara-kirk.ly' (and to Joe's comment about applying interval-center to an empty interval, since this would only occur if the elements list is empty, i.e., hara-kiried); unfortunately, this regression didn't show up with `make check'. I'll push a fix once I've double checked the regression tests. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG wrote: I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. I wasn't meaning to sound US-centric; I'm more concerned with wasting developers' time with hard-to-read code. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New instrument name posititioning in scheme displays instr. name for haraiki'ed staves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 10. August 2009 22:56:09 schrieb Neil Puttock: 2009/8/10 Reinhold Kainhofer reinh...@kainhofer.com: Since the patch b8a1b9b174a3b68f05bb3e08fb5f754649b92574, short instrument names for harakiried staves are still printed (above each other, at the top of the system). Oh dear, that's not good. :) [...] I'll push a fix once I've double checked the regression tests. ... and added a new regression test for this bug, right? ;-) 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) iD8DBQFKgI0/TqjEwhXvPN0RAnkyAJ91QPKZ4VVYx4HJDq9h7XJtpzGRCwCfYJ+u o9nsA5RNe/y26Fuy1xsVlGs= =QzYC -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Mon, Aug 10, 2009 at 5:57 PM, Mark Poleskymarkpole...@yahoo.com wrote: I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. I wasn't meaning to sound US-centric; I'm more concerned with wasting developers' time with hard-to-read code. They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing configure with Autoconf 2.64
On Mon, Aug 10, 2009 at 8:11 AM, Joe Neemanjoenee...@gmail.com wrote: On Thu, 2009-08-06 at 10:53 -0700, Patrick McCarty wrote: On Thu, Aug 06, 2009 at 06:22:05PM +0200, John Mandereau wrote: Le mercredi 05 août 2009 à 21:03 -0700, Patrick McCarty a écrit : I need this patch to run ./autogen.sh with the latest Autoconf version (2.64). The only earlier version I am able to test is 2.63, which works fine with the patch. The warnings I am seeing and workarounds are here: http://www.gnu.org/software/hello/manual/autoconf/Expanded-Before-Required.html Okay to apply? (or is there a better fix?) Shouldn't AC_PROG_CC be AC_PROG_CXX? :-) That's actually a good point. But since we've always used AC_PROG_CC, and there haven't been any reports of this not working, I think we should just keep using the same macro. Other than this it works for me. I'm not an expert with autoconf, so I' don't know about possible better fixes. After looking into this some more, I think this fix is perfectly safe for any Autoconf version. Autoconf 2.64 catches cases of incorrect macro nesting, so expanding AC_PROG_CC before stepmake is initialized should be all that's needed. I'll push. This seems to have broken the --disable-optimising argument to configure. With commit 74bdeea4, I get $ ./autogen.sh --disable-optimising $ grep O2 config.make (nothing) With this patch (40911543), I get $ ./autogen.sh --disable-optimising $ grep O2 config.make CONFIG_CFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) CONFIG_CXXFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) My autoconf is version 2.63 Sorry about that, Joe. I could reproduce with Autoconf 2.64 as well. Can you test the latest git to see if it works now? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New instrument name posititioning in scheme displays instr. name for haraiki'ed staves
2009/8/10 Reinhold Kainhofer reinh...@kainhofer.com: ... and added a new regression test for this bug, right? ;-) Heheh, I'm hoping it won't come to that if I can get the existing test to work properly (I'm hopeful making the name longer will work). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing configure with Autoconf 2.64
On Mon, 2009-08-10 at 14:23 -0700, Patrick McCarty wrote: On Mon, Aug 10, 2009 at 8:11 AM, Joe Neemanjoenee...@gmail.com wrote: On Thu, 2009-08-06 at 10:53 -0700, Patrick McCarty wrote: On Thu, Aug 06, 2009 at 06:22:05PM +0200, John Mandereau wrote: Le mercredi 05 août 2009 à 21:03 -0700, Patrick McCarty a écrit : I need this patch to run ./autogen.sh with the latest Autoconf version (2.64). The only earlier version I am able to test is 2.63, which works fine with the patch. The warnings I am seeing and workarounds are here: http://www.gnu.org/software/hello/manual/autoconf/Expanded-Before-Required.html Okay to apply? (or is there a better fix?) Shouldn't AC_PROG_CC be AC_PROG_CXX? :-) That's actually a good point. But since we've always used AC_PROG_CC, and there haven't been any reports of this not working, I think we should just keep using the same macro. Other than this it works for me. I'm not an expert with autoconf, so I' don't know about possible better fixes. After looking into this some more, I think this fix is perfectly safe for any Autoconf version. Autoconf 2.64 catches cases of incorrect macro nesting, so expanding AC_PROG_CC before stepmake is initialized should be all that's needed. I'll push. This seems to have broken the --disable-optimising argument to configure. With commit 74bdeea4, I get $ ./autogen.sh --disable-optimising $ grep O2 config.make (nothing) With this patch (40911543), I get $ ./autogen.sh --disable-optimising $ grep O2 config.make CONFIG_CFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) CONFIG_CXXFLAGS = -g -O2 -g -pipe $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) My autoconf is version 2.63 Sorry about that, Joe. I could reproduce with Autoconf 2.64 as well. Can you test the latest git to see if it works now? All better now, thanks. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
2009/8/10 Francisco Vila paconet@gmail.com: Hello. The example below shows that the new vertical engine makes dead lyrics contexts to occup space. This did not happen before, IMO the new lyrics should (IF it has enough room) to align with the previous one. I've found that ragged-last-bottom could trigger the bug. At the very end of this real-world file is the line which, when commented out, triggers the problem. http://paconet.org/agnus.ly http://paconet.org/agnus.pdf -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
On 8/10/09 9:14 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Trevor Daniels wrote Monday, August 10, 2009 8:49 AM
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty pnor...@gmail.com:
I wonder why we are seeing different beaming patterns? I think
all of
your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing Carl's last changes to beam-settings.scm.
Aah, thanks for reminding me, Neil. I'd forgotten those. I'll
fish
them out and apply them to my current LP.
With all Carl's mods applied just the expected two inconsistencies
remain:
\relative c'' {
a8 a a16 a a8 a a a a16 a | % wrong, should be ...
a8 a a16[ a a8] a a a[ a16 a] |
a32 a a16 a a a a32 a a16 a a a a32 a a16 a a a a32 a | % wrong,
should be ...
a32[ a a16 a a] a[ a32 a a16 a] a[ a a32 a a16] a a a a32 a
}
The second of these can be fixed (bypassed really) with
\overrideBeamSettings #'Score #'(4 . 4) #'end #'(((1 . 32) . (8 8 8
8)))
which I think is a more acceptable beaming anyway,
but the first is a more fundamental problem which cannot be
fixed by any override which preserves beam breaks at
1/4, 1/2 and 3/4 AFAICS.
OK, so now I can see the differences. Thanks, Trevor.
Can you express in words a rule that describes why
a8 a a16[ a a8] a a a[ a16 a16]
is better than
a8[ a a16 a a8] a8[ a a a16 a]
? It seems to me that something has triggered a desire to break the beam on
the beats, when
a8[ a a a] a[ a a a]
is desired to break at 1/2.
Perhaps if you can explain this, I can figure out what is missing in the
autobeaming algorithms.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
Carl, you wrote Monday, August 10, 2009 10:58 PM
On 8/10/09 9:14 AM, Trevor Daniels t.dani...@treda.co.uk
wrote:
With all Carl's mods applied just the expected two
inconsistencies
remain:
\relative c'' {
a8 a a16 a a8 a a a a16 a | % wrong, should be ...
a8 a a16[ a a8] a a a[ a16 a] |
a32 a a16 a a a a32 a a16 a a a a32 a a16 a a a a32 a | %
wrong,
should be ...
a32[ a a16 a a] a[ a32 a a16 a] a[ a a32 a a16] a a a a32 a
}
The second of these can be fixed (bypassed really) with
\overrideBeamSettings #'Score #'(4 . 4) #'end #'(((1 . 32) . (8 8
8
8)))
which I think is a more acceptable beaming anyway,
but the first is a more fundamental problem which cannot be
fixed by any override which preserves beam breaks at
1/4, 1/2 and 3/4 AFAICS.
OK, so now I can see the differences. Thanks, Trevor.
Can you express in words a rule that describes why
a8 a a16[ a a8] a a a[ a16 a16]
is better than
a8[ a a16 a a8] a8[ a a a16 a]
? It seems to me that something has triggered a desire to break
the beam on
the beats, when
a8[ a a a] a[ a a a]
is desired to break at 1/2.
Perhaps if you can explain this, I can figure out what is missing
in the
autobeaming algorithms.
I can do no better than quote Ross:
1. [in 4/4 time] A beam can never be used
to combine notes of the second and third
beats into a unit.
2. In simple time any beat divided into
more than two parts cannot be connected
to another beat to form a unit.
Apart from these there are no firm rules,
but these explain my beaming. Rule 1 permits
beaming 4 quavers (sorry, 8th notes) together
(and this seems the common practice), as
quavers have only two parts to a beat, but as
soon as two 16th notes are introduced we have
(at least) three parts to a beat, and rule 2
kicks in, forcing beams to be limited to
single beats.
HTH
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Mon, 2009-08-10 at 13:03 +0200, Francisco Vila wrote: Hello. The example below shows that the new vertical engine makes dead lyrics contexts to occup space. This did not happen before, IMO the new lyrics should (IF it has enough room) to align with the previous one. Did this work before (see bug 127)? Anyway, it works for me if I override Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'space = 0 Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'stretchability = 0 If you can verify that it looks ok for non-trivial examples, I'll make that the default. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
OK, I've found a setting that works *pretty well*, with one bad case:
\relative c'' {
\overrideBeamSettings #'Score #'(4 . 4) #'end
#'((* . (1 1 1 1))
((1 . 8) . (4 4)))
a8 a a a a a a a | % OK
\break
a16 a a8 a a
a a16 a a8 a | % OK now, was wrong, should be ...
a16[ a a8] a a
a[ a16 a] a8 a |
\break
a8 a a16 a a8
a a a a16 a | % wrong, should be ...
a8 a a16[ a a8]
a a a[ a16 a] |
\break
a8 a16 a a8 a16 a
a8 a16 a a8 a16 a | % OK now, was wrong, should be ...
a8[ a16 a] a8 a16 a
a8[ a16 a] a8 a16 a |
\break
a32 a a16 a a a a32 a a16 a
a a a32 a a16 a a a a32 a | % OK now, was wrong, should be ...
a32[ a a16 a a] a[ a32 a a16 a]
a[ a a32 a a16] a a a a32 a
}
I think I can fix this by tweaking with the START rule; it appears to me
that what fails in measure 4 above is that the beam should be broken at the
final beat because the beaming in the final beat contains a 1/16 beam, so
the 1/8 rule shouldn't apply. But we don't check for that at the start of
the final beat; we only get that check at the end of the final beat.
I'll do some investigation and see if I can fix that.
But for now, I think this beaming rule for 4/4 time is the best I've seen
yet. What do you think?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New instrument name posititioning in scheme displays instr. name for haraiki'ed staves
2009/8/10 Neil Puttock n.putt...@gmail.com: Heheh, I'm hoping it won't come to that if I can get the existing test to work properly (I'm hopeful making the name longer will work). Well this is rather puzzling: if I fix the bug, `make check' shows the correction with a distance of 1.00 (even without changing shortInstrumentName), whereas testing current master against a baseline of 1ac472 (just before the instrument name patch) doesn't reveal the regression. Can anybody explain what's going on? Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
2009/8/11 Joe Neeman joenee...@gmail.com: On Mon, 2009-08-10 at 13:03 +0200, Francisco Vila wrote: Hello. The example below shows that the new vertical engine makes dead lyrics contexts to occup space. This did not happen before, IMO the new lyrics should (IF it has enough room) to align with the previous one. Did this work before (see bug 127)? My examples worked (and still work) on 2.12 Anyway, it works for me if I override Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'space = 0 Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'stretchability = 0 Yes, but does all this verbosity workaround the bug cleanly? If yes, please make it the default, see below. If you can verify that it looks ok for non-trivial examples, I'll make that the default. Yes, If the Agnus qualifies for a non-trivial example. Verified, thanks Updated http://paconet.org/agnus.ly http://paconet.org/agnus.pdf It looks much better now, except for the footer, when stretched. When it's not stretched, the default stave padding is still not satisfying for me, I hate to say. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
update from the git battlefield
I'm git-weary but still alive. Johannes spent *hours* debugging my problem, and eventually traced it to an undiscovered bug in gitk that only affects Microsoft Windows... So I think I'm back: $ git push --dry-run Everything up-to-date Now I need a break. But man, what a sport that guy is. Hope everyone's well. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
improving layout of ly-grammar.txtlocalhost/
Pushed to git. Also, during this work I was able to improve the backslash handling; I think all of the backslashes are now handled correctly. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
On 8/10/09 5:25 PM, Mark Polesky markpole...@yahoo.com wrote: I'm git-weary but still alive. Johannes spent *hours* debugging my problem, and eventually traced it to an undiscovered bug in gitk that only affects Microsoft Windows... So I think I'm back: $ git push --dry-run Everything up-to-date Woo-hoo! Congratulations! It'll be nice to be doing productive work again, instead of battling somebody else's bugs, won't it? Now I need a break. But man, what a sport that guy is. Yes, we are greatly blessed to have Johannes around on the Lilypond-Devel list. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
On 8/10/09 4:23 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl, you wrote Monday, August 10, 2009 10:58 PM Can you express in words a rule that describes why a8 a a16[ a a8] a a a[ a16 a16] is better than a8[ a a16 a a8] a8[ a a a16 a] I can do no better than quote Ross: 1. [in 4/4 time] A beam can never be used to combine notes of the second and third beats into a unit. 2. In simple time any beat divided into more than two parts cannot be connected to another beat to form a unit. Apart from these there are no firm rules, but these explain my beaming. Rule 1 permits beaming 4 quavers (sorry, 8th notes) together (and this seems the common practice), as quavers have only two parts to a beat, but as soon as two 16th notes are introduced we have (at least) three parts to a beat, and rule 2 kicks in, forcing beams to be limited to single beats. Thanks, Trevor. Now I just need to figure out how to get autobeaming to work properly. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Tue, 2009-08-11 at 01:10 +0200, Francisco Vila wrote: 2009/8/11 Joe Neeman joenee...@gmail.com: On Mon, 2009-08-10 at 13:03 +0200, Francisco Vila wrote: Hello. The example below shows that the new vertical engine makes dead lyrics contexts to occup space. This did not happen before, IMO the new lyrics should (IF it has enough room) to align with the previous one. Did this work before (see bug 127)? My examples worked (and still work) on 2.12 Anyway, it works for me if I override Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'space = 0 Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'stretchability = 0 Yes, but does all this verbosity workaround the bug cleanly? If yes, please make it the default, see below. It's no more verbose than the current defaults; I've just committed it. If you can verify that it looks ok for non-trivial examples, I'll make that the default. Yes, If the Agnus qualifies for a non-trivial example. Verified, thanks Updated http://paconet.org/agnus.ly http://paconet.org/agnus.pdf It looks much better now, except for the footer, when stretched. Is the footer too close to the lyrics? The default value (in the paper block) for bottom-system-spacing is bottom-system-spacing = #'((space . 1) (padding . 1) (min-distance . 0) (stretchability . 5)) Could you try an increased padding value (maybe 2 or 3)? When it's not stretched, the default stave padding is still not satisfying for me, I hate to say. Is it too tight? Try overriding ChoirStaff.StaffGrouper #'between-staff-spacing #'space to something larger (default is 9). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. August 2009 01:10:33 schrieb Francisco Vila: It looks much better now, except for the footer, when stretched. Yes, I also noticed this with my scores: It appears that the space between the last staff and the footer is fixed and will never stretch. If a page is stretched a lot, this makes the last staff appear too far down. My gut feeling is that the space between the footer and the last staff should also be somehow stretched (although maybe not with the same spring constant. When it's not stretched, the default stave padding is still not satisfying for me, I hate to say. Me too. The staves are too close together. 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) iD8DBQFKgLM7TqjEwhXvPN0RAtA2AJ0YgZb2vz8GUUxt2rJOQJrry8cg7ACfeUil kwAALT7y6if4TP0d85J1maA= =EvsV -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Tue, 2009-08-11 at 01:46 +0200, Reinhold Kainhofer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 11. August 2009 00:24:25 schrieb Joe Neeman:
On Mon, 2009-08-10 at 13:03 +0200, Francisco Vila wrote:
Hello. The example below shows that the new vertical engine makes dead
lyrics contexts to occup space. This did not happen before, IMO the
new lyrics should (IF it has enough room) to align with the previous
one.
Did this work before (see bug 127)?
It worked for me with the other file I sent (where I use italic lyrics for
the
cue voice).
Anyway, it works for me if I
override
Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'space = 0
Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'stretchability = 0
Yes, that looks much better.
However, while comparing the old and the new output, without ragged-bottom,
the new output looks much worse:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Eybler_OmnesDeSabaVenient_HV40_Instrument_SSolo.old.pdf
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Eybler_OmnesDeSabaVenient_HV40_Instrument_SSolo.new.pdf
With the uninitialized variables fix, the remaining issues might just be
due to bad default settings (see below). I would appreciate help in
finding good settings because I don't deal with choral or orchestral
scores very often.
- -) For some reason even the header is higher up with the new engine.
Try increasing 'space, 'minimum-distance or 'padding in
top-title-spacing (\paper block).
- -) With the new engine, the lyrics are too far away from the staff. It
seems
that
\layout {
\context {
\Lyrics
\override VerticalAxisGroup #'minimum-Y-extent = #'(0.5 . 0.5)
}
\context {
\Staff
\override VerticalAxisGroup #'minimum-Y-extent = #'(-1. . 3)
}
}
does not have any effect any more.
Y-extents aren't used any more for spacing. You can make the lyrics
closer to the staff by changing
Lyrics.VerticalAxisGroup #'inter-staff-spacing
In particular, try decreasing 'space and 'minimum-distance.
- -) The staves are really crammed together.
This is controlled by the between-system-spacing \paper-block variable
(try increasing 'space).
- -) The cue text (bar 35) seems to be differently aligned in 2.13.x than in
2.12.1. That has probably nothing to do with the vertical layout engine, but
still something that is noticable.
Is it a \mark? If so, its alignment is measured with respect to the bar
line, not the note (and so the tighter horizontal spacing makes it look
further to the right when compared with the note). If it's a TextScript,
I have no idea what's causing the difference.
Thanks for the continued feedback,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Tue, 2009-08-11 at 01:54 +0200, Reinhold Kainhofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. August 2009 01:10:33 schrieb Francisco Vila: It looks much better now, except for the footer, when stretched. Yes, I also noticed this with my scores: It appears that the space between the last staff and the footer is fixed and will never stretch. If a page is stretched a lot, this makes the last staff appear too far down. My gut feeling is that the space between the footer and the last staff should also be somehow stretched (although maybe not with the same spring constant. A minute ago, I suggested increasing 'padding in bottom-system-spacing. Perhaps it would also (or instead?) be a good idea to increase 'space and 'stretchability. Compared with increasing 'padding, this would increase the space to the footer more in stretched scores and less in tight scores. Bear in mind that the 'space in bottom-system-spacing is measured from the margin to the middle line of the bottom staff (not the lyrics). Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB log always goes to linux-x86 ?
GUB make lilypond fails with: building package: freebsd-x86::guile *** Stage: download (guile, freebsd-x86) *** Stage: untar (guile, freebsd-x86) *** Stage: patch (guile, freebsd-x86) *** Stage: autoupdate (guile, freebsd-x86) *** Stage: configure (guile, freebsd-x86) *** Stage: compile (guile, freebsd-x86) *** Stage: install (guile, freebsd-x86) Command barfed: cd /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7 make LDFLAGS='-Wl,-rpath -Wl,\$$ORIGIN/../lib' DESTDIR=/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root install Tail of target/linux-x86/log/build.log make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7/srfi' make: *** [install-recursive] Error 1 Command barfed: cd /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7 make LDFLAGS='-Wl,-rpath -Wl,\$$ORIGIN/../lib' DESTDIR=/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root install Tail of target/linux-x86/log/build.log *** Failed target: freebsd-x86::guile No, that's not a typo -- the attempt to build guile on freebsd ends up writing to target-linux-x86/log (??) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
2009/8/11 Joe Neeman joenee...@gmail.com: Is the footer too close to the lyrics? The default value (in the paper block) for bottom-system-spacing is bottom-system-spacing = #'((space . 1) (padding . 1) (min-distance . 0) (stretchability . 5)) Could you try an increased padding value (maybe 2 or 3)? 3 is fine; 2 is too close IMO When it's not stretched, the default stave padding is still not satisfying for me, I hate to say. Is it too tight? Try overriding ChoirStaff.StaffGrouper #'between-staff-spacing #'space to something larger (default is 9). This seems to be a dangerous variable: 9 is not enough; more than 9 makes systems to be closer than staves in a system, which one should always avoid. In my example, possibly staves should benefit from a hard padding on top, say 4 spaces or so. Otherwise lyrics collide with the next staff. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. August 2009 02:04:28 schrieb Joe Neeman: On Tue, 2009-08-11 at 01:46 +0200, Reinhold Kainhofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. August 2009 00:24:25 schrieb Joe Neeman: On Mon, 2009-08-10 at 13:03 +0200, Francisco Vila wrote: Hello. The example below shows that the new vertical engine makes dead lyrics contexts to occup space. This did not happen before, IMO the new lyrics should (IF it has enough room) to align with the previous one. Did this work before (see bug 127)? It worked for me with the other file I sent (where I use italic lyrics for the cue voice). Anyway, it works for me if I override Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'space = 0 Lyrics.VerticalAxisGroup #'inter-loose-line-spacing #'stretchability = 0 Yes, that looks much better. However, while comparing the old and the new output, without ragged-bottom, the new output looks much worse: http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Eybler_ OmnesDeSabaVenient_HV40_Instrument_SSolo.old.pdf http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Eybler_ OmnesDeSabaVenient_HV40_Instrument_SSolo.new.pdf With the uninitialized variables fix, the remaining issues might just be due to bad default settings (see below). I would appreciate help in finding good settings because I don't deal with choral or orchestral scores very often. Okay, I'll see whether I can find some time to tweak all the variables (I'm currently preparing some Urtext editions of Eybler works, then I need to fix this texi2html issue with translated file names, etc). Do you have a list of all variables that affect the vertical layout now? That would be quite helpful for the doc writers, too. Y-extents aren't used any more for spacing. You can make the lyrics closer to the staff by changing Lyrics.VerticalAxisGroup #'inter-staff-spacing In particular, try decreasing 'space and 'minimum-distance. Ah, that name is really more intuitive than the old one! - -) The staves are really crammed together. This is controlled by the between-system-spacing \paper-block variable (try increasing 'space). That is set to a low variable so that scores with ragged-bottom=#f can have a small staff distance. It seems that the vertical layout will now always use the minimal distance between staves unless stretching is enabled, right? - -) The cue text (bar 35) seems to be differently aligned in 2.13.x than in 2.12.1. That has probably nothing to do with the vertical layout engine, but still something that is noticable. Is it a \mark? If so, its alignment is measured with respect to the bar line, not the note (and so the tighter horizontal spacing makes it look further to the right when compared with the note). If it's a TextScript, I have no idea what's causing the difference. It's an InstrumentSwitch object, which is the grob created when you \set Voice.instrumentCueName = Solo 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) iD8DBQFKgLkoTqjEwhXvPN0RAibyAJ9geLT1MCejkvUy+HQ6IeqUZ/yBIQCgsTZH tgWLyPd7WwyDWJ7JF8BDPSk= =TKcY -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
2009/8/11 Joe Neeman joenee...@gmail.com: - -) The staves are really crammed together. This is controlled by the between-system-spacing \paper-block variable (try increasing 'space). Let's be careful about not mixing staves and systems in our wording. I appreciate that staves nearly collide with the lyrics above, inside a system. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB log always goes to linux-x86 ?
On Mon, Aug 10, 2009 at 05:08:51PM -0700, Graham Percival wrote: GUB make lilypond fails with: building package: freebsd-x86::guile *** Stage: download (guile, freebsd-x86) *** Stage: untar (guile, freebsd-x86) *** Stage: patch (guile, freebsd-x86) *** Stage: autoupdate (guile, freebsd-x86) *** Stage: configure (guile, freebsd-x86) *** Stage: compile (guile, freebsd-x86) *** Stage: install (guile, freebsd-x86) Command barfed: cd /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7 make LDFLAGS='-Wl,-rpath -Wl,\$$ORIGIN/../lib' DESTDIR=/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root install Tail of target/linux-x86/log/build.log make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7/srfi' make: *** [install-recursive] Error 1 Command barfed: cd /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7 make LDFLAGS='-Wl,-rpath -Wl,\$$ORIGIN/../lib' DESTDIR=/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root install Tail of target/linux-x86/log/build.log *** Failed target: freebsd-x86::guile Since Jan recently condensed the console output for errors, you might find the reason why this failed in target/linux-x86/log/build.log. I suspect rm -rf target/freebsd-x86/packages/guile* might solve your problem. No, that's not a typo -- the attempt to build guile on freebsd ends up writing to target-linux-x86/log (??) Hasn't this always been the case? When I run `make lilypond', the log file is linux-64/log/build.log (since I am running a 64-bit OS). But when I run bin/gub darwin-ppc::lilypond the log file is darwin-ppc/log/build.log. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB log always goes to linux-x86 ?
On Mon, Aug 10, 2009 at 05:27:15PM -0700, Patrick McCarty wrote: On Mon, Aug 10, 2009 at 05:08:51PM -0700, Graham Percival wrote: Tail of target/linux-x86/log/build.log Tail of target/linux-x86/log/build.log rm -rf target/freebsd-x86/packages/guile* I tried that, and src/guile/, and status/guile*, and install/guile* The first erro rin target/linux-x86/log/build.log is this: test -z /usr/lib || /home/lilypond/bin/mkdir -p /home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la '/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib' libtool: install: error: cannot install `libguile-srfi-srfi-1-v-3.la' to a directory not ending in /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7/srfi/.libs make[3]: *** [install-libLTLIBRARIES] Error 1 No, that's not a typo -- the attempt to build guile on freebsd ends up writing to target-linux-x86/log (??) Hasn't this always been the case? Hmm. Maybe? I haven't noticed it before. When I run `make lilypond', the log file is linux-64/log/build.log (since I am running a 64-bit OS). But when I run bin/gub darwin-ppc::lilypond the log file is darwin-ppc/log/build.log. Well, make lilypond compiles all the versions. It's like running bin/gub darwin-ppc::lilypond; bin/gub darwin-x86::lilypond; bin/gub freebsd-x86::lilypond; ...etc I would have expected the build for each OS/arch to occur in their own log files. It's no big deal if they're all in linux-x86 (since that's the host OS), but it just seemed a bit weird to me. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Tue, 2009-08-11 at 02:19 +0200, Reinhold Kainhofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. August 2009 02:04:28 schrieb Joe Neeman: With the uninitialized variables fix, the remaining issues might just be due to bad default settings (see below). I would appreciate help in finding good settings because I don't deal with choral or orchestral scores very often. Okay, I'll see whether I can find some time to tweak all the variables (I'm currently preparing some Urtext editions of Eybler works, then I need to fix this texi2html issue with translated file names, etc). Do you have a list of all variables that affect the vertical layout now? That would be quite helpful for the doc writers, too. I do intend to write some docs (once I've finished dealing with my TODO list), but in the absence of docs, here's a list of spacing variables. They all take alists with the same entries (space, minimum-distance, padding and stretchability, which are explained in scm/define-grob-properties.scm under next-staff-spacing). paper block variables: top-system-spacing top-title-spacing between-system-spacing bottom-system-spacing after-title-spacing before-title-spacing between-title-spacing Grob properties: VerticalAxisGroup in the staff context, 'next-staff-spacing defaults to a callback that gets its return value from a StaffGrouper grob in a higher context (see below). If there is no StaffGrouper grob then 'next-staff-spacing falls back on 'default-next-staff-spacing the StaffGrouper grob lives, by default, in PianoStaff, GrandStaff and ChoirStaff. Its properties are 'between-staff-spacing 'after-last-staff-spacing Properties for unspaced lines: you mark a line as unspaced by setting VerticalAxisGroup #'staff-affinity. Unspaced lines don't participate in the initial spacing problem; we make sure to reserve a minimum amount of space for them, and they are distributed after the position of the staves has already been determined 'inter-staff-spacing (controls the spacing to the staff for which the unspaced line has affinity. For example, the spacing from a lyrics line to the staff above it) 'inter-loose-line-spacing (controls the spacing to the nearest unspaced line in the direction of this line's staff-affinity. For example, changing this property on the second line of lyrics will affect its spacing to the first line of lyrics; see input/regression/page-spacing-loose-lines-after.ly). There is currently no way to specify the space from a line with staff-affinity UP and the staff below it (it's on my TODO). - -) The staves are really crammed together. This is controlled by the between-system-spacing \paper-block variable (try increasing 'space). That is set to a low variable so that scores with ragged-bottom=#f can have a small staff distance. It seems that the vertical layout will now always use the minimal distance between staves unless stretching is enabled, right? When a page is ragged, the distance between staves is the larger of - 'space - 'minimum-distance - 'padding + (the smallest amount to prevent overlap) - -) The cue text (bar 35) seems to be differently aligned in 2.13.x than in 2.12.1. That has probably nothing to do with the vertical layout engine, but still something that is noticable. Is it a \mark? If so, its alignment is measured with respect to the bar line, not the note (and so the tighter horizontal spacing makes it look further to the right when compared with the note). If it's a TextScript, I have no idea what's causing the difference. It's an InstrumentSwitch object, which is the grob created when you \set Voice.instrumentCueName = Solo Then I don't know, because InstrumentSwitch should be aligned with the note. If you can isolate a minimal example, I'd say that this is a bug. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dead lyrics context still occupies vertical space
On Tue, 2009-08-11 at 02:17 +0200, Francisco Vila wrote:
2009/8/11 Joe Neeman joenee...@gmail.com:
Is the footer too close to the lyrics? The default value (in the paper
block) for bottom-system-spacing is
bottom-system-spacing = #'((space . 1) (padding . 1) (min-distance . 0)
(stretchability . 5))
Could you try an increased padding value (maybe 2 or 3)?
3 is fine; 2 is too close IMO
Thanks, could you also try increasing 'space? The problem (which
occurred to me after sending the last email) with just doing padding is
that it affects tightly spaced scores as well as loosely spaced scores.
When it's not stretched, the default stave padding is still not
satisfying for me, I hate to say.
Is it too tight? Try overriding ChoirStaff.StaffGrouper
#'between-staff-spacing #'space to something larger (default is 9).
This seems to be a dangerous variable: 9 is not enough; more than 9
makes systems to be closer than staves in a system, which one should
always avoid.
Right, you need to keep StaffGrouper #'between-staff-spacing and
\paper { between-system-spacing } balanced (along with some other
variables too). But if you can find a good default for
between-staff-spacing, I can just bump up everything by a corresponding
amount.
In my example, possibly staves should benefit from a hard padding on
top, say 4 spaces or so. Otherwise lyrics collide with the next staff.
There's currently no way to specify the spacing between a lyrics line
with staff-affinity UP and the line below it, but it's on my TODO list.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
omf in documentation
The main doc pages all contain stuff like: @c don't remove this comment. @ignore @omfcreator Han-Wen Nienhuys, Jan Nieuwenhuizen and Graham Percival @omfdescription Learning Manual of the LilyPond music engraving system @omftype program usage @omfcategory Applications|Publishing @omflanguage English @end ignore Are these for the Open Source Metadata Framework? http://www.ibiblio.org/osrt/omf/ Are they actually being used? If not, can I remove them? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup command `parenthesize'
Neil Puttock n.putt...@gmail.com writes:
Very shapely parentheses. :)
Thank you, and thanks for the comments! Here are two addenda
to the original patch that make the improvements you suggested:
commit 79259e82dea04bec0090152268ac8ec3ad12ff1f
Author: Thomas Morgan t...@ziiuu.com
Date: Mon Jul 27 20:22:03 2009 -0400
Make `parenthesize-stencil' a public procedure.
In same procedure, use constant `RIGHT' instead of 1.
diff --git a/scm/stencil.scm b/scm/stencil.scm
index 5b83631..c35d45e 100644
--- a/scm/stencil.scm
+++ b/scm/stencil.scm
@@ -136,16 +136,16 @@ the more angular the shape of the parenthesis.
x-extent
y-extent)))
-(define (parenthesize-stencil
-stencil half-thickness width angularity padding)
+(define-public (parenthesize-stencil
+ stencil half-thickness width angularity padding)
Add parentheses around @var{stencil}, returning a new stencil.
(let* ((y-extent (ly:stencil-extent stencil Y))
(lp (make-parenthesis-stencil
y-extent half-thickness (- width) angularity))
(rp (make-parenthesis-stencil
y-extent half-thickness width angularity)))
-(set! stencil (ly:stencil-combine-at-edge lp X 1 stencil padding))
-(set! stencil (ly:stencil-combine-at-edge stencil X 1 rp padding))
+(set! stencil (ly:stencil-combine-at-edge lp X RIGHT stencil padding))
+(set! stencil (ly:stencil-combine-at-edge stencil X RIGHT rp padding))
stencil))
(define-public (make-line-stencil width startx starty endx endy)
commit a4b20dfb40475332e7d9fdcdf347c1d559412102
Author: Thomas Morgan t...@ziiuu.com
Date: Mon Jul 27 20:48:02 2009 -0400
Define property defaults in markup command `parenthesize'.
Do not make `angularity' a grob property: remove it from
`lily/script-interface.cc', `scm/define-grob-properties.scm',
and `scm/define-grobs.scm'.
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index 6bdd069..59737b5 100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -112,7 +112,6 @@ 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 0c13f82..ee75ee7 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -38,8 +38,6 @@ 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 f829a33..e511f24 100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -1889,7 +1889,6 @@
(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 bbc2aec..10cc7fe 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -3025,7 +3025,11 @@ Draw vertical brackets around @var{arg}.
(define-builtin-markup-command (parenthesize layout props arg)
(markup?)
graphic
- ()
+ ((angularity 0)
+ (padding)
+ (size 1)
+ (thickness 1)
+ (width 0.25))
@cindex placing parentheses around text
@@ -3043,16 +3047,17 @@ a column containing several lines of text.
}
@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))
+(scaled-width (* size width))
+(scaled-thickness
+ (* (chain-assoc-get 'line-thickness props 0.1)
+thickness))
+(half-thickness
+ (min (* size 0.5 scaled-thickness)
+ (* (/ 4 3.0) scaled-width)))
(padding (chain-assoc-get 'padding props half-thickness)))
(parenthesize-stencil
- markup half-thickness width angularity padding)))
+ markup half-thickness scaled-width angularity padding)))
+
;; Delayed markup evaluation
Re: omf in documentation
On Mon, Aug 10, 2009 at 10:19 PM, Graham Percivalgra...@percival-music.ca wrote: The main doc pages all contain stuff like: @c don't remove this comment. @ignore @omfcreator Han-Wen Nienhuys, Jan Nieuwenhuizen and Graham Percival @omfdescription Learning Manual of the LilyPond music engraving system @omftype program usage @omfcategory Applications|Publishing @omflanguage English @end ignore Are these for the Open Source Metadata Framework? http://www.ibiblio.org/osrt/omf/ Yes. Are they actually being used? If not, can I remove them? I can't remember. There is a script to generate the omf files, and the theory was that distributors could install them appropriately, so the lily docs would show up in centralized help systems. I think that has never happened, though. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB log always goes to linux-x86 ?
On Mon, Aug 10, 2009 at 05:35:15PM -0700, Graham Percival wrote: On Mon, Aug 10, 2009 at 05:27:15PM -0700, Patrick McCarty wrote: On Mon, Aug 10, 2009 at 05:08:51PM -0700, Graham Percival wrote: Tail of target/linux-x86/log/build.log Tail of target/linux-x86/log/build.log rm -rf target/freebsd-x86/packages/guile* I tried that, and src/guile/, and status/guile*, and install/guile* The first erro rin target/linux-x86/log/build.log is this: test -z /usr/lib || /home/lilypond/bin/mkdir -p /home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la '/home/lilypond/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib' libtool: install: error: cannot install `libguile-srfi-srfi-1-v-3.la' to a directory not ending in /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7/srfi/.libs make[3]: *** [install-libLTLIBRARIES] Error 1 I can reproduce this, but I am unable to discover a fix. However, attached is a diff for two libtool shell traces. The first is successful (libguile.la), but the second is not (libguile-srfi-srfi-1-v-3.la). Line 124 shows that a value is assigned to relink_command in libguile-srfi-srfi-1-v-3.la, but not for libguile.la. HTH, Patrick --- succeed.log 2009-08-10 20:51:07.280939498 -0700 +++ fail.log2009-08-10 20:51:13.610915518 -0700 @@ -274,24 +274,24 @@ 1089+ opt_debug=: 1094+ exec_cmd= 1190+ case $1 in -1215+ test 5 -gt 0 +1215+ test 8 -gt 0 1216+ opt=--mode=install 1217+ shift 1219+ case $opt in 1279+ func_opt_split --mode=install 622+ func_opt_split_opt=--mode 623+ func_opt_split_arg=install -1280+ set dummy --mode install /bin/install -c libguile.la /home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib +1280+ set dummy --mode install /bin/install -c libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la /home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib 1281+ shift -1215+ test 6 -gt 0 +1215+ test 9 -gt 0 1216+ opt=--mode 1217+ shift 1219+ case $opt in -1237+ test 5 -eq 0 +1237+ test 8 -eq 0 1238+ case $1 in 1256+ mode=install 1257+ shift -1215+ test 4 -gt 0 +1215+ test 7 -gt 0 1216+ opt=/bin/install 1217+ shift 1219+ case $opt in @@ -316,7 +316,7 @@ 2254+ test install = execute 2334+ test install = finish 2773+ test install = install -2773+ func_mode_install -c libguile.la /home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib +2773+ func_mode_install -c libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la /home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib 2340+ : 2343+ test /bin/install = /bin/sh 2343+ test /bin/install = /bin/sh @@ -350,16 +350,31 @@ 2371+ test -n '' 2377+ case $arg in 2396+ test -n '' -2399+ dest=libguile.la +2399+ dest=libguile-srfi-srfi-1-v-3.la 2400+ continue 2369+ for arg in '$@' -2371+ test -n libguile.la -2372+ files=' libguile.la' +2371+ test -n libguile-srfi-srfi-1-v-3.la +2372+ files=' libguile-srfi-srfi-1-v-3.la' +2373+ dest=libguile-srfi-srfi-4-v-3.la +2374+ continue +2369+ for arg in '$@' +2371+ test -n libguile-srfi-srfi-4-v-3.la +2372+ files=' libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la' +2373+ dest=libguile-srfi-srfi-13-14-v-3.la +2374+ continue +2369+ for arg in '$@' +2371+ test -n libguile-srfi-srfi-13-14-v-3.la +2372+ files=' libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la' +2373+ dest=libguile-srfi-srfi-60-v-2.la +2374+ continue +2369+ for arg in '$@' +2371+ test -n libguile-srfi-srfi-60-v-2.la +2372+ files=' libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la' 2373+ dest=/home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib 2374+ continue 2410+ test -z '/bin/install -c' 2413+ test -n '' -2416+ test -z ' libguile.la' +2416+ test -z ' libguile-srfi-srfi-1-v-3.la libguile-srfi-srfi-4-v-3.la libguile-srfi-srfi-13-14-v-3.la libguile-srfi-srfi-60-v-2.la' 2425+ func_stripname '' / /home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib 614+ func_stripname_result=/home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib 615+ func_stripname_result=/home/pnorcks/git/gub/target/freebsd-x86/install/guile-1.8.7-root/usr/lib @@ -377,10 +392,10 @@ 2463+ current_libdirs= 2464+ for file in '$files' 2467+ case $file in -2475+ func_lalib_unsafe_p libguile.la +2475+ func_lalib_unsafe_p libguile-srfi-srfi-1-v-3.la 1400+ lalib_p=no -1401+ test -f libguile.la -1401+ test -r libguile.la +1401+ test -f libguile-srfi-srfi-1-v-3.la +1401+ test -r libguile-srfi-srfi-1-v-3.la 1401+ exec 1402+ for lalib_p_l in 1 2
Re: improving layout of ly-grammar.txtlocalhost/
Pushed to git. Thanks a lot! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
