Re: [patch] create xrefs from .tely
2010/1/3 John Mandereau : > Le samedi 26 décembre 2009 à 11:39 +0100, John Mandereau a écrit : >> Looking at the .i?tely files will basically work as well, except that it >> will miss any anchors (nodes, sections...) created by lilypond-book; >> this is not a big deal, though, as the only ones it creates are for the >> Snippets List. > > Oh, this will miss all automatically generated documentation, i.e. the > Internals Reference and some Notation appendices. All these limitations > should be commented in the code somewhere. I thought that was obvious, but ok, I've dumped a note into the CG website chapter. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website issues and comment-discussion
2010/1/3 John Mandereau : > Le dimanche 03 janvier 2010 à 10:03 +, Graham Percival a écrit : >> Because I'm a bad person and should be taken to task over it? I >> always mean to go back and fix it, > > I didn't intend to do anything else with the comment I added. There are > many other issues with the website I'm going to report accompanied with > a patch, but for this one I was stuck on making any good suggestion, so > I dumped a comment. Remember that you told me the website was ready > enough for translations, That's not quite what I said. I said that nobody was working on it, so we might as well begin translating it, partly in the hopes that the translators would fix obvious problems. > so I just > dumped this comment, and will do it again whenever such a sitation > arises again and there is no dedicated person to work on the website. Ok then, every time you dump a comment into the texinfo, I'll take the time to remove it and discuss it over email or dump it in the tracker. >> but I keep on getting dragged into >> working on other things. > > You work on so many things that you can't make sure to fix and polish > all of them yourself, and I still see nothing wrong that you put some > comments in the source rather than writing it on a private list or > sending an email in a time frame when nobody else is available for > tackling it. Maybe I should stop fussing the GUB and clean up those issues. It's certainly true that I set a bad example by leaving the website in the state I did. I'll test Patrick's patch for the uninstallation thing, but then start tidying up some old things rather than working on newer release stuff. >> > If we keep this node, then we should add some more text, maybe taking >> > inspiration from the introduction of the essay on the old website. >> >> I'm not opposed to adding more text to that node. > > You deleted my comment, but I haven't found where is this issue > registered now; this is not very productive. Umm, in this very thread? http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00082.html Scroll to the bottom, item 2) ? I expected that both those items are small enough that we could have a brief discussion on -devel and then move on with life. If not, I could add them to the tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Invalid HTML in docs
Hi John, The HTML pages for the documentation on kainhofer.com have code that looks like this: ... ... ... Was this caused by your refactoring of the texi2html init file? I'm asking because the above is not valid HTML, and the colorDefault class is not used in the docs stylesheet, only in lilypond-web.css. Can you take a look at this? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Invalid HTML in docs
I can't reproduce this, although looking at the code I can't see how
it's working on my computer. I haven't tried a completely rebuild,
though.
Try this patch; if it fixes the problem on your end, then please push.
Cheers,
- Graham
On Mon, Jan 4, 2010 at 8:49 AM, Patrick McCarty wrote:
> Hi John,
>
> The HTML pages for the documentation on kainhofer.com have code that
> looks like this:
>
> ...
> ...
> ...
>
> Was this caused by your refactoring of the texi2html init file? I'm
> asking because the above is not valid HTML, and the colorDefault class
> is not used in the docs stylesheet, only in lilypond-web.css.
>
> Can you take a look at this?
>
> Thanks,
> Patrick
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
From 732c16a0cae48250adb8c3b3d7c7f46de5ba9bb2 Mon Sep 17 00:00:00 2001
From: Graham Percival
Date: Mon, 4 Jan 2010 09:11:07 +
Subject: [PATCH] Web build: fix color classes.
---
Documentation/lilypond-texi2html.init |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/lilypond-texi2html.init b/Documentation/lilypond-texi2html.init
index e3b09ab..55186a9 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -957,10 +957,11 @@ sub generate_ly_toc_entries()
'manuals' => [1, 1, 1, 2, 2, 2, 3, 3, 3, 3, 3, 4, 4, 4],
'community' => [1, 1, 1, 2, 2, 2, 3, 3],
);
- my $addColor = " colorDefault";
+ my $addColor = "class = \"";
+ $addColor = $addColor . "\" colorDefault";
while (($top_section, $color_indices) = each %color_maps) {
if (index ($element->{'sectionup'}->{'file'}, $top_section) >= 0) {
- $addColor = " color" . $color_indices->[$child_count];
+ $addColor = $addColor . " color" . $color_indices->[$child_count];
}
}
$this_css_class .= $addColor . "\"";
--
1.6.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] GUB: Fix #885
New linux binaries with this patch are here: http://lilypond.org/~graham/ If they work for you (I can't remember what arch you have, so I did them all), could you send that patch for Jan for pushing to GUB? Cheers, - Graham On Sat, Jan 2, 2010 at 9:27 AM, Patrick McCarty wrote: > Hello, > > I think this patch fixes Issue 885, even though I can't test it at the > moment. See > > http://code.google.com/p/lilypond/issues/detail?id=885 > > Thanks, > Patrick > > ___ > 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
extra font required for make doc
Due to the euro symbol in the website, we now require the femyr10 font for tex. This isn't part of the normal tex fonts, since the symbol didn't exist when tex was originally written. In ubuntu, you can get it from texlive-fonts-recommended or something like that. AFAIK we don't have an accurate list of doc requirements in the CG, and Mark is rewriting that chapter anyway, so I don't plan on changing the CG or modifying the configure script. If you're interested in either of these tasks, be my guest. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
away for a few days
Tomorrow I'm off for a few days, meeting some relatives and Trevor. As previously mentioned, I won't stick to my "2 hours a day" rule while I'm away; it might be more (if I have a boring train journey) or much less (if the family is interesting, if there's nice scenery, etc). I'll resume my normal hours on Friday 8 Jan. If I do work, it'll be on the GOP website, adding info about lilypond mentors to the CG, moving the waf stuff from dev/gperciva (and delete it) into dev/waf, and documenting a few more bits of the doc-building process. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
bends: pre-implementation issues
Hello all, I plan to work on the emplementation of bends for lilypond. Some preliminary tests with scheme were successful, so I want to go to the next stage soon and create some new engravers. But there are still some unsolved issues. But first, a brief explanation for all non-guitarists out there: a band is achieved by pressing down a string and moving it along the frets. The string gets bend, and the resulting tone gets higher. There are three variants: 1) the bend (or bend up): plucking the string, then doing the bend 2) release bend: plucking a already bent string. Sounds like a reverse bend. 3) pre bend: bend the unplucked string, pluck afterwards. Mostly (but not always) followed by a release bend. [Tablature guys: if I have missed something important, please join in and correct me!] In normal staves, bends are indicated by pointed slurs: "^" In tab staves, bends are indicated by arrows which start parallel to the staff lines and go upwards until they point perpendicular to the staff lines. The bend amount is indicated by numbers. As bends are musically and technically some sort of slurs, I think the best way to implement them is mainly to copy the slur engraver code and to adapt it properly. Internally, slurs cannot be created via slur = (make-music 'SlurEvent) so with bends, I have to add the commands to the parser. Is this correct? If this is true, it yields to the second question. Would it be better to create three new commands, like \bend, \releaseBend and \preBend, or to use one indicator/command and let lilypond decide what to do? I see two possible solutions: either e4 \bend f \releaseBend e2 or e4 ^ f ^ e2 The "^" sign isn't mandatory, but it would make sense, as the output looks similar in this case. The form e4 \bend f \bend e2 isn't not as easy to understand for the code reader. As I am not at all familiar with engravers, I have a last question concerning the capabilities of engravers: sometimes there are situations where bends are "concatenated", i.e. e4 \bend f \bend g \release e or e4 \bend g \release f \release e Can the engraver "foresee" when it is working on the e-g part that there are *two* release bends afterwards? Or in the former case, can the g-e release part be told that there were two bends upwards? (The slur engraver cannot do this, I know, but I want to know whether it is technically possible to store information of previous or following engraving actions, so they can influence the engraving process? I tried to use booleans while playing around with bends and scheme, but this didn't work very well/at all). Thanks in advance Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[opensuse-contrib] lilypond
Hi, I'm the current maintainer of lilypond in openSUSE:Contrib and am in the process of updating to version 2.12.3.I'm currently having a bit of a problem with the info files and info is an area that is new to me as far as packaging and creating are concerned. 1) The man page for lilypond-invoke-editor points to the info page which gives a copy of the man page and there is no lilypond-invoke-editor.info to be found. Have I done something wrong or is this a bug as there is no info page in the documentation package or built with the package at all? 2) I would like to be able to make a package with the info images available but ATM can't get this right. Everything packaged under the info directory gets compressed and has a .gz extension even where the two links link to. I'm not sure if this is the problem. ATM I delete the two links, lilypond, lilypond-snippets and the files lilypond-snippets.info-images-dir-dep and lilypond.info-images-dir-dep which I assume are related to this. 3) install_info complains about lilypond-learning.info and lilypond-programming.info not having DIR headers, I examined the other info files and made patches (usr/ is where I unpack the documentation) :- --- usr/share/info/lilypond-learning.info 2009-12-15 22:08:29.0 +0200 +++ usr/share/info/lilypond-learning.info 2010-01-03 19:28:30.762962562 +0200 @@ -1,3 +1,9 @@ +INFO-DIR-SECTION GNU LilyPond -- the music typesetter + +START-INFO-DIR-ENTRY +* LilyPond Learning Manual: (lilypond-learning). Start here. +END-INFO-DIR-ENTRY + Indirect: lilypond-learning.info-1: 0 and :- --- usr/share/info/lilypond-program.info2010-01-03 19:39:47.060086021 +0200 +++ usr/share/info/lilypond-program.info2010-01-03 19:46:14.146956727 +0200 @@ -1,4 +1,9 @@ This is out-www/lilypond-program.info, produced by makeinfo version 4.13 from out-www/lilypond-program.texi. +INFO-DIR-SECTION GNU LilyPond -- the music typesetter + +START-INFO-DIR-ENTRY +* LilyPond Application Usage: (lilypond-program). Installing and running applications. +END-INFO-DIR-ENTRY File: lilypond-program.info, Node: Top, Next: Install, Up: (dir) Have I done this correctly? My spec file can be found at http://pastebin.com/m34f46995 Any help you can give will be appreciated. Dave Plater ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Op maandag 04-01-2010 om 15:33 uur [tijdzone +0200], schreef Dave
Plater:
Hi Dave,
Thanks for mailing us about this!
> I'm the current maintainer of lilypond in openSUSE:Contrib and am in the
> process of updating to version 2.12.3.I'm currently having a
> bit of a problem with the info files and info is an area that is new to me as
> far as packaging and creating are concerned.
> 1) The man page for lilypond-invoke-editor points to the info page which
> gives a copy of the man page and there is no
> lilypond-invoke-editor.info to be found. Have I done something wrong or is
> this a bug as there is no info page in the documentation package
> or built with the package at all?
There is no lilypond-invoke-editor.info -- I think you found a bug
(sort of), this is a general remark for [GNU] help2man man pages.
Is there a reason not to build the documentation? It would be good
to know for lilypond developers as well as openSUSE users that
everything they see in the manual actually can be and was
created on SUSE.
Another /big/ advantage of building the documentation is that you/we
can say to openSUSE users to do
zypper source-install -d lilypond-documentation
and they be ready to build lilypond themselves.
> 2) I would like to be able to make a package with the info images available
> but ATM can't get this right. Everything packaged under the
> info directory gets compressed and has a .gz extension even where the two
> links link to. I'm not sure if this is the problem. ATM I delete
> the two links, lilypond, lilypond-snippets and the files
> lilypond-snippets.info-images-dir-dep and lilypond.info-images-dir-dep which I
> assume are related to this.
Yes, that's related. The openSUSE extended info install check blindly
gzips everything it finds, including the target of symlinks that do
not exist.
The symlinks will help emacs find the images, there need be two
usr/share/info/lilypond --> ../../doc/lilypond/html/Documentation/user
usr/share/info/lilypond-snippets --> ../../doc/lilypond/input/lsr
or somesuch. I think we used to print a helpful/warning message
when installing the documentation -- esp. for distributions when
they install not in /usr but for packaging reasons - but that seems
to be gone now [John, Graham?]
Have you seen/read this section in the rpm that you (or at least
is now) commented out?
This is/was to work around this gzipping thing
# brp-compress ignorantly compress the symlink (or directory) for Info
images.
# ERROR: link target doesn't exist (neither in build root nor in
installed system):
# /usr/share/info/lilypond-snippets.gz ->
/usr/doc/packages/lilypond/html/input/lsr/.gz
#%define __os_install_post \
#%{suse_check} \
#/usr/lib/rpm/brp-compress \
#(cd %{buildroot}/usr/share/info; \
# rm -f lilypond.gz; \
# ln -sf ../doc/packages/lilypond/html/Documentation/user lilypond; \
# rm -f lilypond-snippets.gz; \
# ln -sf ../doc/packages/lilypond/html/input/lsr lilypond-snippets) \
#/usr/lib/rpm/brp-symlink
> 3) install_info complains about lilypond-learning.info and
> lilypond-programming.info not having DIR headers, I examined the other info
> files and made patches (usr/ is where I unpack the documentation) :-
Hmm, I don't think you need to install-info these files, all
necessary headers should be available in lilypond.info,
lilypond-internals.info and music-glossary.info
eg, this
> --- usr/share/info/lilypond-learning.info 2009-12-15
> 22:08:29.0 +0200
> +++ usr/share/info/lilypond-learning.info 2010-01-03
> 19:28:30.762962562 +0200
> @@ -1,3 +1,9 @@
> +INFO-DIR-SECTION GNU LilyPond -- the music typesetter
> +
> +START-INFO-DIR-ENTRY
> +* LilyPond Learning Manual: (lilypond-learning). Start here.
> +END-INFO-DIR-ENTRY
> +
is in lilypond.tely [and thus lilypond.info] as:
* LilyPond Learning Manual: (lilypond-learning). Start here.
* LilyPond Internals Reference: (lilypond-internals). Definitions for
tweaking.
* LilyPond Application Usage: (lilypond-program). Installing and running
applications.
Greetings,
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: [tablatures] bends: pre-implementation issues
On 1/4/10 5:38 AM, "Marc Hohl" wrote: > Hello all, > > I plan to work on the emplementation of bends for lilypond. Some preliminary > tests with scheme were successful, so I want to go to the next stage > soon and > create some new engravers. But there are still some unsolved issues. > > But first, a brief explanation for all non-guitarists out there: > a band is achieved by pressing down a string and moving it along the frets. > The string gets bend, and the resulting tone gets higher. There are three > variants: > 1) the bend (or bend up): plucking the string, then doing the bend > 2) release bend: plucking a already bent string. Sounds like a reverse bend. > 3) pre bend: bend the unplucked string, pluck afterwards. Mostly (but > not always) > followed by a release bend. > > [Tablature guys: if I have missed something important, please join in > and correct me!] > > In normal staves, bends are indicated by pointed slurs: "^" > In tab staves, bends are indicated by arrows which start parallel to the > staff lines > and go upwards until they point perpendicular to the staff lines. The > bend amount > is indicated by numbers. > > As bends are musically and technically some sort of slurs, I think the > best way to implement them is mainly to copy the slur engraver code and to > adapt it properly. Internally, slurs cannot be created via > > slur = (make-music 'SlurEvent) > > so with bends, I have to add the commands to the parser. Is this correct? Yes, you will need to add something to the parser, I believe. It's because bends need to be spanners (they connect notes, so they cover multiple moments). > > If this is true, it yields to the second question. Would it be better to > create three new commands, like \bend, \releaseBend and \preBend, or to use > one indicator/command and let lilypond decide what to do? > I don't know enough about your plans to be able to answer this. > I see two possible solutions: either > > e4 \bend f \releaseBend e2 > > or > > e4 ^ f ^ e2 > > The "^" sign isn't mandatory, but it would make sense, as the output looks > similar in this case. The form > I'm sorry, but you can't use ^. That's already used to place markups, slurs, ties, etc. in an up direction. > e4 \bend f \bend e2 > > isn't not as easy to understand for the code reader. > I think you ought to come up with something that is an "enclosure" type of element, like slurs. Perhaps something like ^( ^) (but I don't know if that will work in the parser or not). On the other hand, if a bend is always between two notes, something like a tie symbol may work. You might consider ~^ to be a bend between two notes. > As I am not at all familiar with engravers, I have a last question > concerning the > capabilities of engravers: > > sometimes there are situations where bends are "concatenated", i.e. > > e4 \bend f \bend g \release e > > or > > e4 \bend g \release f \release e > > Can the engraver "foresee" when it is working on the e-g part that there > are *two* > release bends afterwards? Or in the former case, can the g-e release > part be told > that there were two bends upwards? > (The slur engraver cannot do this, I know, but I want to know whether it is > technically possible to store information of previous or following engraving > actions, so they can influence the engraving process? I tried to use > booleans > while playing around with bends and scheme, but this didn't work very > well/at all). You can do whatever you want in engravers. I'm sure that you can make this stuff work, but the exact mechanism isn't clear to me now, because I don't have a picture in my mind of what you want the notation to look like. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
On 01/04/2010 05:11 PM, Jan Nieuwenhuizen wrote:
> Op maandag 04-01-2010 om 15:33 uur [tijdzone +0200], schreef Dave
> Plater:
>
> Hi Dave,
>
> Thanks for mailing us about this!
>
>
>> I'm the current maintainer of lilypond in openSUSE:Contrib and am in the
>> process of updating to version 2.12.3.I'm currently having a
>> bit of a problem with the info files and info is an area that is new to me
>> as far as packaging and creating are concerned.
>> 1) The man page for lilypond-invoke-editor points to the info page which
>> gives a copy of the man page and there is no
>> lilypond-invoke-editor.info to be found. Have I done something wrong or is
>> this a bug as there is no info page in the documentation package
>> or built with the package at all?
>>
> There is no lilypond-invoke-editor.info -- I think you found a bug
> (sort of), this is a general remark for [GNU] help2man man pages.
>
> Is there a reason not to build the documentation? It would be good
> to know for lilypond developers as well as openSUSE users that
> everything they see in the manual actually can be and was
> created on SUSE.
>
> Another /big/ advantage of building the documentation is that you/we
> can say to openSUSE users to do
>
> zypper source-install -d lilypond-documentation
>
> and they be ready to build lilypond themselves.
>
I'm assuming that the documentation tarball which is 98 meg in size
contains the same documentation as gets built and downloaded from the
web by the other method. In which case the documentation rpm will still
be the same size and the source rpm will be smaller but when building
you will end up downloading a lot more than the doc tarball. Am I right
in my assumption?
>
>> 2) I would like to be able to make a package with the info images available
>> but ATM can't get this right. Everything packaged under the
>> info directory gets compressed and has a .gz extension even where the two
>> links link to. I'm not sure if this is the problem. ATM I delete
>> the two links, lilypond, lilypond-snippets and the files
>> lilypond-snippets.info-images-dir-dep and lilypond.info-images-dir-dep which
>> I
>> assume are related to this.
>>
> Yes, that's related. The openSUSE extended info install check blindly
> gzips everything it finds, including the target of symlinks that do
> not exist.
>
> The symlinks will help emacs find the images, there need be two
>
>usr/share/info/lilypond --> ../../doc/lilypond/html/Documentation/user
>usr/share/info/lilypond-snippets --> ../../doc/lilypond/input/lsr
>
> or somesuch. I think we used to print a helpful/warning message
> when installing the documentation -- esp. for distributions when
> they install not in /usr but for packaging reasons - but that seems
> to be gone now [John, Graham?]
>
> Have you seen/read this section in the rpm that you (or at least
> is now) commented out?
>
> This is/was to work around this gzipping thing
>
> # brp-compress ignorantly compress the symlink (or directory) for Info
> images.
> # ERROR: link target doesn't exist (neither in build root nor in
> installed system):
> # /usr/share/info/lilypond-snippets.gz ->
> /usr/doc/packages/lilypond/html/input/lsr/.gz
> #%define __os_install_post \
> #%{suse_check} \
> #/usr/lib/rpm/brp-compress \
> #(cd %{buildroot}/usr/share/info; \
> # rm -f lilypond.gz; \
> # ln -sf ../doc/packages/lilypond/html/Documentation/user lilypond; \
> # rm -f lilypond-snippets.gz; \
> # ln -sf ../doc/packages/lilypond/html/input/lsr lilypond-snippets) \
> #/usr/lib/rpm/brp-symlink
>
This makes sense, I had already tried restoring the links almost the
same way as you have done, the documentation tarball now uses the path
/usr/share/docs/lilypond and I moved everything to
/usr/share/docs/packages/lilypond and had to recreate the links, I don't
know the brp-compress and brp-symlink tricks though, what do they do? I
will uncomment this section and play with it now I know what its for, it
was already commented out when I took over.
>
>> 3) install_info complains about lilypond-learning.info and
>> lilypond-programming.info not having DIR headers, I examined the other info
>> files and made patches (usr/ is where I unpack the documentation) :-
>>
> Hmm, I don't think you need to install-info these files, all
> necessary headers should be available in lilypond.info,
> lilypond-internals.info and music-glossary.info
>
> eg, this
>
>
>> --- usr/share/info/lilypond-learning.info 2009-12-15
>> 22:08:29.0 +0200
>> +++ usr/share/info/lilypond-learning.info 2010-01-03
>> 19:28:30.762962562 +0200
>> @@ -1,3 +1,9 @@
>> +INFO-DIR-SECTION GNU LilyPond -- the music typesetter
>> +
>> +START-INFO-DIR-ENTRY
>> +* LilyPond Learning Manual: (lilypond-learning). Start here.
>> +END-INFO-DIR-ENTRY
>> +
>>
> is in lilypond.tely [and thus lilypond.info] as:
>
> * Lily
Re: bends: pre-implementation issues
On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl wrote:
> I plan to work on the emplementation of bends for lilypond. Some preliminary
> tests with scheme were successful, so I want to go to the next stage soon
> and
> create some new engravers. But there are still some unsolved issues.
>
> But first, a brief explanation for all non-guitarists out there:
> a band is achieved by pressing down a string and moving it along the frets.
> The string gets bend, and the resulting tone gets higher. There are three
> variants:
> 1) the bend (or bend up): plucking the string, then doing the bend
> 2) release bend: plucking a already bent string. Sounds like a reverse bend.
> 3) pre bend: bend the unplucked string, pluck afterwards. Mostly (but not
> always)
> followed by a release bend.
>
> [Tablature guys: if I have missed something important, please join in and
> correct me!]
>
> In normal staves, bends are indicated by pointed slurs: "^"
> In tab staves, bends are indicated by arrows which start parallel to the
> staff lines
> and go upwards until they point perpendicular to the staff lines. The bend
> amount
> is indicated by numbers.
>
> As bends are musically and technically some sort of slurs, I think the
> best way to implement them is mainly to copy the slur engraver code and to
> adapt it properly. Internally, slurs cannot be created via
>
> slur = (make-music 'SlurEvent)
>
> so with bends, I have to add the commands to the parser. Is this correct?
Initially, you can define the appropriate events in
define-music-types.scm, and use an identifier to access them; see
ly/declarations-init.ly
for examples on how to instantiate them.
You should focus on building the backend formatting before worrying
about the syntax. It is ok to launch the feature with an experimental
syntax for one release or so, so don't worry about getting the syntax
right, as experimenting with syntax is the easy part.
You are worrying about the engravers, but in reality engravers are
simple classes which just connect grobs together, and the real
difficulty is in writing the formatting code that manipulates the
grobs.
Do not use the slur code for creating the bends. Slurs have many
graphic peculiarities, and you will spend needless energy in switching
off the slur behavior. The real question you need to resolve first is
item vs. spanner, i.e. if you have a bend like this:
<<
{ c4\bend d4\release }
{ f8 g8 a8 b8 }
>>
will the bend traverse the 8th note to reach up to the following 4th
note (the D)? Or is its shape more or less fixed?
> isn't not as easy to understand for the code reader.
>
> As I am not at all familiar with engravers, I have a last question
> concerning the
> capabilities of engravers:
>
> sometimes there are situations where bends are "concatenated", i.e.
>
> e4 \bend f \bend g \release e
>
> or
>
> e4 \bend g \release f \release e
>
> Can the engraver "foresee" when it is working on the e-g part that there are
> *two*
> release bends afterwards? Or in the former case, can the g-e release part be
> told
> that there were two bends upwards?
> (The slur engraver cannot do this, I know, but I want to know whether it is
> technically possible to store information of previous or following engraving
> actions, so they can influence the engraving process? I tried to use
> booleans
> while playing around with bends and scheme, but this didn't work very
> well/at all).
As said, the engravers are just for setting up grobs, and engravers
receive information in time-order, ie. when receiving the event for
the first bend, the engraver does not know about the 2nd bend. Of
couse, you can alter the 1st bend on receiving the 2nd bend, but the
administration involved may be tricky, as it needs to work correctly
in polyphonic situations too, like the example I quoted above.
--
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 issue 786 (lyric extenders) again
> Yes, I am top-posting I notice that issue 786 was just marked as critical. I sent the following message to -devel four weeks ago but never received a response. I'd appreciate advice on how to write messages that are more responder-friendly. Chris Snyder wrote: Issue 786, which was caused by a patch I submitted back in March, was recently re-opened with another case of an extender being completized too early. Looking at the example, it's easy to spot what's going on. The fix, however, looks to me to be less straightforward. Some background: The original patch fixed an issue where an extender would go too long (sometimes to the end of the score) when the lyrics ended before the associated voice. This was because extenders were only completized when the next event in the Lyrics context came along, which would never occur if the Lyrics block ended with an extender. My original patch added a check to see if the voice was in a melisma and to completize the extender if not. One problem this caused (original issue 786) was with manual melismata, which the melisma_busy(voice) function doesn't know about (and can't - it doesn't know about Lyrics contexts at all, nor should/could it, since multiple Lyrics contexts can be associated with one voice). This was fixed by changing the Lyric_engraver to add empty LyricText objects. The Extender_engraver checks both melisma_busy and for the presence of an empty LyricText object, and only completizes the extender if neither is true (as well as another check to fix issue 800). The case that caused issue 786 to be reopened, however, poses yet another problem. It is more general than just happening with beamed notes - I've verified the same behavior with slurs and ties as well. It happens whenever an automatic melisma (beam, slur, tie) is followed by a manual one (underscore in Lyrics). Looking at the checks I added, it's obvious what's happening: On the last note of the automatic melisma, melisma_busy returns false, but the empty LyricsText object won't occur until the next moment, so the Extender_engraver thinks it should completize the extender. Under the scheme as it exists now, the Extender_engraver would have to somehow check for an empty LyricText object occurring in the future. This doesn't seem to me to be the correct approach. Alternatively, I've thought of another solution that seems to be more elegant than this growing list of checks for various cases: what if the parser created an empty LyricText object at the end of each Lyrics block? That would solve the original issue I fixed back in March in a way that would allow us to revert that part of the Extender_engraver to the way it was before my original patch. Before I try to learn how the parser works, does this seem like an acceptable approach? Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Op maandag 04-01-2010 om 19:09 uur [tijdzone +0200], schreef Dave Plater: > On 01/04/2010 05:11 PM, Jan Nieuwenhuizen wrote: > > Op maandag 04-01-2010 om 15:33 uur [tijdzone +0200], schreef Dave > > Plater: Hi Dave, > > Another /big/ advantage of building the documentation is that you/we > > can say to openSUSE users to do > > > > zypper source-install -d lilypond-documentation > > > > and they be ready to build lilypond themselves. > > > I'm assuming that the documentation tarball which is 98 meg in size > contains the same documentation as gets built and downloaded from the > web by the other method. Nothing gets downloaded when you build the documentation by doing "make web". The pre-built documentation ball is available primarily for users that do not want to, or do not succeed in building the docs. It contains what gets built by doing "make web; make web-install" > In which case the documentation rpm will still > be the same size and the source rpm will be smaller but when building > you will end up downloading a lot more than the doc tarball. Am I right > in my assumption? I don't see much difference in the source rpm's size. Either way it contains just all of lilypond. When downloading the prebuilt doc ball, you download ~98MB more; stuff that you otherwise all build locally. > This makes sense, I had already tried restoring the links almost the > same way as you have done, the documentation tarball now uses the path > /usr/share/docs/lilypond and I moved everything to > /usr/share/docs/packages/lilypond and had to recreate the links, I don't > know the brp-compress and brp-symlink tricks though, what do they do? I > will uncomment this section and play with it now I know what its for, it > was already commented out when I took over. Ah. Then you probably also did not comment-out "make web" and added downloading the documentation tarball. Best to revert that, I think. I did not invent the brp-symlink and brp-compress; although I can take a guess as to what they do [hint: man symlink, man compress]. This magic was just copied from the original __os_install_post macro in the rpm lib; with added rm and ln fixings. > The lilypond-learning and programming infos look cleaner at the top with > the INFO-DIR-SECTION but they still work without it and those two infos > weren't in the previous documentation at least not in the spec file.. Interesting. 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: [opensuse-contrib] lilypond
Op maandag 04-01-2010 om 19:09 uur [tijdzone +0200], schreef Dave Plater: Hi Dave, I see in the osc log (sadly omitted from the spec's change log): $ osc log | p GET https://api.opensuse.org/source/openSUSE:Factory:Contrib/lilypond/_history r11 | pgajdos | 2009-11-11 07:48:04 | ab1f57adcc696674b2d2e1ad9dd78f93 | 2.12.2 - Don't build documentation because of problems on x86_64. Well, that does not say very much. In fact, I built and tested it on x86_64, so I'm kind of disappointed not having seen a bug report or question about the problem. Also, a change log entry saying exactly /what/ the problem was, would have been nice. So you probably just want to revert r11, update to 2.12.3 and see what happens. HTH, janneke -- 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: [opensuse-contrib] lilypond
On 01/04/2010 05:11 PM, Jan Nieuwenhuizen wrote:
> Op maandag 04-01-2010 om 15:33 uur [tijdzone +0200], schreef Dave
> Plater:
>
> Hi Dave,
>
> Thanks for mailing us about this!
>
>
>> I'm the current maintainer of lilypond in openSUSE:Contrib and am in the
>> process of updating to version 2.12.3.I'm currently having a
>> bit of a problem with the info files and info is an area that is new to me
>> as far as packaging and creating are concerned.
>> 1) The man page for lilypond-invoke-editor points to the info page which
>> gives a copy of the man page and there is no
>> lilypond-invoke-editor.info to be found. Have I done something wrong or is
>> this a bug as there is no info page in the documentation package
>> or built with the package at all?
>>
> There is no lilypond-invoke-editor.info -- I think you found a bug
> (sort of), this is a general remark for [GNU] help2man man pages.
>
> Is there a reason not to build the documentation? It would be good
> to know for lilypond developers as well as openSUSE users that
> everything they see in the manual actually can be and was
> created on SUSE.
>
> Another /big/ advantage of building the documentation is that you/we
> can say to openSUSE users to do
>
> zypper source-install -d lilypond-documentation
>
> and they be ready to build lilypond themselves.
>
>
>> 2) I would like to be able to make a package with the info images available
>> but ATM can't get this right. Everything packaged under the
>> info directory gets compressed and has a .gz extension even where the two
>> links link to. I'm not sure if this is the problem. ATM I delete
>> the two links, lilypond, lilypond-snippets and the files
>> lilypond-snippets.info-images-dir-dep and lilypond.info-images-dir-dep which
>> I
>> assume are related to this.
>>
> Yes, that's related. The openSUSE extended info install check blindly
> gzips everything it finds, including the target of symlinks that do
> not exist.
>
> The symlinks will help emacs find the images, there need be two
>
>usr/share/info/lilypond --> ../../doc/lilypond/html/Documentation/user
>usr/share/info/lilypond-snippets --> ../../doc/lilypond/input/lsr
>
> or somesuch. I think we used to print a helpful/warning message
> when installing the documentation -- esp. for distributions when
> they install not in /usr but for packaging reasons - but that seems
> to be gone now [John, Graham?]
>
> Have you seen/read this section in the rpm that you (or at least
> is now) commented out?
>
> This is/was to work around this gzipping thing
>
> # brp-compress ignorantly compress the symlink (or directory) for Info
> images.
> # ERROR: link target doesn't exist (neither in build root nor in
> installed system):
> # /usr/share/info/lilypond-snippets.gz ->
> /usr/doc/packages/lilypond/html/input/lsr/.gz
> #%define __os_install_post \
> #%{suse_check} \
> #/usr/lib/rpm/brp-compress \
> #(cd %{buildroot}/usr/share/info; \
> # rm -f lilypond.gz; \
> # ln -sf ../doc/packages/lilypond/html/Documentation/user lilypond; \
> # rm -f lilypond-snippets.gz; \
> # ln -sf ../doc/packages/lilypond/html/input/lsr lilypond-snippets) \
> #/usr/lib/rpm/brp-symlink
>
>
snip
> Greetings,
> Jan.
>
Disregard what I said about building the documentation although it seems
to take a long time. The "make web" target no longer exists, I'm trying
it out with "make doc", there is a "make WEB_TARGETS=" but I don't think
thats what "make web" was. What would happen if I extracted the
documentation tarball into `out-www' ?
Regards
Dave P
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Op maandag 04-01-2010 om 21:00 uur [tijdzone +0200], schreef Dave Plater: > On 01/04/2010 05:11 PM, Jan Nieuwenhuizen wrote: > > Op maandag 04-01-2010 om 15:33 uur [tijdzone +0200], schreef Dave > Disregard what I said about building the documentation although it seems > to take a long time. The "make web" target no longer exists, I'm trying > it out with "make doc", yes, doc and doc-install they're called now. Thought that only was on the 2.13 branch...sorry. > What would happen if I extracted the documentation tarball into `out-www' ? It may just be that the docs do not build on suse and you won't know? Have you seen the osc log message? That's exactly why not building the docs is a bad idea. Apparently, the 2.12.2 docs did not build on openSUSE x86_64; not good. Did you consider the zypper source-install issue? Greetings, janneke ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] bends: pre-implementation issues
Carl Sorensen schrieb:
On 1/4/10 5:38 AM, "Marc Hohl" wrote:
{[..]
so with bends, I have to add the commands to the parser. Is this correct?
Yes, you will need to add something to the parser, I believe. It's because
bends need to be spanners (they connect notes, so they cover multiple
moments).
Ok.
If this is true, it yields to the second question. Would it be better to
create three new commands, like \bend, \releaseBend and \preBend, or to use
one indicator/command and let lilypond decide what to do?
I don't know enough about your plans to be able to answer this.
I attached an example to my answer to Han-Wens mail. In measures
1 to 6, the is a bend/release bend combination, measure 7 is bend up
only, measure 9 is a single pre bend, and measure 10 is a pre bend followed
by a release bend.
The usage code in ly files should be easily understandable, so
I think I'll vote for \preBend, \bend and \releaseBend, but I don't know
if it is
wise to define three parser commands if there is a possibility of using
only one
(see below).
I see two possible solutions: either
e4 \bend f \releaseBend e2
or
e4 ^ f ^ e2
The "^" sign isn't mandatory, but it would make sense, as the output looks
similar in this case. The form
I'm sorry, but you can't use ^. That's already used to place markups,
slurs, ties, etc. in an up direction.
Yes, of course. It was just meant as a simple abbreviation.
Perhaps \^ might do the job? I mean, if I can use a symbol, then
I think it would be best to use *one* symbol for the whole bend stuff,
but if I have to use a word as a command, then I'd prefer to
use three different commands.
On the other hand, if a bend is always between two notes, something like a
tie symbol may work. You might consider ~^ to be a bend between two notes.
A bend will definitely be always between two notes.
You can do whatever you want in engravers. I'm sure that you can make this
stuff work, but the exact mechanism isn't clear to me now, because I don't
have a picture in my mind of what you want the notation to look like.
Perhaps it is a bit clearer now (?), but David will post some more
sophisticated examples of what should be doable with bends, so
perhaps clarification will have to wait until then.
Thanks
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 786 (lyric extenders) again
On Mon, 2010-01-04 at 12:22 -0500, Chris Snyder wrote: > > Yes, I am top-posting > > I notice that issue 786 was just marked as critical. I sent the > following message to -devel four weeks ago but never received a > response. I'd appreciate advice on how to write messages that are more > responder-friendly. Your previous mail is asking a detailed question about code which (AFAIK) few people on the list know much about. The only advice I can offer is to pester the list more often than once a month. > Chris Snyder wrote: > > Issue 786, which was caused by a patch I submitted back in March, was > > recently re-opened with another case of an extender being completized > > too early. Looking at the example, it's easy to spot what's going on. > > The fix, however, looks to me to be less straightforward. > > > > Some background: > > The original patch fixed an issue where an extender would go too long > > (sometimes to the end of the score) when the lyrics ended before the > > associated voice. This was because extenders were only completized when > > the next event in the Lyrics context came along, which would never occur > > if the Lyrics block ended with an extender. My original patch added a > > check to see if the voice was in a melisma and to completize the > > extender if not. > > > > One problem this caused (original issue 786) was with manual melismata, > > which the melisma_busy(voice) function doesn't know about (and can't - > > it doesn't know about Lyrics contexts at all, nor should/could it, since > > multiple Lyrics contexts can be associated with one voice). This was > > fixed by changing the Lyric_engraver to add empty LyricText objects. The > > Extender_engraver checks both melisma_busy and for the presence of an > > empty LyricText object, and only completizes the extender if neither is > > true (as well as another check to fix issue 800). > > > > The case that caused issue 786 to be reopened, however, poses yet > > another problem. It is more general than just happening with beamed > > notes - I've verified the same behavior with slurs and ties as well. It > > happens whenever an automatic melisma (beam, slur, tie) is followed by a > > manual one (underscore in Lyrics). Looking at the checks I added, it's > > obvious what's happening: On the last note of the automatic melisma, > > melisma_busy returns false, but the empty LyricsText object won't occur > > until the next moment, so the Extender_engraver thinks it should > > completize the extender. > > > > Under the scheme as it exists now, the Extender_engraver would have to > > somehow check for an empty LyricText object occurring in the future. > > This doesn't seem to me to be the correct approach. > > > > Alternatively, I've thought of another solution that seems to be more > > elegant than this growing list of checks for various cases: what if the > > parser created an empty LyricText object at the end of each Lyrics > > block? That would solve the original issue I fixed back in March in a > > way that would allow us to revert that part of the Extender_engraver to > > the way it was before my original patch. Before I try to learn how the > > parser works, does this seem like an acceptable approach? Do you mean a LyricEvent (ie. a Music object, which is created in the parser) rather than a LyricText (ie. a Grob, which is created in an engraver)? I don't know much about that part of the code, but it sounds ok to me. Maybe it would be clearer, though, if you created a new music type (EndExtenderEvent, for example). Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bends: pre-implementation issues
I am confused here. Are you trying to implement the symbols that are on the tab staff, or on the normal notation? On Mon, Jan 4, 2010 at 5:44 PM, Marc Hohl wrote: > Oops, I just sent a mail with an attachment that seems to be too big > for -devel, I don't know where the limits are for the tablature list. > I'll upload it to my homepage: > > http://www.hohlart.de/marc/bendtest.pdf > > Marc > -- 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: Invalid HTML in docs
Le lundi 04 janvier 2010 à 00:49 -0800, Patrick McCarty a écrit : > ... > ... > ... > > Was this caused by your refactoring of the texi2html init file? Certainly, I botched generation of CSS class attribute for both the new website and manuals when we merged the two init files. All these kinds of issues should be fixed now, except that some classes may be wrong; I tried to check them and didn't stumble upon any strange thing, but I rely on your experience on this to report such problems. Thanks for the report, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] Re: bends: pre-implementation issues
Carl Sorensen schrieb:
On 1/4/10 12:29 PM, "Marc Hohl" wrote:
Han-Wen Nienhuys schrieb:
On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl wrote:
[...]
As bends are musically and technically some sort of slurs, I think the
best way to implement them is mainly to copy the slur engraver code and to
adapt it properly. Internally, slurs cannot be created via
slur = (make-music 'SlurEvent)
so with bends, I have to add the commands to the parser. Is this correct?
Initially, you can define the appropriate events in
define-music-types.scm, and use an identifier to access them; see
ly/declarations-init.ly
for examples on how to instantiate them.
Ok, thanks for the hint!
You should focus on building the backend formatting before worrying
about the syntax. It is ok to launch the feature with an experimental
syntax for one release or so, so don't worry about getting the syntax
right, as experimenting with syntax is the easy part.
You are worrying about the engravers, but in reality engravers are
simple classes which just connect grobs together, and the real
difficulty is in writing the formatting code that manipulates the
grobs.
To be honest: I do not worry about the engravers alone, I am
frighened by the whole task, but I need bends, so ...
Do not use the slur code for creating the bends. Slurs have many
graphic peculiarities, and you will spend needless energy in switching
off the slur behavior. The real question you need to resolve first is
item vs. spanner, i.e. if you have a bend like this:
<<
{ c4\bend d4\release }
{ f8 g8 a8 b8 }
will the bend traverse the 8th note to reach up to the following 4th
note (the D)? Or is its shape more or less fixed?
Sorry for not having an example attached. As I said, bends are
just a special case for slurs, and I defined a scheme function which uses
the control points for the bezier curve (let's call them z1, z2, z3 and z4),
computes the point in the middle between z2 and z3 (z23) and draws a line
from z1 to z23 and from z23 to z4. The slur routine takes care of all stems,
accidentals and stuff, so it seemed natural to me to use this code as a
base.
Please look at the attached pdf, especially pointed slurs in the normal
staves.
(At first, I tried to implement bends only with scheme, but there are
problems
arising when a bend is followed by a "real" slur, so I decided to do it
in a cleaner way.)
By the way: what is the difference between a spanner and an item? I strongly
feel bends *must* be spanners, but honestly, I don't know the reason.
A spanner has a start event and an end event, and covers the time in between
those events.
Thanks for explanation, this is quite identical to what I assumed,
but brought into a clear shape.
Nearly all of the bends that you have drawn must be spanners, I think.
I'm curious about measures 8 and 9 of the example you posted. In the first
beat of each note, you have a grace note bent up to a note. In measure 8,
the grace and the note have a different horizontal position in the tab; in
measure 9 they have the same horizontal position.
Measure 8 is a bend which is audible (kind of grace note, the stem is
missing - this is probably an error in my definitions), while measure 9
shows
a pre bend. The string is bent before plucking it, so it sounds at the
higher pitch.
As I look at this notation more clearly, it seems that the amount of bend is
an attribute of a note. You might consider just specifying the string and
fret of a note, and then given a string tuning, string, and fret, the amount
of bend can be calculated.
Hm, never thought of that. I would have implemented it as a function
of the surrounding notes, i.e. the note where it starts and the note
it reaches, but your approach may be able to cover blues bends as well.
But I have to take into account the duration of the bent note.
As I implemented it via scheme, I used the spanner bounds of a slur
to calculate the right amount automatically. So actually, I code
\bendOn c\5 ( d\5 ) \bendOff
for a bend.
Bend curves could then be drawn between successive notes at the same fret on
the same string, and the amount of bend can be calculated automatically.
With that kind of architecture, you'd just have the bend engraver catch
notes, and it would spit out a spanner whenever the string and fret were the
same and the note differed.
This is fairly similar to how the autobeam engraver works. It checks a
note, and provisionally starts a beam. If the beam shouldn't be created, it
junks it.
This mechanism could come in handy especially when bends are hold.
For example, in measure 9, there is a pre Bend, in measure 10 there is
a pre bend followed by a release bend. With your mechanism, I could
draw the horizontal line just in case, and if there is no release, I'll
junk it.
So what would happen in the beam engraver is that every note would be
caught, along with its
Re: [PATCH] Re: 2.13.10 pre-release testing
Am Donnerstag, 31. Dezember 2009 12:26:39 schrieb Reinhold Kainhofer: > Am Donnerstag, 31. Dezember 2009 11:29:14 schrieb Trevor Daniels: > > convert-ly - OK, except > > Happened to try a file with \version "2.10" > > This causes a python index error. > > Ouch, convert-ly assumed that all version strings always consist of three > entries... I've created a patch to really check for this and normalize the > version to a three-entry tuple if the version has more/fewer levels: > > http://codereview.appspot.com/183097 I agree with Graham that it is better in this case to simply trigger an error message and tell the user to fix the file (e.g. if the user mistypes 2.12.2 as 2.1.2.2, we don't want to apply all conversion rules from 2.1 to 2.13)... So, here's an updated patch, which checks for three-entry tuples as version numbers and prints out an understandable error message instead of making stupid assumptions. http://codereview.appspot.com/183097 Okay to apply this time? 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Le lundi 04 janvier 2010 à 21:00 +0200, Dave Plater a écrit : > Disregard what I said about building the documentation although it seems > to take a long time. The "make web" target no longer exists, I'm trying > it out with "make doc", there is a "make WEB_TARGETS=" but I don't think > thats what "make web" was. 'web' and 'web-install' targets have been renamed to 'doc' and 'install-doc', respectively, between 2.10 and 2.12 releases. You don't need overriding WEB_TARGETS. configure script doesn't check documentation build requirements completely, so be sure to know well about requirements on http://lilypond.org/doc/v2.12/Documentation/user/lilypond-program/Requirements in particular texinfo.tex, epsf.tex and TeX for building the Texinfo manuals in PDF. Building the documentation is known to be long (e.g. about half an hour on a Core 2 Duo @3GHz with 1GB or more of free RAM if you do "make -j3 CPU_COUNT=3 doc"). If you want to bypass what 'make install-doc' does, you could directly package the contents of TOP-BUILD-DIR/out-www/offline-root into what what RPM should unpack into /usr/share/doc/lilypond-VERSION/html *and* reproduce what install-doc does to install info-doc; for the last item, the simplest way is to see the commands issued when invoking 'make install-doc' (roughly copying .info files, calling install-info and creating the two symlinks to HTML docs images directories). Thank you again for raising this packaging issue, 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
CG addition about Git pulling
Hi Mark,
Could you consider adding something like the following to Git pulling
instructions? Maybe this could be under a @knownissues section (or
"Troubleshooting") at the bottom of the the node "Update command".
%
If pull fails because of a message like
@example
error: Your local changes to 'Documentation/learning/tutorial.itely'
would be overwritten by merge. Aborting.
@end example
or
@example
Documentation/learning/tutorial.itely: needs update
refusing to pull with rebase: your working tree is not up-to-date
@end example
it means that you have modified some files in you working tree without
committing changes, at least 'Documentation/learning/tutorial.itely' in
the example above; you can work around this by saving uncommitted
changes, pull, then reapplying previsouly saved changes:
@example
git stash
git pull -r
git stash pop
@end example
Note that @command{git stash pop} will try to apply a patch, so this may
creates a conflict; if it happens, see @ref{Resolving conflicts}.
%
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: bends: pre-implementation issues
Oops, I just sent a mail with an attachment that seems to be too big for -devel, I don't know where the limits are for the tablature list. I'll upload it to my homepage: http://www.hohlart.de/marc/bendtest.pdf Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New website: what's the sense of '(main)'?
Le samedi 02 janvier 2010 à 18:56 -0800, Patrick McCarty a écrit :
> I think that using the chapter name instead of "(main)" would be
> perfect. I'll take care of the CSS problem tonight.
Current style of this button you changed is better, but what about using
lily-home-nav-{bg,hover,active}.png backgrounds in exactly the same
situations as the first navigation bar? If you like this, I'll take
care of this (the init file plus the CSS).
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: Invalid HTML in docs
2010/1/4 John Mandereau : > Le lundi 04 janvier 2010 à 00:49 -0800, Patrick McCarty a écrit : >> ... >> ... >> ... >> >> Was this caused by your refactoring of the texi2html init file? > > Certainly, I botched generation of CSS class attribute for both the new > website and manuals when we merged the two init files. All these kinds > of issues should be fixed now, except that some classes may be wrong; I > tried to check them and didn't stumble upon any strange thing, but I > rely on your experience on this to report such problems. Thank you, John. That fixed it. I don't see any incorrect classes; there are empty classes (class=""), but those don't cause any problems. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] GUB: Fix #885
On Mon, Jan 4, 2010 at 1:18 AM, Graham Percival wrote: > New linux binaries with this patch are here: > http://lilypond.org/~graham/ > > If they work for you (I can't remember what arch you have, so I did > them all), could you send that patch for Jan for pushing to GUB? The linux-64 and linux-x86 builds uninstall just fine now. Thanks for doing this! -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [opensuse-contrib] lilypond
Le lundi 04 janvier 2010 à 16:11 +0100, Jan Nieuwenhuizen a écrit : > Yes, that's related. The openSUSE extended info install check blindly > gzips everything it finds, including the target of symlinks that do > not exist. > > The symlinks will help emacs find the images, there need be two > >usr/share/info/lilypond --> ../../doc/lilypond/html/Documentation/user >usr/share/info/lilypond-snippets --> ../../doc/lilypond/input/lsr > > or somesuch. Yes, these symlinks are supposed to point to the directories of the installed HTML/PDF documentation tree that contains images; HTML and Info docs can use the same images, so these symlinks are meant to save space. > I think we used to print a helpful/warning message > when installing the documentation -- esp. for distributions when > they install not in /usr but for packaging reasons - but that seems > to be gone now [John, Graham?] Why do you think it has gone? I.e., what did you do precisely to tell this? AFAICT this should still work. > Hmm, I don't think you need to install-info these files, all > necessary headers should be available in lilypond.info, > lilypond-internals.info and music-glossary.info The DIR entries are all contained in lilypond.info (source is Documentation/user/lilypond.tely) and lilypond-snippets.info (source is input/lsr/lilypond-snippets.tely), so it's necessary and sufficient to install-info these two files, and copy all .info files as well, just like 'make install-doc' (after having done 'make doc') does. 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: [opensuse-contrib] lilypond
On 01/04/2010 08:59 PM, Jan Nieuwenhuizen wrote: > Op maandag 04-01-2010 om 19:09 uur [tijdzone +0200], schreef Dave > Plater: > > Hi Dave, > > I see in the osc log (sadly omitted from the spec's change log): > > $ osc log | p > GET https://api.opensuse.org/source/openSUSE:Factory:Contrib/lilypond/_history > > r11 | pgajdos | 2009-11-11 07:48:04 | ab1f57adcc696674b2d2e1ad9dd78f93 | > 2.12.2 > > > - Don't build documentation because of problems on x86_64. > > > Well, that does not say very much. In fact, I built and tested it on > x86_64, so I'm kind of disappointed not having seen a bug report or > question about the problem. Also, a change log entry saying exactly > /what/ the problem was, would have been nice. > > So you probably just want to revert r11, update to 2.12.3 and see > what happens. > > HTH, > > janneke > > > Lilypond suddenly stopped building for x86_64 for some reason or other and I became involved due to being the maintainer of rosegarden which needs lilypond. It was then that Petr commented out the spec lines and I suppose added the tarball docs to the package, he is under a lot of work pressure and doesn't have the time. Here is the body of the reply I received when I answered his call for someone to take over :- You can notice I have commented out a big parts of spec file which > > resulted in bulid of documentation, which kindly contributed > > jann...@novell.com (the spec file is almost his work). The > > documentation stopped to build for x86_64 a significant > > while ago and janneke didn't respond so I decided > > to work around it by switching the build off again and Source2 > > documentation, because I don't have a good insight and have no > > time to puzzle the issue out. > > > > Thanks a lot again > > Petr I suspect that janneke is no longer with novell as this is the address Petr gave me yesterday and to which I sent a similar email to the one I sent to the list jann...@gnu.org. Anyway I'm a community (unpaid) maintainer so I'm not subject to similar pressures just have to do paying work sometimes. I'm busy using rpmbuild to fine tune spec file and get the files in the right places ATM and I'll let you know if I need anymore help. Regards Dave P ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] Re: bends: pre-implementation issues
On 1/4/10 3:28 PM, "Marc Hohl" wrote: > Carl Sorensen schrieb: >> >> With the architecture above, I don't think you need to specify bend and >> release bend. All of the bends you show have a note at each end of the bend >> (either a real note or a grace note). >> > Yes, but there are quarter tone bends, as David pointed out, which aren't > followed by a note. But perhaps they should be handled seperately. > Lilypond does provide doits and falls, so perhaps these features have > only to > be adapted for tablature. On the other hand, when there is a consistent > approach for handling all cases, it should be bundled together. A quarter-tone bend should just be an articulation on the note, it seems to me. But this could also be handled in the bend engraver. > > I'll wait for David's work on bend constellations and try to make a list > of all > relevant combinations/cases. Perhaps the situation can be clarified > thereafter. Sounds like a good idea to me. > > Thanks for your ideas! You're welcome. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] Re: bends: pre-implementation issues
On 1/4/10 12:29 PM, "Marc Hohl" wrote:
> Han-Wen Nienhuys schrieb:
>> On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl wrote:
>>
>>> [...]
>>>
>>> As bends are musically and technically some sort of slurs, I think the
>>> best way to implement them is mainly to copy the slur engraver code and to
>>> adapt it properly. Internally, slurs cannot be created via
>>>
>>> slur = (make-music 'SlurEvent)
>>>
>>> so with bends, I have to add the commands to the parser. Is this correct?
>>>
>>
>> Initially, you can define the appropriate events in
>> define-music-types.scm, and use an identifier to access them; see
>>
>> ly/declarations-init.ly
>>
>> for examples on how to instantiate them.
>>
> Ok, thanks for the hint!
>> You should focus on building the backend formatting before worrying
>> about the syntax. It is ok to launch the feature with an experimental
>> syntax for one release or so, so don't worry about getting the syntax
>> right, as experimenting with syntax is the easy part.
>>
>> You are worrying about the engravers, but in reality engravers are
>> simple classes which just connect grobs together, and the real
>> difficulty is in writing the formatting code that manipulates the
>> grobs.
>>
> To be honest: I do not worry about the engravers alone, I am
> frighened by the whole task, but I need bends, so ...
>> Do not use the slur code for creating the bends. Slurs have many
>> graphic peculiarities, and you will spend needless energy in switching
>> off the slur behavior. The real question you need to resolve first is
>> item vs. spanner, i.e. if you have a bend like this:
>>
>> <<
>> { c4\bend d4\release }
>>
>> { f8 g8 a8 b8 }
>>
>> will the bend traverse the 8th note to reach up to the following 4th
>> note (the D)? Or is its shape more or less fixed?
>>
> Sorry for not having an example attached. As I said, bends are
> just a special case for slurs, and I defined a scheme function which uses
> the control points for the bezier curve (let's call them z1, z2, z3 and z4),
> computes the point in the middle between z2 and z3 (z23) and draws a line
> from z1 to z23 and from z23 to z4. The slur routine takes care of all stems,
> accidentals and stuff, so it seemed natural to me to use this code as a
> base.
> Please look at the attached pdf, especially pointed slurs in the normal
> staves.
>
> (At first, I tried to implement bends only with scheme, but there are
> problems
> arising when a bend is followed by a "real" slur, so I decided to do it
> in a cleaner way.)
>
> By the way: what is the difference between a spanner and an item? I strongly
> feel bends *must* be spanners, but honestly, I don't know the reason.
A spanner has a start event and an end event, and covers the time in between
those events.
Nearly all of the bends that you have drawn must be spanners, I think.
I'm curious about measures 8 and 9 of the example you posted. In the first
beat of each note, you have a grace note bent up to a note. In measure 8,
the grace and the note have a different horizontal position in the tab; in
measure 9 they have the same horizontal position.
As I look at this notation more clearly, it seems that the amount of bend is
an attribute of a note. You might consider just specifying the string and
fret of a note, and then given a string tuning, string, and fret, the amount
of bend can be calculated.
Bend curves could then be drawn between successive notes at the same fret on
the same string, and the amount of bend can be calculated automatically.
With that kind of architecture, you'd just have the bend engraver catch
notes, and it would spit out a spanner whenever the string and fret were the
same and the note differed.
This is fairly similar to how the autobeam engraver works. It checks a
note, and provisionally starts a beam. If the beam shouldn't be created, it
junks it.
So what would happen in the beam engraver is that every note would be
caught, along with its fret and string. The note, fret, and string would be
stored in internal variables. Then, if the note is different, but the fret
and string are the same, a bend would be engraved. Otherwise, the previous
bend would be junked.
Once the disposition of the previous potential bend has been completed, a
new bend would be started, with the note, fret, and string of the current
note. This bend could either be finished or junked according to the next
note.
An alternative way to handle the bend is to just add an optional bend amount
to the note (the default of which would be zero). Then you'd have a similar
algorithm, but with slightly different details.
Get a note. If the string and fret are the same, but the bend is different,
finish and print the bend. Otherwise, junk the bend.
Then, start a new bend with the given string, fret, and bend.
>
> But to answer your question: there are situations where two strings are
> plucked
> together, the lower one being bent, while the other one s
Re: New website: what's the sense of '(main)'?
Le lundi 04 janvier 2010 à 15:03 -0800, Patrick McCarty a écrit : > I just fixed two of the gradient images in master. I didn't notice > them before because they are not currently used in the CSS. :-) > > For the CSS, you'll want to use nav-bg-2.png, nav-hover-2.png, and > nav-active-2.png on the second-layer navbar. This is for consistency, > primarily. Thanks, I'll see this next time I work again on Lily website and translations, i.e. next week-end. 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: New website: what's the sense of '(main)'?
2010/1/4 John Mandereau :
> Le samedi 02 janvier 2010 à 18:56 -0800, Patrick McCarty a écrit :
>> I think that using the chapter name instead of "(main)" would be
>> perfect. I'll take care of the CSS problem tonight.
>
> Current style of this button you changed is better, but what about using
> lily-home-nav-{bg,hover,active}.png backgrounds in exactly the same
> situations as the first navigation bar? If you like this, I'll take
> care of this (the init file plus the CSS).
Hmm. I think I prefer the current style to what you propose. Using
the lily-home images for the second-layer navbar would look too
cluttered, IMO.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New website: what's the sense of '(main)'?
2010/1/4 John Mandereau :
> Le lundi 04 janvier 2010 à 14:18 -0800, Patrick McCarty a écrit :
>> 2010/1/4 John Mandereau :
>> > Current style of this button you changed is better, but what about using
>> > lily-home-nav-{bg,hover,active}.png backgrounds in exactly the same
>> > situations as the first navigation bar? If you like this, I'll take
>> > care of this (the init file plus the CSS).
>>
>> Hmm. I think I prefer the current style to what you propose. Using
>> the lily-home images for the second-layer navbar would look too
>> cluttered, IMO.
>
> Oops, I meant using nav-{bg,hover,active}.png, in order to make clear
> whether this first entry on the second-layer navbar is active or not.
> This suggestion was for making this navbar clearer, not cluttered :-P
Oh, I see. Sure, I think that would be helpful.
I just fixed two of the gradient images in master. I didn't notice
them before because they are not currently used in the CSS. :-)
For the CSS, you'll want to use nav-bg-2.png, nav-hover-2.png, and
nav-active-2.png on the second-layer navbar. This is for consistency,
primarily.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New website: what's the sense of '(main)'?
Le lundi 04 janvier 2010 à 14:18 -0800, Patrick McCarty a écrit :
> 2010/1/4 John Mandereau :
> > Current style of this button you changed is better, but what about using
> > lily-home-nav-{bg,hover,active}.png backgrounds in exactly the same
> > situations as the first navigation bar? If you like this, I'll take
> > care of this (the init file plus the CSS).
>
> Hmm. I think I prefer the current style to what you propose. Using
> the lily-home images for the second-layer navbar would look too
> cluttered, IMO.
Oops, I meant using nav-{bg,hover,active}.png, in order to make clear
whether this first entry on the second-layer navbar is active or not.
This suggestion was for making this navbar clearer, not cluttered :-P
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: [opensuse-contrib] lilypond
On 01/04/2010 10:08 PM, John Mandereau wrote: > Le lundi 04 janvier 2010 à 21:00 +0200, Dave Plater a écrit : > >> Disregard what I said about building the documentation although it seems >> to take a long time. The "make web" target no longer exists, I'm trying >> it out with "make doc", there is a "make WEB_TARGETS=" but I don't think >> thats what "make web" was. >> > 'web' and 'web-install' targets have been renamed to 'doc' and > 'install-doc', respectively, between 2.10 and 2.12 releases. You don't > need overriding WEB_TARGETS. configure script doesn't check > documentation build requirements completely, so be sure to know well > about requirements on > http://lilypond.org/doc/v2.12/Documentation/user/lilypond-program/Requirements > in particular texinfo.tex, epsf.tex and TeX for building the Texinfo > manuals in PDF. > > Building the documentation is known to be long (e.g. about half an hour > on a Core 2 Duo @3GHz with 1GB or more of free RAM if you do "make -j3 > CPU_COUNT=3 doc"). > > If you want to bypass what 'make install-doc' does, you could directly > package the contents of TOP-BUILD-DIR/out-www/offline-root into what > what RPM should unpack into /usr/share/doc/lilypond-VERSION/html *and* > reproduce what install-doc does to install info-doc; for the last item, > the simplest way is to see the commands issued when invoking 'make > install-doc' (roughly copying .info files, calling install-info and > creating the two symlinks to HTML docs images directories). > > Thank you again for raising this packaging issue, > John > Thanks that's the info I need, I use rpmbuild --short-circuit to fine tune where the files go, I've got a mere celeron E1200 1.6GHz with 1GB ram and I haven't timed it yet but it seems to take about an hour, haven't tried parallel jobs yet, I've only got two cores. Once the final product build in the build service, it won't be so much of a problem. Regards Dave P ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG addition about Git pulling
John Mandereau wrote: > Could you consider adding something like the following to > Git pulling instructions? Maybe this could be under a > @knownissues section (or "Troubleshooting") at the bottom > of the the node "Update command". Sure thing. By the way, I had less time than expected last week, but I still got some stuff done. Maybe by this weekend I'll be able to post a rough draft of the Git stuff. We'll see. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG addition about Git pulling
On Mon, Jan 04, 2010 at 08:58:11PM -0800, Mark Polesky wrote: > John Mandereau wrote: > > Could you consider adding something like the following to > > Git pulling instructions? Maybe this could be under a > > @knownissues section (or "Troubleshooting") at the bottom > > of the the node "Update command". > > By the way, I had less time than expected last week, but I > still got some stuff done. Maybe by this weekend I'll be > able to post a rough draft of the Git stuff. Could we get the new introduction chapter added? I've been wanting to add the info about lilypond mentors for a while, but I don't want to add a new chapter filled with stubs if you're going to add the same new chapter filled with real sections. I think everybody liked the idea of the intro chapter, even if there's slight uncertainty over one section of it (i.e. lily-git). Let's get the part(s) that everybody agrees with done. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly: Normalize versions to three-entry tuples before comparing (issue183097)
LGTM if the two nitpicks are adressed.
http://codereview.appspot.com/183097/diff/4/1002
File scripts/convert-ly.py (right):
http://codereview.appspot.com/183097/diff/4/1002#newcode213
scripts/convert-ly.py:213: class InvalidVersion:
this class should be subclassed from a basic Exception class, e.g.
"class InvalidVersion (Exception):". Idem for the two exception classes
défined above, although they aren't normally affected by this patch.
http://codereview.appspot.com/183097/diff/4/1002#newcode323
scripts/convert-ly.py:323: error (_ ("invalid version string `%s' found
in `%s'. \n"
A more common wording of such an error message would be
"%s: %s: invalid version string\n" % (f, ex.version)
or maybe
"%s: invalid version string `%s'\n" % (f, ex.version)
http://codereview.appspot.com/183097
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
