Re: GOP pre-planning: Frog bugfixing
2008/12/12 Eyolf Østrem ey...@oestrem.com: I don't know about the devs -- you're probably right that to them, new features are more interesting -- but THIS user sticks with LilyPond because the output is superb. As it is, LP deals with 99% of the western music notation canon, and to me, the perfectioning of that is far more important than filling in the remaining %. Also, a higher priority for me would be to simplify input for the 30% which go beyond simple music expressions and where scheme or fiddling with grob properties are required. Eyolf: I think we agree on the need for more simplification, and if you look at the feature requests, a lot of them are actually about simpler input syntax rather than about adding exotic whole-new features. - for instance, a major feature request is to make LilyPond+editor easier to install and to understand under Windows. - another example: it would be nice to have one single command to start a TextSpanner without having to \override TextSpanner #'bound-details #'left #'text (I've already been working quite a lot on this particular one). So when I say we should make requesting features and taking them into account easier, I am also advocating for actually improving the existing software. Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A naive question about permissions in buildscripts/
OK, I buy your idea, but the involved changes are invasive and will also require changes in GUB. I'll do my best to keep everything working thanks to testing and greping through the sources, but I may miss some details -- you have been warned. :-) A new build will show all the problems. I've started creating auxscripts/ (for scripts that needn't be built) and auxpython/ (for Python modules that needn't be built), and I'll commit as soon as I can't find remaining breakages. Someone this list (Graham?) made the suggestion to move all script subdirs into the `script' directory to avoid cluttering of lilypond's top-level directory... Thanks in advance for your work. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP pre-planning: Frog bugfixing
My impression is that we have more people doing bug fixes now than a couple of years ago (at that time it was primarily Han-Wen and Jan), but that the number of fixed bugs per week and bug fixer is lower. On the other hand, the number of newly introduced bugs (not to be confused with the number of discovered bugs) per week is also much lower now than a couple of years ago, when we had a new minor release at least once a week. /Mats Graham Percival wrote: LilyPond Frogs No, this isn't my new name for the French translation team. :) Frogs will be a team of bug-fixers (because frogs eat bugs, and you often find them in Ponds of Lilies). We've gotten relatively good about new bug reports -- maybe 1/3 of new reports result in a patch within a week or two. However, there's still a backlog of over 200 bugs. The idea behind Frogs is simple: each person will fix an average of one bug per week. You can either fix an existing bug, or report a new bug and fix it. We won't quibble over the severity of the bug; if a new Frog (Tadpole? ;) is only comfortable fixing program errors or similar false warning messages, those will still count towards his 1 bug per week average. If you feel skilled and ambitious, go ahead and fix the dreaded #34 in a week. :) New Frogs will send patches to the FrogMeister for approval; he will ensure that there's no obvious mistakes (both logic and code style) before they create a codereview.appspot issue for review from -devel as a whole. He will also serve as a mentor to inexperienced developers who may feel shy about sending unreviewed patches to -devel directly. I'm hesitated slightly about proposing this since I'm not qualified to be the FrogMeister. I have 3 or 4 candidates in mind, but I don't want to name names since I don't know if they're interested/willing. I'm guessing that the FrogMeister will do about 5 hours of work per week in the beginning, scaling down to 2 hours once everybody knows what they're doing. That's not counting the normal 10 hours of mailing list reading/writing, whatever bug fixes or doc work he does himself, etc. As a final hint, any doc person who is willing to switch to being the FrogMeister has my enthusiastic support. I know that I discouraged you guys from doing coding during GDP, but that fixed-term project is over, and fostering more code developers is more important now. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel -- = Mats Bengtsson Signal Processing School of Electrical Engineering Royal Institute of Technology (KTH) SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: mats.bengts...@ee.kth.se WWW: http://www.s3.kth.se/~mabe = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
gub3 build failure
Problem building the netpbm package. gcc doesn't seem to
recognize the -flax-vector-conversions option, but doens't gub
download gcc itself to avoid specific-version compiler problems?
Log attached.
Cheers,
- Graham
must rebuild[linux-x86]: tools::netpbm tools::curl tools::expat tools::git
gettext tools::flex zlib libpng tools::gmp tools::bison expat tools::python
python freetype tools::freetype fontconfig glib pango tools::texi2html
tools::libxml2 tools::gettext tools::rsync tools::guile guile libjpeg
ghostscript urw-fonts tools::fontforge tools::t1utils tools::bzip2
tools::fontconfig tools::ghostscript tools::imagemagick lilypond
*** Stage: pkg_install (cross/gcc-core, linux-x86)
*** Stage: pkg_install (glibc-core, linux-x86)
building package: tools::netpbm
*** Stage: untar (netpbm, tools)
*** Stage: patch (netpbm, tools)
*** Stage: autoupdate (netpbm, tools)
*** Stage: configure (netpbm, tools)
*** Stage: compile (netpbm, tools)
Command barfed: cd /home/lilypond/gub/target/tools/build/netpbm-10.35 make
CC=gcc CFLAGS='-O2 -fPIC -flax-vector-conversions' LDFLAGS='-Wl,-rpath
-Wl,\$$ORIGIN/../lib -L/home/lilypond/gub/target/tools/build/netpbm-10.35/pbm
-L/home/lilypond/gub/target/tools/build/netpbm-10.35/pgm
-L/home/lilypond/gub/target/tools/build/netpbm-10.35/pnm
-L/home/lilypond/gub/target/tools/build/netpbm-10.35/ppm' LADD=-lm
LINUXSVGALIB=NONE XML2LD=NONE XML2_LIBS=NONE XML2_CFLAGS=NONE X11LIB=NONE
Tail of target/linux-x86/log/build.log
If you don't know what this means, take the default or see doc/INSTALL
regular or merge [regular] ==
Do you want libnetpbm to be statically linked or shared?
static or shared [shared] ==
What header file defines uint32_t, etc.?
(Doing test compiles to choose a default for you -- ignore errors)
Doing test compile: cc -c -o /tmp/netpbm0.o /tmp/netpbm0.c
'#include' argument or NONE [inttypes.h] == (Doing test compiles to
determine if you have int64 type -- ignore errors)
Doing test compile: cc -c -o /tmp/netpbm0.o /tmp/netpbm0.c
You do.
Doing test compile: cc -c -o /tmp/netpbm0.o /tmp/netpbm0.c
The following questions concern the subroutine libraries that are Netpbm
prerequisites. Every library has a compile-time part (header files)
and a link-time part. In the case of a shared library, these are both
part of the development component of the library, which may be separately
installable from the runtime shared library. For each library, you must
give the filename of the link library. If it is not in your linker's
default search path, give the absolute pathname of the file. In addition,
you will be asked for the directory in which the library's interface headers
reside, and you can respond 'default' if they are in your compiler's default
search path.
If you don't have the library on your system, you can enter 'none' as the
library filename and the builder will skip any part that requires that library.
What is your JPEG (graphics format) library?
library filename or 'none' [libjpeg.so] == Where are the interface headers for
it?
JPEG header directory [default] ==
What is your TIFF (graphics format) library?
library filename or 'none' [libtiff.so] == Where are the interface headers for
it?
TIFF header directory [default] ==
What is your Z (compression) library?
library filename or 'none' [libz.so] == Where are the interface headers for it?
Z header directory [default] ==
What is your X11 (X client) library?
library filename or 'none' [/usr/lib/libX11.so] == Where are the interface
headers for it?
X11 header directory [default] ==
What is your Svgalib library?
library filename or 'none' [libvga.so] == Where are the interface headers for
it?
Svgalib header directory [default] ==
What URL will you use for the main Netpbm documentation page?
This information does not get built into any programs or libraries.
It does not make anything actually install that web page.
It is just for including in legacy man pages.
Documentation URL [http://netpbm.sourceforge.net/doc/] ==
Doing test compile: cc -c -o /tmp/netpbm0.o /tmp/netpbm0.c
Doing test compile: cc -c -o /tmp/netpbm0.o /tmp/netpbm0.c
Doing test compile: cc -c -o /tmp/netpbm0.o
-I/home/lilypond/gub/target/tools/root/usr/include /tmp/netpbm0.c
We have created the file 'Makefile.config'. Note, however, that
we guessed a lot at your configuration and you may want to look
at Makefile.config and edit it to your requirements and taste
before doing the make.
Now you may proceed with 'make'
Running dump_file
('3',
'/home/lilypond/gub/target/tools/status/netpbm-10.35-netpbm-patched-10.35', 'w')
{'permissions': 420}
*** Stage: compile (netpbm, tools)
invoking cd /home/lilypond/gub/target/tools/build/netpbm-10.35 make CC=gcc
CFLAGS='-O2 -fPIC -flax-vector-conversions' LDFLAGS='-Wl,-rpath
-Wl,\$$ORIGIN/../lib -L/home/lilypond/gub/target/tools/build/netpbm-10.35/pbm
-L/home/lilypond/gub/target/tools/build/netpbm-10.35/pgm
Re: A naive question about permissions in buildscripts/
On Fri, Dec 12, 2008 at 11:25:44AM +0100, Werner LEMBERG wrote: I've started creating auxscripts/ (for scripts that needn't be built) and auxpython/ (for Python modules that needn't be built), and I'll commit as soon as I can't find remaining breakages. Someone this list (Graham?) made the suggestion to move all script subdirs into the `script' directory to avoid cluttering of lilypond's top-level directory... Yes. We'll probably do the same thing with ly/ (split into ly/builtin and ly/utils/). However, might it be an idea to wait a week or so? I'd like to get 2.12 out ASAP, and this kind of directory reshuffling sounds like the kind of thing that could delay things. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP pre-planning: Frog bugfixing
On Fri, Dec 12, 2008 at 01:09:53PM +0100, Mats Bengtsson wrote: My impression is that we have more people doing bug fixes now than a couple of years ago (at that time it was primarily Han-Wen and Jan), but that the number of fixed bugs per week and bug fixer is lower. Oh, definitely -- but I think the project is much healthier now. Back then, if Han-Wen or Jan were hit by a bus or took a commercial job (the two leading causes of death for open-source developers :), development would stall almost entirely, and the next generation would have a much harder time getting started. Now we have half a dozen people with a decent understanding of lilypond's internal architecture, so if anything happened to one of them, it wouldn't derail things as much. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
It uses compiled GCC for the cross compiler, but 'local' packages (like netpbm) get compiled with local GCC. As a workaround, you can installn netpbm from the distribution and disable it in gub. On Fri, Dec 12, 2008 at 12:18 PM, Graham Percival gra...@percival-music.ca wrote: Problem building the netpbm package. gcc doesn't seem to recognize the -flax-vector-conversions option, but doens't gub download gcc itself to avoid specific-version compiler problems? Log attached. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 12. Dezember 2008 schrieb Han-Wen Nienhuys: It uses compiled GCC for the cross compiler, but 'local' packages (like netpbm) get compiled with local GCC. As a workaround, you can installn netpbm from the distribution and disable it in gub. On Fri, Dec 12, 2008 at 12:18 PM, Graham Percival gra...@percival-music.ca wrote: Problem building the netpbm package. gcc doesn't seem to recognize the -flax-vector-conversions option, but doens't gub download gcc itself to avoid specific-version compiler problems? Log attached. It seems that this version of netpbm needs quite a recent compiler (i.e. gcc 4.2.4 from KUbuntu hardy does NOT work!). I've tried it on my office machine, running KUbuntu intrepid with gcc 4.3.2, and there the netpbm package worked just fine. I've planned to upgrade my server to intrepid anyway, so this is just one more reason to do it now... Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQoOkTqjEwhXvPN0RAs1wAJ9nEz/KYrzsWTz/KDVfDx7yNLncEgCggFSj m5morcE7etVmrTxqbzJxe1E= =UFt+ -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Hi Werner, Hehe, still not perfect. Sorry for being such a PITA :-) If you weren't, I'd ask you to be. ;-) Lilypond wouldn't be what it is if it weren't for people like Han-Wen, you and the other developers who aim for the highest possible quality standards. Vice versa I apologize for giving you so much opportunity to discover bugs and buglets. ;-) The `natural.arrowdown' glyph correctly extends the vertical bar outlines into exactly the same direction, while the `natural.arrowboth' extends the stem into a slightly different direction, which is not correct. I noticed this, too, but I thought it was due to rounding errors caused by metafont since I passed exactly the same direction as an argument for both glyphs. I now made a correction which I hope fixes this issue but please double check to be sure. Additionally, the upper left point of the lower horizontal bar `jumps' if compared between natural glyphs with and without an up-arrow. The same is true for the lower right point of the upper horizontal bar for glyphs with and without a down-arrow. This is fixed in the attached revised version of the patches. Please let further suggestions be coming. :-) Thanks and best regards, Max patch_arrowed_accidentals.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
set accidental style in \layout block?
Is there a way to set the accidental style in the layout block?
If not, shouldn't there be? Something like...
\layout {
\context {
\Score
accidentalStyle = #'modern
}
}
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: set accidental style in \layout block?
2008/12/12 Mark Polesky markpole...@yahoo.com:
Is there a way to set the accidental style in the layout block?
Yes :
\layout {
\context { \Score % or Staff, or Voice
autoAccidentals = #yourstyle
autoCautionaries = #yourotherstyle
}
}
yourstyle may be one of the predefined styles (have a look at
music-functions.scm) or a custom style, such as
`(Staff ,(make-accidental-rule 'same-octave 0)
,(make-accidental-rule 'any-octave 0)
,(make-accidental-rule 'same-octave 1)
,neo-modern-accidental-rule))
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: set accidental style in \layout block?
My goodness, Valentin, I would never have figured that out. Is this described in the docs somewhere? It should be. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: set accidental style in \layout block?
Does anyone think it would be worth adding the
syntactic sugar to allow this?
\layout {
\context {
\Score
accidentalStyle = #'modern
}
}
or this?
\layout {
#(layout-set-accidental-style 'modern)
}
as opposed to the current method (as I understand it):
modern = #`(Staff ,(make-accidental-rule 'same-octave 0)
,(make-accidental-rule 'any-octave 0)
,(make-accidental-rule 'same-octave 1))
\score {
{ ... }
\layout {
\context {
\Score
autoAccidentals = #modern
autoCautionaries = #modern
}
}
}
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Short tick as a bar line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's a patch that adds ticked barlines (i.e. a tick of the length of a staff
space through the top-most staffline):
http://codereview.appspot.com/10645
Please review.
Unfortunately, I'm running into one problem: It seems that for each barline in
a staff group the function is called multiple times and the resulting stencil
also shifted differently. In particular, for all staves except the last in a
staff group a tick is created through both the top-most and the bottom-most
staff line. An example is attached. Any idea what is going on here?
Cheers,
Reinhold
- --
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung Jung-Wien, http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFJQvQDTqjEwhXvPN0RAtevAJ9E24aMOmIEGA5GKyN618qjzuSv2wCePp1l
Z0X3/eiCWjoQSVyQ9W/98zo=
=zNhB
-END PGP SIGNATURE-
\header { texidoc = A ticked bar line is a short line of the same length as a
staff space, centered on the top-most barline. }
\version 2.11.65
\paper { ragged-right = ##t }
\relative \new StaffGroup
\new Staff {
c4 \bar ' c }
\new Staff {
c c
}
bar-line-tick.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 12. Dezember 2008 19:41:44 schrieb Galen Toews: I cannot find how to produce a thick bar. As far as I can seen in the code in bar-line.cc, there is currently no way to create a single thick bar line. In compound barlines, a thick line is indicated by a dot (e.g. |.), but using only a single dot (like in \bar .) is implemented to create a single dot... Question to the other developers: Should we change \bar . to create a single thick barline for reasons of consistency and instead add a new bar line style \bar dot to create a single dot as a bar line? If not, what would be the best way to indicate a single thick bar line? Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQvSdTqjEwhXvPN0RAuKbAKCQqeen/MZ37mH+yRn/9AxaFxN4tACgnYop Jy7NSk1AAmDc2uexA7jkqKc= =3p8D -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A naive question about permissions in buildscripts/
Le vendredi 12 décembre 2008 à 06:21 -0800, Graham Percival a écrit : On Fri, Dec 12, 2008 at 11:25:44AM +0100, Werner LEMBERG wrote: Someone this list (Graham?) made the suggestion to move all script subdirs into the `script' directory to avoid cluttering of lilypond's top-level directory... Yes. Good idea, but I'd rather move the least number of scripts to minimize the burden of checking and fixing the makefiles and scripts and the possible temporary confusion in developers mind caused by all this moving, so I propose to keep current files in scripts/ and python/, and add new directories: - python/aux for Python modules that needn't be built, - scripts/aux for maintenance scripts (that needn't be built), - scripts/build for scripts that need to be built. However, might it be an idea to wait a week or so? I'd like to get 2.12 out ASAP, and this kind of directory reshuffling sounds like the kind of thing that could delay things. Agreed. I'll push changes for this just after 2.12.0 release. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Short tick as a bar line
2008/12/12 Reinhold Kainhofer reinh...@kainhofer.com: Unfortunately, I'm running into one problem: It seems that for each barline in a staff group the function is called multiple times and the resulting stencil also shifted differently. In particular, for all staves except the last in a staff group a tick is created through both the top-most and the bottom-most staff line. An example is attached. Any idea what is going on here? A span bar. :) You need to suppress it in Span_bar::calc_glyph_name (). Apart from this, LGTM. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/10 Han-Wen Nienhuys hanw...@gmail.com:
Some random comments:
Thanks for these suggestions! They are implemented in the attached
patches. Please let me know if you'd like some further corrections.
- have a look at scm/script.scm to set defaults just for staccato.
Following Neil's suggestions, I set the default for staccato to 0.5
and left all other scripts alone.
- shifted suggests a boolean property. toward-stem-shift ?
Renamed.
- do not use 'pos' - it's the name for vertical offsets in half staffspace.
OK. Lacking a better idea, I chose note-head-location and
stem-location instead. I hope it's not too clumsy.
- use explicit type checks (ie. number? rather than (not null?))
The number check was eliminated by Neil's suggestion to use a default value.
I now use ly:grob? to check whether a stem grob exists.
-(if (equal? dir1 dir2) can move to before the stem-pos init
Done.
- add a regtest. Should be short, with a short doc string explaining
the functionality.
Done (patch #2). I hope it meets the requirements for a regtest.
Please let me know if anything is missing or wrong.
Max
From 3cb4d8d3c53d318c6a388bd325382975c077f8af Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:52:27 +0100
Subject: [PATCH] New grob-property 'shifted-towards-stem (allows scripts to be placed anywhere between the note head and the stem)
---
lily/script-interface.cc |1 +
scm/define-grob-properties.scm |4
scm/output-lib.scm | 19 ++-
scm/script.scm |1 +
4 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index a525500..af2b8f9 100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -129,6 +129,7 @@ ADD_INTERFACE (Script_interface,
positioning-done
script-priority
script-stencil
+ toward-stem-shift
slur
slur-padding
);
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index b697af3..d9e5691 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -551,6 +551,10 @@ value @code{-1} means left aligned, @code...@tie{}centered, and
values may also be specified.)
(self-alignment-Y ,number? Like @code{self-alignment-X} but for
the y...@tie{}axis.)
+ (toward-stem-shift ,number? Amount by which scripts are shifted
+toward the stem if their direction coincides with the stem direction.
+...@code{0.0} means keep the default position (centered on the note head),
+...@code{1.0} means centered on the stem. Interpolated values are possible.)
(shorten-pair ,number-pair? The lengths to shorten a
text-spanner on both sides, for example a pedal bracket. Positive
values shorten the text-spanner, while negative values lengthen it.)
diff --git a/scm/output-lib.scm b/scm/output-lib.scm
index b93edda..1b231d4 100644
--- a/scm/output-lib.scm
+++ b/scm/output-lib.scm
@@ -669,4 +669,21 @@ centered, X==1 is at the right, X == -1 is at the left.
(define-public (script-interface::calc-x-offset grob)
(ly:grob-property grob 'positioning-done)
- (ly:self-alignment-interface::centered-on-x-parent grob))
+ (let* ((shift (ly:grob-property grob 'toward-stem-shift 0.0))
+ (note-head-location (ly:self-alignment-interface::centered-on-x-parent grob))
+ (note-head-grob (ly:grob-parent grob X))
+ (stem-grob (ly:grob-object note-head-grob 'stem)))
+(+ note-head-location
+ ;; If the property 'toward-stem-shift is defined and the script has the
+ ;; same direction as the stem, move the script accordingly. Since scripts can
+ ;; also be over skips, we need to check whether the grob has a stem at all.
+ (if (ly:grob? stem-grob)
+ (let ((dir1 (ly:grob-property grob 'direction))
+ (dir2 (ly:grob-property stem-grob 'direction)))
+ (if (equal? dir1 dir2)
+ (let* ((common-refp (ly:grob-common-refpoint grob stem-grob X))
+ (stem-location (ly:grob-relative-coordinate stem-grob common-refp X)))
+ (* shift (- stem-location
+ note-head-location)))
+ 0.0))
+ 0.0
diff --git a/scm/script.scm b/scm/script.scm
index eb2fad5..5e2a2a9 100644
--- a/scm/script.scm
+++ b/scm/script.scm
@@ -111,6 +111,7 @@
(side-relative-direction . -1)
(quantize-position . #t)
(avoid-slur . inside)
+ (toward-stem-shift . 0.5)
(padding . 0.20)
(script-priority . -100)))
(tenuto .
--
1.5.4.3
From d310eaa9789aafb5e6f09d2e6baa20adba0bf72c Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:42:22 +0100
Subject: [PATCH] Add regression test for 'toward-stem-shift property
---
input/regression/script-shift.ly | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 input/regression/script-shift.ly
diff --git a/input/regression/script-shift.ly
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
On Fri, Dec 12, 2008 at 10:20 PM, Maximilian Albert maximilian.alb...@googlemail.com wrote: u - add a regtest. Should be short, with a short doc string explaining the functionality. Done (patch #2). I hope it meets the requirements for a regtest. Please let me know if anything is missing or wrong. No need to test 3 values, 0.0 and != 0.0 should be enough. Be sure to test both stem up and stem down. Use only 1 note for each situation (or, if you need to test beams, 2). -- 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
[PATCHES] Re: Short tick as a bar line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 13. Dezember 2008 00:55:11 schrieb Neil Puttock: 2008/12/12 Reinhold Kainhofer reinh...@kainhofer.com: Unfortunately, I'm running into one problem: It seems that for each barline in a staff group the function is called multiple times and the resulting stencil also shifted differently. In particular, for all staves except the last in a staff group a tick is created through both the top-most and the bottom-most staff line. An example is attached. Any idea what is going on here? A span bar. :) You need to suppress it in Span_bar::calc_glyph_name (). Ah, that makes sense! For the space between staves in a staff group, the Span_bar uses also a BarLine object of the same type, so it's actually a tick through the top-most virtual staff line of the space between the staves... Okay, I uploaded a new patch: http://codereview.appspot.com/10645/show Now I set the bar line type for the span bar to . Is this the correct way? Or should I rather completely suicide the object? Cheers, Reinhold PS: I suppose that the dot bar style ( \bar. ) should also remove the span bar... To be honest, I have no idea what the purpose of the . bar style is, so I also don't know how it should work across staff groups. It was addd ages ago by hanwen (with an empty log message on 2005-11-29, right after 2.7.15), but it is nowhere documented or used... Unless someone has a good reason, I thus propose to use \bar . for a thick bar line instead. Patch is here: http://codereview.appspot.com/11044 Please review - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQwZZTqjEwhXvPN0RAmWgAKCcpKMBGSVttMvDm2K5JU/3bK2xhgCfY16b m4x2LNARlHqE3OAf4zCoWAI= =FmOs -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a server with a 64-bit processor, on which I have installed a 32-bit Linux distribution (so I can reuse all my 32-bit self-created packages, among other reasons). Now, Graham is trying to use that server also as a build machine for lilypond releases. Unfortunately, gmp does not build there, since the configure check seems to think it is on a 64-bit platform: checking size of mp_limb_t... 4 configure: error: Oops, mp_limb_t is 32 bits, but the assembler code in this configuration expects 64 bits. You appear to have set $CFLAGS, perhaps you also need to tell GMP the intended ABI, see ABI and ISA in the manual. Command barfed: cd /home/lilypond/gub/target/tools/build/gmp-4.2.1 chmod +x /home/lilypond/gub/target/tools/src/gmp-4.2.1/configure /home/lilypond/gub/target/tools/src/gmp-4 .2.1/configure --prefix=/home/lilypond/gub/target/tools/install/gmp-4.2.1- root/usr --prefix=/home/lilypond/gub/target/tools/root/usr --enable-shared -- enable-static CFLAGS=-I/hom e/lilypond/gub/target/tools/root/usr/include LDFLAGS=- L/home/lilypond/gub/target/tools/root/usr/lib LD_LIBRARY_PATH=/home/lilypond/gub/target/tools/root/usr/lib Any idea how to solve this problem? Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQwkCTqjEwhXvPN0RAuBNAKChRoxLljtskK0+SRt2GFt6LROEQQCbBnU8 TCVxZSV4h+IaC+k4nJ99TU4= =Y3+q -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond problems
On Fri, Dec 12, 2008, Reinhold Kainhofer reinh...@kainhofer.com said: Should we change \bar . to create a single thick barline for reasons of consistency and instead add a new bar line style \bar dot to create a single dot as a bar line? newbies dumb Q - will the switch impact extant user files? is there a way to do a broken barline? (maybe \bar . ) Historical editions often used vertical rows of dots intermixed with bars to mark sections (not always being repeated) as in |:| or :|: or :||: perhaps an experiment will clarify the useage? -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Samstag, 13. Dezember 2008 02:48:14 schrieb dem...@suffolk.lib.ny.us:
On Fri, Dec 12, 2008, Reinhold Kainhofer reinh...@kainhofer.com said:
Should we change \bar . to create a single
thick barline for reasons of consistency and instead add a new
bar line style \bar dot to create a single dot as a bar line?
newbies dumb Q - will the switch impact extant user files?
I don't think so. If you look at what \bar .produces, ie.
\version 2.11.65
\relative c' { c4 \bar. c4}
(image is attached) then you'll see that such a barline doesn't make much
sense at all.
is there a way to do a broken barline? (maybe \bar . )
You mean like \bar : for a dotted bar line or \bar dashed for a dashed bar
line?
See http://kainhofer.com/~lilypond/Documentation/user/lilypond/Bars.html#Bars
Historical editions often used vertical rows of dots intermixed with bars
to mark sections (not always being repeated) as in |:| or :|: or :||:
perhaps an experiment will clarify the useage?
I have never seen those yet. Are the dotted rows similar to the \bar : line?
If so, they are currently not possible in LilyPond anyway. \bar :|: and \bar
:||: produces a barline with repeating dots on both sides, not with four
dots...
Cheers,
Reinhold
- --
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung Jung-Wien, http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFJQxqLTqjEwhXvPN0RApv9AJ0VajApWfS4R3+XbmOWGiNxNMIs0QCghpPE
KOnEQJH6uZL8nRE4PZOtIHw=
=YSR8
-END PGP SIGNATURE-
a-crop.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: set accidental style in \layout block?
On Fri, Dec 12, 2008 at 03:09:12PM -0800, Mark Polesky wrote: My goodness, Valentin, I would never have figured that out. Is this described in the docs somewhere? It should be. Add it to LSR with the tag docs and whatever else you think it needs. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond problems
Question to the other developers: Should we change \bar . to create a single thick barline for reasons of consistency and instead add a new bar line style \bar dot to create a single dot as a bar line? I don't object, but I've never seen a single thick barline in the wild... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Please let further suggestions be coming. :-) No further suggestions. I've applied it to the git. Thanks! Please provide proper entries for NEWS.tely and other documentation files, together with a regression test (or extending an existing one). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
