Future work on Music Glossary
Hi Kurt Graham has asked me to take over his role in updating the LilyPond Music Glossary - i.e. prompting for editorial changes to be made, receiving changes and updating the files in git. Not being musically competent, I do not intend to make any editorial changes myself. There are a number of changes and additions waiting to be made. As you have made all the editorial changes in the recent past could you please let me know a) whether you are willing to continue actively, b) if you are, whether you would prefer to remain exclusive English editor, or if you would like help. Then, regarding the mechanics:- c) Are you git-enabled, i.e. able to fetch files from Savannah? d) If you are, are you able to create patches? I notice that some terms have not been translated into all the languages. How is this translation triggered? Do we need to recruit help? Finally, what became of the offer to add Hungarian to the glossary? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Grob type (and other metadata) in point-and-click url
Would it be theoretically possible to include other metadata in the point-and-click url besides the input file position? I'm looking at: (define (grob-cause offset grob I'm not sure, how much information is included in that grob object. If a text script for example would have the information that it is a Voice.TextScript, or that the notehead it is coming from a note event it would allow powerful finishing tools, like extra-offset, adding transposition in the editors. What do you think? Thanks, Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
Le samedi 18 juillet 2009 à 03:31 -0700, Graham Percival a écrit : > Good point. I had a vague notion that having them there might > make it easier to produce the top-level *.txt files, but I > honestly would rather have them moved. If you're happy with that, > then by all means let's move them. Yes, the distinction will be made in the Manuals page instead of the directory structure, which is both better for users and not more complicated for developers and contributors. > compile.itexi would go in devel. (note the itexi) > I guess we'd need an "install.texi" somewhere, just to produce the > INSTALL.txt document. Since compile.itexi is mainly intended as > part of the CG, it wouldn't have a @top node. Exactly. > I propose that we make Changes a standalone document: > Documentation/changes.tely > we don't need a subdir for this, since it should only just be the > single file. Agreed. > Yes, with the proviso that "snippet" might require extra trickery. > (i.e. Documentation/snippet/lsr, Documentation/snippet/new/, etc) I'd like to move - input/lsr to Documentation/snippets (so that this directory actually contains some real material) - input/new to Documentation/snippets/new - input/texidocs to Documentation/snippets/texidocs > Oh wait: authors doesn't get its own manual. That will move into > web.tely, as part of community.itexi. That's noted. > And we /might/ want to rename "devel" to "contributors", just to > keep it close to the CG name. The original devel/ dir was just to > oppose user/. OK. > Up to you. I mean, the simplification would also make it *easier* > to switch, so maybe you want to do it sooner, just for fun. :) I don't think it would be so easier. It's so much work to switch to another build system for LilyPond and I already have other time-consuming hobbies, e.g. making our Python scripts that manipulate Texinfo more reliable by using a Texinfo parser. > > Unless there are objections, I'll start applying this plan by moving the > > three manuals and snippets very soon. > > I think we have more than three manuals, but other than that, agreed. I meant LM NR and AU. As there might be some places to decide for snippets, I'm starting right now with three main manuals and the CG, including splitting out the essay. 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: Grob type (and other metadata) in point-and-click url
On Mon, Jul 20, 2009 at 11:05:27AM +0200, Bertalan Fodor (LilyPondTool) wrote: > Would it be theoretically possible to include other metadata in the > point-and-click url besides the input file position? > I'm looking at: > > (define (grob-cause offset grob > > I'm not sure, how much information is included in that grob object. > > If a text script for example would have the information that it is a > Voice.TextScript, or that the notehead it is coming from a note event it > would allow powerful finishing tools, like extra-offset, adding > transposition in the editors. Yes, you can get more information from grob-cause. A quick inspection with GDB reveals this cause for a NoteHead grob (indented for easier reading) in a particular file I have: (cause . #) (elements) (duration . #) (pitch . #) (origin . #)) ((display-methods #) (name . NoteEvent) (types general-music event note-event rhythmic-event melodic-event))>) (length . #) (elements) (duration . #) (pitch . #) (origin . #)) ((class . note-event))>) Hopefully that will give you some ideas about using grob-cause. :-) -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translation review requests -- texi2html's handling of @ignore blocks
On wo, 2009-07-15 at 15:16 +0200, Reinhold Kainhofer wrote: > Actually, @ignore blocks are not supposed to be processed at all, that's why > they are called ignore. However, @c comments would make sense to include as > comments in the html code. You might ask Patrice (on the texi2html mailing > list) about this feature. He has always been very forthcoming and usually > implemented things within hours. I'm not on that list, would you like to ask for me? Jan. -- Jan Nieuwenhuizen | 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
Converting texinfo comments to HTML comments
Hi Patrice, In our lilypond docs, we have several texinfo comments, most notably the git revision of the texinfo document, which would make sense to be converted into html comments (so that we can e.g. determine from which revision a document was compiled, which is particularly useful for translators). I've taken a quick look at the texi2html code, but I couldn't find the spot where @c lines are ignored. Can you think of an easy way to convert texinfo comments into html comments? Thanks, Reinhold PS: Sometimes it might even make sense to convert @ignore...@end ignore blocks to html comments. Is there a way for this, too? (Actually, our git revisions are currently inside an @ignore block, so if it's not possible to convert ignore blocks to comments, then we'll have to change a lot of files...) -- -- 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3: Infinite loop in patch stage for linux-x86::linux-headers
On vr, 2009-07-17 at 21:50 -0700, Patrick McCarty wrote: > I have no idea what's going on, but the build.log is attached. Can you try executing the command that triggers this by hand, possibly with some -x debugging to see what's going on, ie do something like cd /home/pnorcks/git/gub/target/linux-x86/src/linux-headers-2.4.34 yes yes | make ARCH=i386 oldconfig CONFIG_SHELL='/bin/bash -x' I do not see this problem, but someone on #denemo (don't remember) has. Do you have /dev/mtd*? Jan. -- Jan Nieuwenhuizen | 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: translation review requests -- texi2html's handling of @ignore blocks
Le 15/07/2009 15:16, Reinhold Kainhofer disait : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 13. Juli 2009 10:57:23 schrieb Jan Nieuwenhuizen: Just talking to xorius on #lilypond about where the latest french translations live for review... I realised it would be nice if texi2html would copy any @ignore @end ignore blocks to html comments so that you can easily check if the website is up to date. Actually, @ignore blocks are not supposed to be processed at all, that's why they are called ignore. However, @c comments would make sense to include as comments in the html code. You might ask Patrice (on the texi2html mailing list) about this feature. He has always been very forthcoming and usually implemented things within hours. Cheers, Reinhold - -- But there are many @c comments that appear in many files as well. I don't know anything in neither texinfo or texi2html but would it be possible to create a specific macro for this purpose? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Translation and releasing
Hi Mr release-master and his fellow workers, Please wait a couple of days before delivering a new release, since I'm almost (99% plus a proof-reading) of a complete reviewing of the French version of the learning manual. Thanks in advance for those so called frog-eaters... Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3: Infinite loop in patch stage for linux-x86::linux-headers
On Mon, Jul 20, 2009 at 03:09:19PM +0200, Jan Nieuwenhuizen wrote: > On vr, 2009-07-17 at 21:50 -0700, Patrick McCarty wrote: > > > I have no idea what's going on, but the build.log is attached. > > Can you try executing the command that triggers this by hand, > possibly with some -x debugging to see what's going on, ie > do something like > > > cd /home/pnorcks/git/gub/target/linux-x86/src/linux-headers-2.4.34 > yes yes | make ARCH=i386 oldconfig CONFIG_SHELL='/bin/bash -x' > > I do not see this problem, but someone on #denemo (don't remember) has. > Do you have /dev/mtd*? No, I don't have any items that start with "mtd" in /dev. However, I believe I've come across a bug in Bash 4.0-024. From the shell tracing I've done, this simple command sequence demonstrates the problem: bash-4.0$ cat test.sh #!/bin/sh echo Hello bash-4.0$ . test.sh Hello bash-4.0$ sh sh-4.0$ . test.sh sh: .: test.sh: file not found This is why I'm getting the error message near the top of my log: scripts/Configure: line 551: .: .config-is-not.12306: file not found On my system, /bin/sh is just a symlink to /bin/bash. This is a bug, right? Or could it be a problem with my distro's configuration (almost vanilla, I think): http://repos.archlinux.org/viewvc.cgi/bash/repos/core-x86_64/ Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
On 7/17/09 10:16 AM, "Marc Hohl" wrote:
Carl Sorensen schrieb:
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
I prefer to offer both variants.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
Yes, I had that before, but I decided to remove the plural s, because
in chord constructs, it works only on the next note, and in normal
contexts,
c d \deadNote e f
influences only the e (\deadNotes would imply to influence e and f, in
my opinion).
When one uses { }, \deadNote works on a group of notes, so the meaning here
is clear. So personnally, I wouldn't change it ...
Thinking of similar functions, like \relative and \harmonic, perhaps we
should just name the function to \dead. Then we'd have
4 or \dead {c d e f g a b}
This also brings more distinction between \deadNotesOn and \dead; one of my
concerns was potential confusion between \deadNote and \deadNotesOn. What
do you think?
Hm, sounds kind of morbid to me, calling a note "dead", but since
I am not a native english speaker, I cannot judge this from a neutral
point of view.
Do you think that there will arise big problems with these commands?
I think \deadNotesOn and \deadNote are rather self-explanatory, so I
don't believe to confuse potential users.
Marc
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Marc Hohl wrote: > Hm, sounds kind of morbid to me, calling a note "dead", but since > I am not a native english speaker, I cannot judge this from a neutral > point of view. > Do you think that there will arise big problems with these commands? > I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't > believe to confuse potential users. I prefer "muted" rather than "dead". Though, the LilyPond internals can get kind of violent, especially with the Hara_kiri_engraver, and ly:grob-suicide! (whose docstring simply says "Kill grob"). I would rule that more as a homicide. By the way, I killed a grob once, just to watch him die. - Mark ps. joking aside, I think "muted" is alot better. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/20/09 3:09 PM, "Mark Polesky" wrote:
>
>
> Marc Hohl wrote:
>> Hm, sounds kind of morbid to me, calling a note "dead", but since
>> I am not a native english speaker, I cannot judge this from a neutral
>> point of view.
>> Do you think that there will arise big problems with these commands?
>> I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't
>> believe to confuse potential users.
>
> I prefer "muted" rather than "dead". Though, the LilyPond internals
> can get kind of violent, especially with the Hara_kiri_engraver, and
> ly:grob-suicide! (whose docstring simply says "Kill grob"). I would
> rule that more as a homicide. By the way, I killed a grob once, just
> to watch him die.
grobicide, not homicide, I think! :)
>
> - Mark
> ps. joking aside, I think "muted" is alot better.
>
So perhaps we have
4
\muted{ c d e f g}
{
\mutedNotesOn
c d e f g
\mutedNotesOff
c d e f g
}
Or maybe it becomes
{
\mutedOn
c d e f
\mutedOff
c d e f
}
I think I prefer this to \deadNote, \deadNotesOn, \deadNotesOff.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
2009/7/19 Mark Polesky :
> I attached the updated patch. Okay to apply?
Nearly there...
+ (note-columns ,ly:grob-array? "A list of @code{NoteColumn} grobs.")
"An array of @code{NoteColumn} grobs.")
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3: Infinite loop in patch stage for linux-x86::linux-headers
On Mon, Jul 20, 2009 at 01:41:18PM -0700, Patrick McCarty wrote:
> On Mon, Jul 20, 2009 at 03:09:19PM +0200, Jan Nieuwenhuizen wrote:
> > On vr, 2009-07-17 at 21:50 -0700, Patrick McCarty wrote:
> >
> > > I have no idea what's going on, but the build.log is attached.
> >
> > Can you try executing the command that triggers this by hand,
> > possibly with some -x debugging to see what's going on, ie
> > do something like
> >
> >
> > cd /home/pnorcks/git/gub/target/linux-x86/src/linux-headers-2.4.34
> > yes yes | make ARCH=i386 oldconfig CONFIG_SHELL='/bin/bash -x'
> >
> > I do not see this problem, but someone on #denemo (don't remember) has.
> > Do you have /dev/mtd*?
>
> No, I don't have any items that start with "mtd" in /dev.
>
> However, I believe I've come across a bug in Bash 4.0-024. From the
> shell tracing I've done, this simple command sequence demonstrates the
> problem:
>
> bash-4.0$ cat test.sh
> #!/bin/sh
> echo Hello
>
> bash-4.0$ . test.sh
> Hello
> bash-4.0$ sh
> sh-4.0$ . test.sh
> sh: .: test.sh: file not found
>
>
> This is why I'm getting the error message near the top of my log:
>
> scripts/Configure: line 551: .: .config-is-not.12306: file not found
As a followup, this is a situation where Bash 4.0 is more
POSIX-compliant than Bash 3.2.
See the bug report I posted, and the followup:
http://bugs.archlinux.org/task/15606
The attached patch fixes the problem.
Thanks,
Patrick
>From 978efa7c2b91699186db3de477b47040444731af Mon Sep 17 00:00:00 2001
From: Patrick McCarty
Date: Mon, 20 Jul 2009 15:20:06 -0700
Subject: [PATCH] Fix a compatibility issue with Bash 4.0
---
gub/specs/linux-headers.py |1 +
patches/linux-headers-2.4.34-posix-fix.patch | 12
2 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 patches/linux-headers-2.4.34-posix-fix.patch
diff --git a/gub/specs/linux-headers.py b/gub/specs/linux-headers.py
index 2e07baf..345f469 100644
--- a/gub/specs/linux-headers.py
+++ b/gub/specs/linux-headers.py
@@ -12,6 +12,7 @@ class Linux_headers (build.BinaryBuild, build.SdkBuild):
return ['']
def patch (self):
self.system ('''
+cd %(srcdir)s && patch -p1 < %(patchdir)s/linux-headers-2.4.34-posix-fix.patch
cd %(srcdir)s && yes yes | make ARCH=%(package_arch)s oldconfig symlinks
include/linux/version.h
#cd %(srcdir)s && yes yes | make ARCH=i386 oldconfig
#cd %(srcdir)s && make ARCH=%(package_arch)s symlinks include/linux/version.h
diff --git a/patches/linux-headers-2.4.34-posix-fix.patch
b/patches/linux-headers-2.4.34-posix-fix.patch
new file mode 100644
index 000..07a56b8
--- /dev/null
+++ b/patches/linux-headers-2.4.34-posix-fix.patch
@@ -0,0 +1,12 @@
+diff -ru linux-2.4.34/scripts/Configure linux-2.4.34-2/scripts/Configure
+--- linux-2.4.34/scripts/Configure 2006-12-23 12:34:20.0 -0800
linux-2.4.34-2/scripts/Configure 2009-07-20 15:14:58.506858922 -0700
+@@ -548,7 +548,7 @@
+ echo "#"
+ . $DEFAULTS
+ sed -e 's/# \(CONFIG_[^ ]*\) is not.*/\1=n/' <$DEFAULTS >.config-is-not.$$
+- . .config-is-not.$$
++ . ./.config-is-not.$$
+ rm .config-is-not.$$
+ else
+ echo "#"
--
1.6.3.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/20/09 3:09 PM, "Mark Polesky" wrote: > > > Marc Hohl wrote: >> Hm, sounds kind of morbid to me, calling a note "dead", but since >> I am not a native english speaker, I cannot judge this from a neutral >> point of view. >> Do you think that there will arise big problems with these commands? >> I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't >> believe to confuse potential users. > > I prefer "muted" rather than "dead". Though, the LilyPond internals > can get kind of violent, especially with the Hara_kiri_engraver, and > ly:grob-suicide! (whose docstring simply says "Kill grob"). I would > rule that more as a homicide. By the way, I killed a grob once, just > to watch him die. > > - Mark > ps. joking aside, I think "muted" is alot better. After my previous post, I thought that the term in LilyPond ought to reflect the most appropriate musical usage term, rather than what I think is the best non-musical english term. So I did a search for "dead note" and found that it is widely accepted in the rock guitar world (which is the largest market for tablatures, I think). The Virginia Tech Multimedia Music Dictionary http://www.music.vt.edu/musicdictionary/ has an entry for "dead note" that consists solely of a link to the entry for "false note"; both the guitar term "dead note" and the wind instrument term "ghost note" point to the term false note. But I can't find any other links in the first few pages of Google to indicate that this VT usage is commonly-accepted or widespread. Wikipedia (in a poorly-cited article) uses the term "ghost note" for all instruments (including the string-muted and palm-muted notes). This entry seems to indicate that "ghost note" is a term widely used with drums. Following up on links to "ghost note" in the guitar world causes me to believe that ghost notes in guitar are different than ghost notes in wind instruments. So I don't think that "ghost note" is a good universal term either. After this little search, I'm inclined to lean toward the Virginia Tech answer -- use the "false note" term, since it's not used anywhere else, and point it to "dead notes" for guitar and "ghost notes" for woodwinds. If this were strictly a tablature issue, I'd say keep it at "dead notes", since that is the guitar term. But Marc's excellent patch also applies to musical staffs, and those notating for woodwinds might want to use it as well (although that can be done with an override, since it's not part of a chord). Anyway, what do you think we should do for this notation? Thanks, Carl > > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Possible bug with system-count
Hi Joe,
You may already be aware of this issue, but I'll report it anyway.
I'm currently typesetting a piece that should comfortably fit two
systems to a page. For consistency's sake I've added system-count = 2 in
the \layout block. I've added a minimalish file atthe bottom of this
message. When I compile it I get the following output:
,
| lilypond /home/cameron/temp/systemcount.ly
| GNU LilyPond 2.13.2
| Processing `/home/cameron/temp/systemcount.ly'
| Parsing...
| Interpreting music... [8][16][24][32][40][48][56][64][72][80][88][96]
| Preprocessing graphical objects...
| Calculating line breaks...
| warning: cannot find line breaking that satisfies constraints
| Drawing systems...
| Solving 1 page-breaking chunks...[1: 1 or 2 pages]
| Drawing systems...
| Layout output to `systemcount.ps'...
| Converting to `./systemcount.pdf'...
|
| Compilation finished at Tue Jul 21 09:53:19
`
With system-count = 2 I notice several things:
1) I never get more than three systems. The third system will simply run
off the page. Experimentation with other values for system-count
suggests the total number of systems in the piece will be the specified
system-count plus one and the final system will not line break.
2) If there is a lot of room on the page the third system will appear on
the first page anyway. Try commenting the << and >> out to see what I
mean.
3) If I unset system-count, everything works normally.
Here's a somewhat minimal example of a file that displays this:
--8<-
\version "2.13.2"
notes = \relative c''{
\repeat unfold 100 {a b c d}
}
\score{
\new GrandStaff{
<<
\new Staff{
\notes
}
\new Staff{
\notes
}
\new Staff{
\notes
}
\new Staff{
\notes
}
\new Staff{
\notes
}
>>
}
\layout{
system-count = 2
}
}
--8<-
Hope this helps,
--
Cameron Horsburgh
Blog: http://spiritcry.wordpress.com/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Possible bug with system-count
On Tue, 2009-07-21 at 10:08 +1000, Cameron Horsburgh wrote: > Hi Joe, > > You may already be aware of this issue, but I'll report it anyway. > > I'm currently typesetting a piece that should comfortably fit two > systems to a page. For consistency's sake I've added system-count = 2 in > the \layout block. Perhaps you intended to use systems-per-page instead of system-count? Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translation review requests -- texi2html's handling of @ignore blocks
On Mon, Jul 20, 2009 at 07:02:21PM +0200, Jean-Charles Malahieude wrote:
> Le 15/07/2009 15:16, Reinhold Kainhofer disait :
>> Actually, @ignore blocks are not supposed to be processed at all,
>> that's why they are called ignore. However, @c comments would make
>> sense to include as comments in the html code. You might ask Patrice
>> (on the texi2html mailing list) about this feature. He has always been
>> very forthcoming and usually implemented things within hours.
>
> But there are many @c comments that appear in many files as well. I
> don't know anything in neither texinfo or texi2html but would it be
> possible to create a specific macro for this purpose?
I like this! Something like (untested)
@macro translateComment{TEXT}
@html
@end html
@end macro
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Converting texinfo comments to HTML comments
On Mon, Jul 20, 2009 at 02:38:13PM +0200, Reinhold Kainhofer wrote:
> In our lilypond docs, we have several texinfo comments, most notably the git
> revision of the texinfo document, which would make sense to be converted into
> html comments (so that we can e.g. determine from which revision a document
> was compiled, which is particularly useful for translators).
Sorry, I just noticed this message as well. I think this would be
better done as a macro; that way, we can retain our
non-git-revision-number comments as "private" in the documentation
source.
It's easily done with:
@macro htmlcomment{TEXT}
@html
@end html
Cheers,
- Graha
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation and releasing
On Mon, Jul 20, 2009 at 10:06:04PM +0200, Jean-Charles Malahieude wrote: > Please wait a couple of days before delivering a new release, since I'm > almost (99% plus a proof-reading) of a complete reviewing of the French > version of the learning manual. Noted, but there's going to be an almost completely rewritten LM 1 and LM 5 before 2.14 comes out. We've been discussing this for weeks, so please don't complain about the moving target that is the documentation. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Rewriting x11-color.scm
I rewrote x11-color.scm so that now the color-list is generated semi-automatically. It's more organized, easier to read, and less than a quarter of its original size. But does my approach slow things down at all? Measurably? I figure the current version is probably faster because no calculations need to be made during the definition of the color-list. But I don't have a good sense of the impact of this. I'm not posting a patch here because I'm pretty sure it would be way too big for the list-server. Anyway, please comment if you can. - Mark x11-color.scm -- allows access to x11 color codes source file of the GNU LilyPond music typesetter (c) 2005--2009 Bernard Hurley (define (number->symbol x) (string->symbol (number->string x))) (define invariant-colors ;; 63 colors that do not accept suffixes '((AliceBlue240 248 255) (beige245 245 220) (black 0 0 0) (BlanchedAlmond 255 235 205) (BlueViolet 138 43 226) (CornflowerBlue 100 149 237) (DarkBlue 0 0 139) (DarkCyan 0 139 139) (DarkGray 169 169 169) (DarkGreen 0 100 0) (DarkGrey 169 169 169) (DarkKhaki189 183 107) (DarkMagenta 139 0 139) (DarkRed 139 0 0) (DarkSalmon 233 150 122) (DarkSlateBlue 72 61 139) (DarkSlateGrey 47 79 79) (DarkTurquoise 0 206 209) (DarkViolet 148 0 211) (DimGray 105 105 105) (DimGrey 105 105 105) (FloralWhite 255 250 240) (ForestGreen 34 139 34) (gainsboro220 220 220) (GhostWhite 248 248 255) (GreenYellow 173 255 47) (lavender 230 230 250) (LawnGreen124 252 0) (LightCoral 240 128 128) (LightGoldenrodYellow 250 250 210) (LightGray211 211 211) (LightGreen 144 238 144) (LightGrey211 211 211) (LightSeaGreen 32 178 170) (LightSlateBlue 132 112 255) (LightSlateGray 119 136 153) (LightSlateGrey 119 136 153) (LimeGreen 50 205 50) (linen250 240 230) (MediumAquamarine 102 205 170) (MediumBlue 0 0 205) (MediumSeaGreen60 179 113) (MediumSlateBlue 123 104 238) (MediumSpringGreen 0 250 154) (MediumTurquoise 72 209 204) (MediumVioletRed 199 21 133) (MidnightBlue 25 25 112) (MintCream245 255 250) (moccasin 255 228 181) (navy 0 0 128) (NavyBlue 0 0 128) (OldLace 253 245 230) (PaleGoldenrod238 232 170) (PapayaWhip 255 239 213) (peru 205 133 63) (PowderBlue 176 224 230) (SaddleBrown 139 69 19) (SandyBrown 244 164 96) (SlateGrey112 128 144) (violet 238 130 238) (white255 255 255) (WhiteSmoke 245 245 245) (YellowGreen 154 205 50))) (define variant-colors ;; 78 colors that accept suffixes [1-4] (390 total) '((AntiqueWhite 250 235 215) (aquamarine 127 255 212) (azure 240 255 255) (bisque 255 228 196) (blue 0 0 255) (brown 165 42 42) (burlywood 222 184 135) (CadetBlue 95 158 160) (chartreuse 127 255 0) (chocolate 210 105 30) (coral 255 127 80) (cornsilk 255 248 220) (cyan 0 255 255) (DarkGoldenrod 184 134 11) (DarkOliveGreen 85 107 47) (DarkOrange 255 140 0) (DarkOrchid 153 50 204) (DarkSeaGreen 143 188 143) (DarkSlateGray 47 79 79) (DeepPink 255 20 147) (DeepSkyBlue 0 191 255) (DodgerBlue 30 144 255) (firebrick 178 34 34) (gold 255 215 0) (goldenrod 218 165 32) (green0 255 0) (honeydew 240 255 240) (HotPink255 105 180) (IndianRed 205 92 92) (ivory 255 255 240) (khaki 240 230 140) (LavenderBlush 255 240 245) (LemonChiffon 255 250 205) (LightBlue 173 216 230) (LightCyan 224 255 255) (LightGoldenrod 238 221 130) (LightPink 255 182 193) (LightSalmon255 160 122) (LightSkyBlue 135 206 250) (LightSteelBlue 176 196 222) (LightYellow255 255 224) (magenta255 0 255) (maroon 176 48 96) (MediumOrchid 186 85 211) (MediumPurple 147 112 219) (MistyRose 255 228 225) (NavajoWhite255 222 173) (OliveDrab 107 142 35) (orange
Re: PATCH: Improved tablature support
On Mon, Jul 20, 2009 at 02:09:57PM -0700, Mark Polesky wrote: > > I prefer "muted" rather than "dead". Though, the LilyPond internals > can get kind of violent, especially with the Hara_kiri_engraver, We actually changed the name based on a complaint -- \removeStaffContext used to be called \haraKiriStaff (or something like that). The renaming didn't reach all of the internals, but I suppose this could be considered a code janitor task. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB3: recent git changes don't work for me
Hi,
The recent commit (e0ed3589241383db0b8d77c1c7738ad3432a4fd5) regarding
the shallow cloning of non-tracking branches broke GUB on my machine.
I'm running Git 1.6.3.3.
I simply reverted the commit for now, so that I am able to build the
darwin LilyPond installers.
Attached is the relevant portion of build.log.
Thanks,
Patrick
*** Stage: untar (lilypond, darwin-ppc)
invoking mkdir -p
/home/pnorcks/git/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master
invoking cd
/home/pnorcks/git/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master
&& git init
Initialized empty Git repository in
/home/pnorcks/git/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master/.git/
Running read_pipe
('cd /home/pnorcks/git/gub/downloads/lilypond && git rev-list --max-count=1
git.sv.gnu.org/lilypond.git/master',)
{'ignore_errors': False, 'env': {'PATH':
'/home/pnorcks/git/gub/target/tools/root/usr/bin:/home/pnorcks/bin:/home/pnorcks/usr/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/share/java/apache-ant/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/opt/qt/bin',
'LD_LIBRARY_PATH': '/home/pnorcks/git/gub/target/tools/root/usr/lib'}}
invoking cd
/home/pnorcks/git/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master
&& (git checkout -f master || git branch master)
error: pathspec 'master' did not match any file(s) known to git.
fatal: Not a valid object name: 'master'.
Command barfed: cd
/home/pnorcks/git/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master
&& (git checkout -f master || git branch master)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Possible bug with system-count
Joe Neeman writes: > On Tue, 2009-07-21 at 10:08 +1000, Cameron Horsburgh wrote: >> Hi Joe, >> >> You may already be aware of this issue, but I'll report it anyway. >> >> I'm currently typesetting a piece that should comfortably fit two >> systems to a page. For consistency's sake I've added system-count = 2 in >> the \layout block. > > Perhaps you intended to use systems-per-page instead of system-count? Hmm... I think I must have. I could swear I've (successfully) used system-count for this in the past, but the docs are pretty clear on what it means. Now I have to go through my old scores and see where (and if) I've used it in the past. Still, it occurs to me as odd that I get (+ 1 system-count) systems---I would have expected to get system-count systems, with the last system overflowing. Oh, and an important piece of information I apparently left off the original report---I'm using dev/jneeman , not master. Thanks for your time---sorry about the noise. -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
