Re: another wishlist item
Thomas Bushnell BSG wrote: So the availability of mensural and "gregorian" square-note notation in lilypond is great. Will we ever see diastematic neumes?! :) (Just pushing the envelope...) Actually, the ancient notation code was contributed by Juergen Reuter, and has been wilting a bit; since I don't quite understand what it is doing, it probably has accumulated bugs with all the refactoring going on. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Thomas Bushnell BSG wrote: I'm not looking for space-cheap for this; I'm making documents for publication and it's just fine if the PDF I give the printer is stunningly huge. Though since EPS is nonlossy and openoffice.org supports that too, I suppose I should do that! it's a more sensible idea anyway, since EPS files look better when they are scaled in either direction. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
another wishlist item
So the availability of mensural and "gregorian" square-note notation in lilypond is great. Will we ever see diastematic neumes?! :) (Just pushing the envelope...) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Erik Sandberg <[EMAIL PROTECTED]> writes: > If you print the document on a 1200 dpi printer, you must create > 1200 dpi PNGs to get full quality. I don't know what "full size" > means in terms of dpi, but if it means >=1200 dpi, then it should of > course be ok for most users (though the corresponding .eps might be > a smaller file). Oh, yeah, certainly. I'm not looking for space-cheap for this; I'm making documents for publication and it's just fine if the PDF I give the printer is stunningly huge. Though since EPS is nonlossy and openoffice.org supports that too, I suppose I should do that! Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Thomas Bushnell BSG wrote: Erik Sandberg <[EMAIL PROTECTED]> writes: PNGs suffer from limited resolution. It's probably wiser to include .eps or embedded .pdf files (perhaps pngs can be used as preview images, if that's needed). Why? If I generate a png at full size, how do I lose? What am I missing? The brushed stems eg. on the flat symbol need 1200 dpi or more. If you use the right resolution, you don't loose, but you get bulky -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
On Monday 24 October 2005 00.56, Thomas Bushnell BSG wrote: > Erik Sandberg <[EMAIL PROTECTED]> writes: > > PNGs suffer from limited resolution. It's probably wiser to include .eps > > or embedded .pdf files (perhaps pngs can be used as preview images, if > > that's needed). > > Why? If I generate a png at full size, how do I lose? What am I > missing? If you print the document on a 1200 dpi printer, you must create 1200 dpi PNGs to get full quality. I don't know what "full size" means in terms of dpi, but if it means >=1200 dpi, then it should of course be ok for most users (though the corresponding .eps might be a smaller file). -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Erik Sandberg <[EMAIL PROTECTED]> writes: > PNGs suffer from limited resolution. It's probably wiser to include .eps or > embedded .pdf files (perhaps pngs can be used as preview images, if that's > needed). Why? If I generate a png at full size, how do I lose? What am I missing? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
On Monday 24 October 2005 00.26, Thomas Bushnell BSG wrote: > It would be fun if (hint hint) there were a clever way to integrate > lilypond and openoffice.org. I know it's probably a nightmarish > proposal, so maybe not. Could be doable, see http://ooolatex.sourceforge.net/ a similar project for embedding LaTeX equations. This is probably a good package to base a lily mode on, if you're interested. (sounds like a great idea IMHO) > I just generate png files myself and include > them. PNGs suffer from limited resolution. It's probably wiser to include .eps or embedded .pdf files (perhaps pngs can be used as preview images, if that's needed). -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Debian lilypond
OK, I'm building and uploading a new lilypond version for Debian with the new patches that Jan Nieuwenhuizen helpfully provided. In addition, dropping TeX from the build dependencies will make many people happy. It would be fun if (hint hint) there were a clever way to integrate lilypond and openoffice.org. I know it's probably a nightmarish proposal, so maybe not. I just generate png files myself and include them. Thanks for all the work you guys do on an excellent and well-loved piece of software. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG wrote:
>>>ec-fonts-mftraced
>> Wait, you mean showed up and is now gone? What's it for anymore?
>> Why
>> did we ever have it? :)
>
> It was for Lily 2.4, which supported Latin1 encoding and fonts, but not
> unicode.
I see, so now that Unicode is supported, it's not relevant.
Does that mean that nobody will ever want ec-fonts-mftraced anymore?
(If so, I can drop the Debian package itself too.)
> No, Lily used to be linked against libkpathsea to locate TeX fonts, so
> it could determine dimensions of texts. This is no longer necessary with
> Pango. LilyPond now outputs PS directly, which you can include into TeX
> with \includegraphics{}. Supporting TeX (with all of its crappy support
> tools) was one of the major headaches of deploying LilyPond, and I'm
> very glad it's gone.
>
> If the manual suggests .tex is the default, then that would be a bug in
> the manual then; can you pinpoint it more exactly?
Let me check to make sure I have the right version of the manual. :)
I'll get back to you on that.
Thomas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond packaging
Thomas Bushnell BSG wrote: The INSTALL.txt says suggests the "International fonts" for building the website, which of course we want in the Debian package. These fonts are only needed to build the website, right, because the fonts in question get embedded into the images? Yup. specifically, utf-8.ly and xiao-haizi-guai-gaui.ly -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell BSG wrote:
ec-fonts-mftraced
Wait, you mean showed up and is now gone? What's it for anymore? Why
did we ever have it? :)
It was for Lily 2.4, which supported Latin1 encoding and fonts, but not
unicode.
libkpathsea3
tetex-bin
tetex-extra
are not requirement anymore. They may be useful, and are required
when using the (unsupported) TeX backend.
Ok; they were once used for processing the texinfo docs, right?
You say that the TeX backend is no longer supported (!). Why is this?
The manual still regards .tex output as the default output format and
plenty of users regard it as the expected thing.
No, Lily used to be linked against libkpathsea to locate TeX fonts, so
it could determine dimensions of texts. This is no longer necessary with
Pango. LilyPond now outputs PS directly, which you can include into TeX
with \includegraphics{}. Supporting TeX (with all of its crappy support
tools) was one of the major headaches of deploying LilyPond, and I'm
very glad it's gone.
If the manual suggests .tex is the default, then that would be a bug in
the manual then; can you pinpoint it more exactly?
We still have a .tex backend, but it's for TeX wizards that know what
they're doing without reading the manual.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond packaging
The INSTALL.txt says suggests the "International fonts" for building the website, which of course we want in the Debian package. These fonts are only needed to build the website, right, because the fonts in question get embedded into the images? Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes: > LilyPond no longer uses > > ec-fonts-mftraced Wait, you mean showed up and is now gone? What's it for anymore? Why did we ever have it? :) > I think the package > > musixtex-fonts > > does not exist and if it does, I cannot imagine any conflicts. The Debian package no longer includes this conflict. > Also, > as LilyPond does not use tex by default > > libkpathsea3 > tetex-bin > tetex-extra > > are not requirement anymore. They may be useful, and are required > when using the (unsupported) TeX backend. Ok; they were once used for processing the texinfo docs, right? You say that the TeX backend is no longer supported (!). Why is this? The manual still regards .tex output as the default output format and plenty of users regard it as the expected thing. >> Lilypond is such a great thing, I'm glad that finally Debian users >> will have an up-to-date package at least in Debian unstable. > > Thanks! Yes, that's great. And don't forget the Ubuntu users. Well, I can't support everyone. Ubuntu can copy Debian, but I can't simultaneously handle that. >> Oh, and a request: the debian/ directory in the tarballs that you all >> distribute isn't very helpful to me > > I always liked to distribute this for users to build their own deb > package [from CVS]. What do you think? Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell writes: > Anyway, with my patch (or equivalently with yours, I'm sure), lilypond > 2.6.3 is now in Debian. (Whew!) That's great, thanks a lot for your efforts. > I'm going to start going through the many Debian bug reports That's a good thing too. Btw, have you checked the dependencies? LilyPond no longer uses ec-fonts-mftraced I think the package musixtex-fonts does not exist and if it does, I cannot imagine any conflicts. Also, as LilyPond does not use tex by default libkpathsea3 tetex-bin tetex-extra are not requirement anymore. They may be useful, and are required when using the (unsupported) TeX backend. > Lilypond is such a great thing, I'm glad that finally Debian users > will have an up-to-date package at least in Debian unstable. Thanks! Yes, that's great. And don't forget the Ubuntu users. > Oh, and a request: the debian/ directory in the tarballs that you all > distribute isn't very helpful to me I always liked to distribute this for users to build their own deb package [from CVS]. What do you think? Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes: > Thomas Bushnell writes: > >> But now there's a new, more subtle, one. > > Fixed in CVS, see patch below. > > Thanks for the report (and sorry that this kludge survived in the > first place). Ah, I like. Many thanks. My patch was worse (to have an environment variable that, if set, forces running-from-gui? to return #f). I like this one more. :) Anyway, with my patch (or equivalently with yours, I'm sure), lilypond 2.6.3 is now in Debian. (Whew!) It took overcoming an mftrace bug or two, getting Debian's fontforge up-to-date (which required overcoming some other bugs!), finding and fixing the running-from-gui? kludge, and a whole host of other stuff. And, during the whole process, 2.6.4 got released... :) I'm going to start going through the many Debian bug reports filed against the Debian lilypond package now, many of which are very old and were reported against version 2.2 or older. I expect they are nearly all no longer real bugs. Then I'll upgrade to 2.6.4 or whatever is the latest on the branch. Lilypond is such a great thing, I'm glad that finally Debian users will have an up-to-date package at least in Debian unstable. Oh, and a request: the debian/ directory in the tarballs that you all distribute isn't very helpful to me, because I have a separate way of keeping track of what goes in there. It would suit me fine if it simply went away entirely; I'm not using it in my packages, and it may easily be confusing to others. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond puts a shared library in /usr/share
Thomas Bushnell writes:
> Lilypond installs a shared library in /usr/share, to wit:
Fixed in CVS, patch attached.
Jan.
Index: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.3836.2.43
diff -p -u -r1.3836.2.43 ChangeLog
--- ChangeLog 23 Oct 2005 19:04:01 - 1.3836.2.43
+++ ChangeLog 23 Oct 2005 19:15:00 -
@@ -3,6 +3,16 @@
* scm/lily.scm: Remove horrendous running-from-gui? kludge.
(lilypond-main): Redirect to gui-main if 'gui is set.
+ * scripts/midi2ly.py (datadir): Add libdir iso datadir to path,
+ for alternative installations kludging s/share/lib/g
+ LILYPONDPREFIX.
+
+ * SConstruct (libdir_package_version): Define.
+
+ * python/SConscript:
+ * python/GNUmakefile (INSTALLATION_OUT_DIR): Install binary .so
+ module in libdir.
+
2005-10-23 Erik Sandberg <[EMAIL PROTECTED]>
* scripts/lilypond-book.py: Backport bugfix by Mats Bengtsson.
Index: SConstruct
===
RCS file: /cvsroot/lilypond/lilypond/SConstruct,v
retrieving revision 1.79
diff -p -u -r1.79 SConstruct
--- SConstruct 21 Apr 2005 14:28:31 - 1.79
+++ SConstruct 23 Oct 2005 19:15:00 -
@@ -248,6 +248,8 @@ prefix = env['prefix']
bindir = os.path.join (prefix, 'bin')
sharedir = os.path.join (prefix, 'share')
libdir = os.path.join (prefix, 'lib')
+libdir_package = os.path.join (libdir, package.name)
+lidbir_package_version = os.path.join (libdir_package, version)
localedir = os.path.join (sharedir, 'locale')
sharedir_doc_package = os.path.join (sharedir, 'doc', package.name)
sharedir_package = os.path.join (sharedir, package.name)
Index: python/GNUmakefile
===
RCS file: /cvsroot/lilypond/lilypond/python/GNUmakefile,v
retrieving revision 1.8
diff -p -u -r1.8 GNUmakefile
--- python/GNUmakefile 16 Jun 2005 11:54:02 - 1.8
+++ python/GNUmakefile 23 Oct 2005 19:15:00 -
@@ -10,7 +10,7 @@ USER_LDFLAGS=
INSTALLATION_OUT_SUFFIXES=1
INSTALLATION_OUT_FILES=$(OUT_SO_MODULES)
-INSTALLATION_OUT_DIR=$(local_lilypond_datadir)/python
+INSTALLATION_OUT_DIR=$(local_lilypond_libdir)/python
INSTALLATION_OUT_DIR1=$(local_lilypond_datadir)/python
INSTALLATION_OUT_FILES1=$(OUT_PY_MODULES) $(OUT_PYC_MODULES)
Index: python/SConscript
===
RCS file: /cvsroot/lilypond/lilypond/python/SConscript,v
retrieving revision 1.2
diff -p -u -r1.2 SConscript
--- python/SConscript 18 Apr 2005 13:35:13 - 1.2
+++ python/SConscript 23 Oct 2005 19:15:00 -
@@ -11,3 +11,4 @@ pym
cm
install (cm + pym, env['sharedir_package_version'] + '/python')
+install (cm, env['libdir_package_version'] + '/python')
Index: scripts/midi2ly.py
===
RCS file: /cvsroot/lilypond/lilypond/scripts/midi2ly.py,v
retrieving revision 1.33
diff -p -u -r1.33 midi2ly.py
--- scripts/midi2ly.py 6 Jun 2005 14:27:42 - 1.33
+++ scripts/midi2ly.py 23 Oct 2005 19:15:00 -
@@ -30,12 +30,18 @@ import sys
# Users of python modules should include this snippet.
#
-# This soon to be removed for: import lilypond.lilylib as ly
libdir = '@local_lilypond_libdir@'
if not os.path.isdir (libdir):
libdir = '@lilypond_libdir@'
-sys.path.insert (0, os.path.join (libdir, 'python'))
+# ugh
+if os.environ.has_key ('LILYPONDPREFIX'):
+ datadir = os.environ['LILYPONDPREFIX']
+ while datadir[-1] == os.sep:
+ datadir= datadir[:-1]
+ libdir = datadir.replace ('/share/', '/lib/')
+
+sys.path.insert (0, os.path.join (libdir, 'python'))
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell writes:
> But now there's a new, more subtle, one.
Fixed in CVS, see patch below.
Thanks for the report (and sorry that this kludge survived in the first place).
Jan.
Index: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.3836.2.42
diff -p -u -r1.3836.2.42 ChangeLog
--- ChangeLog 23 Oct 2005 15:58:39 - 1.3836.2.42
+++ ChangeLog 23 Oct 2005 19:03:38 -
@@ -1,3 +1,8 @@
+2005-10-23 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * scm/lily.scm: Remove horrendous running-from-gui? kludge.
+ (lilypond-main): Redirect to gui-main if 'gui is set.
+
2005-10-23 Erik Sandberg <[EMAIL PROTECTED]>
* scripts/lilypond-book.py: Backport bugfix by Mats Bengtsson.
Index: lily/lily-parser-scheme.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/lily-parser-scheme.cc,v
retrieving revision 1.16
diff -p -u -r1.16 lily-parser-scheme.cc
--- lily/lily-parser-scheme.cc 22 Jun 2005 15:06:05 - 1.16
+++ lily/lily-parser-scheme.cc 23 Oct 2005 19:02:10 -
@@ -8,15 +8,16 @@
#include
+#include "file-name-map.hh"
#include "file-name.hh"
#include "file-path.hh"
-#include "main.hh"
-#include "lily-parser.hh"
-#include "warn.hh"
-#include "source.hh"
#include "lily-lexer.hh"
+#include "lily-parser.hh"
#include "ly-module.hh"
-#include "file-name-map.hh"
+#include "main.hh"
+#include "program-option.hh"
+#include "source.hh"
+#include "warn.hh"
/* Do not append `!' suffix, since 1st argument is not modified. */
LY_DEFINE (ly_set_point_and_click, "ly:set-point-and-click",
@@ -52,7 +53,7 @@ LY_DEFINE (ly_parse_file, "ly:parse-file
/* When running from gui, generate output in .ly source directory. */
if (output_name_global.is_empty ()
- && scm_call_0 (ly_lily_module_constant ("running-from-gui?")) == SCM_BOOL_T)
+ && ly_get_option (ly_symbol2scm ("gui")) == SCM_BOOL_T)
{
File_name f (file);
f.base_ = "";
Index: scm/lily.scm
===
RCS file: /cvsroot/lilypond/lilypond/scm/lily.scm,v
retrieving revision 1.367.2.3
diff -p -u -r1.367.2.3 lily.scm
--- scm/lily.scm 1 Aug 2005 15:14:46 - 1.367.2.3
+++ scm/lily.scm 23 Oct 2005 19:02:10 -
@@ -348,6 +348,9 @@ The syntax is the same as `define*-publi
(define-public (lilypond-main files)
"Entry point for LilyPond."
+ (if (ly:get-option 'gui)
+ (gui-main files))
+
(if (null? files)
(no-files-handler))
@@ -385,29 +388,12 @@ The syntax is the same as `define*-publi
(use-modules (scm editor))
-(define-public (running-from-gui?)
- (let ((have-tty? (isatty? (current-input-port
-;; If no TTY and not using safe, assume running from GUI.
-(cond
- ((eq? PLATFORM 'windows)
- ;; Always write to .log file.
- (if DOS #t
- ;; This only works for i586-mingw32msvc-gcc -mwindows
- (not (string-match "standard input"
- (format #f "~S" (current-input-port))
- ;; FIXME: using -dgui would be nice, but it does not work
- ((eq? PLATFORM 'foo-windows)
- (ly:get-option 'gui))
- ((eq? PLATFORM 'darwin) #f)
- (else
- (not have-tty?)
-
(define-public (gui-main files)
(if (null? files)
(gui-no-files-handler))
(let* ((base (basename (car files) ".ly"))
(log-name (string-append base ".log")))
-(if (not (running-from-gui?))
+(if (not (ly:get-option 'gui))
(ly:message (_ "Redirecting output to ~a...") log-name))
(ly:stderr-redirect log-name "w")
(ly:message "# -*-compilation-*-")
@@ -430,7 +416,3 @@ The syntax is the same as `define*-publi
(ly:message (_ "Invoking `~a'...") cmd)
(system cmd)
(exit 1)))
-
-(or (not (running-from-gui?))
-(ly:get-option 'safe)
-(define lilypond-main gui-main))
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Figured bass doc patch
John Mandereau wrote:
> Hello,
> Here's a patch for the figured bass docs. I tried to follow the "Hints
> for style".
Very sorry for the wasted bandwidth, here is really the patch now
Index: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.4208
diff -u -r1.4208 ChangeLog
--- ChangeLog 22 Oct 2005 07:31:34 - 1.4208
+++ ChangeLog 23 Oct 2005 15:51:00 -
@@ -1,3 +1,7 @@
+2005-10-23 John Mandereau <[EMAIL PROTECTED]>
+
+ * Documentation/user/instrument-notation.itely (Figured bass): describe new features
+
2005-10-22 Han-Wen Nienhuys <[EMAIL PROTECTED]>
* lily/main.cc: clarify --safe.
Index: Documentation/user/instrument-notation.itely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/instrument-notation.itely,v
retrieving revision 1.63
diff -u -r1.63 instrument-notation.itely
--- Documentation/user/instrument-notation.itely 21 Oct 2005 17:09:15 - 1.63
+++ Documentation/user/instrument-notation.itely 23 Oct 2005 15:51:03 -
@@ -3992,9 +3992,9 @@
<<
\context Voice { \clef bass dis4 c d ais g fis}
\context FiguredBass \figuremode {
-< 6 >4 < 7 >8 < 6+ [_!] >
+< 6 >4 < 7\+ >8 < 6+ [_!] >
< 6 >4 <6 5 [3+] >
-< _ >4 < 6 >4
+< _ >4 < 6 5/>4
}
>>
@end lilypond
@@ -4015,33 +4015,37 @@
@end lilypond
Accidentals are added when you append @code{-}, @code{!}, and @code{+}
-to the numbers
+to the numbers. A plus sign is added when you append @code{\+}, and
+diminished fifths and sevenths can be obtained with @code{5/} and @code{7/}
@example
-<4- 6+ 7!>
+<4- 6+ 7!> <5++> <3--> <7/> r <6\+ 5/>
@end example
@lilypond[quote,raggedright,fragment]
-\context FiguredBass
-\figuremode { <4- 6+ 7!> }
+\figures { <4- 6+ 7!> <5++> <3--> <7/> r <6\+ 5/> }
@end lilypond
-Spaces or dashes may be inserted by using @code{_}. Brackets are
+Spaces may be inserted by using @code{_}. Brackets are
introduced with @code{[} and @code{]}. You can also include text
strings and text markups, see @ref{Overview of text markup commands}.
@example
-< [4 6] 8 [_! 12] > < 5 \markup @{ + \number 6 @} >
+< [4 6] 8 [_! 12] > < 5 \markup @{ \number 6 \super (1) @} >
@end example
@lilypond[quote,raggedright,fragment]
\context FiguredBass
-\figuremode { < [4 6] 8 [_! 12] > < 5 \markup{ + \number 6 } > }
+\figuremode { < [4 6] 8 [_! 12] > < 5 \markup{ \tiny \number 6 \super (1)} > }
@end lilypond
+
It is also possible to use continuation lines for repeated figures,
@lilypond[verbatim,relative=1]
<<
- \new Staff { c4 c }
+ \new Staff {
+\clef bass
+c4 c c
+ }
\figures {
\set useBassFigureExtenders = ##t
<4 6> <3 6> <3 7>
@@ -4051,19 +4055,19 @@
The @code{FiguredBass} context doesn't pay attention to the actual
bass line. As a consequence, you may have to insert extra figures to
-get extender lines below all notes, eg.
-
+get extender lines below all notes, and you may have to add @code{\!}
+to avoid getting an extender line, eg.
[EMAIL PROTECTED], relative=1]
[EMAIL PROTECTED]
<<
\new Voice
- {
-\clef bass
-f16. g32 f16. g32 f16. g32 f16. g32
- }
\figures {
\set useBassFigureExtenders = ##t
-<6 4>4. <6 4>16. <6 4>32 <5 3>8 r
+<6 4->4. <6 4->16. <6 4->32 <5>8. r16 <6>8 <6\! 5->
+ }
+ {
+\clef bass
+f16. g32 f16. g32 f16. g32 f16. g32 f8. es16 d8 es
}
>>
@end lilypond
@@ -4083,6 +4087,22 @@
<4 6>4
@end example
+Accidentals and plus signs can appear after or before the numbers,
+depending on the @code{figuredBassAlterationDirection} and @code{figuredBassPlusDirection}
+properties
+
[EMAIL PROTECTED]
+ \figures {
+<6\+> <5+> <6 4-> r
+\set figuredBassAlterationDirection = #1
+<6\+> <5+> <6 4-> r
+\set figuredBassPlusDirection = #1
+<6\+> <5+> <6 4-> r
+\set figuredBassAlterationDirection = #-1
+<6\+> <5+> <6 4-> r
+ }
[EMAIL PROTECTED] lilypond
+
Although the support for figured bass may superficially resemble chord
support, it is much simpler. The @code{\figuremode} mode simply
@@ -4101,10 +4121,6 @@
@internalsref{BassFigureBracket}, and
@internalsref{BassFigureContinuation} objects and
@internalsref{FiguredBass} context.
-
[EMAIL PROTECTED]
-
-Slash notation for alterations is not supported.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Figured bass doc patch
Le dimanche 23 octobre 2005 à 18:09 +0200, John Mandereau a écrit : > Hello, > Here's a patch for the figured bass docs. I tried to follow the "Hints > for style". In general, I wonder whether the snippets should be > real-life examples (I mean, music that that sounds well when you play > it) or simply demonstrate Lily features. > > Please read the patch carefully, there are certainly English mistakes > and some other details. For example, I suppose > > "Bugs > > Slash notation for alterations is not supported." > > should be removed if "slash notation for alterations" means "slashed > numbers for diminished intervals", as they are now implemented ;-) > > I tested my changes; I had to run 'make web-clean' before 'make web' to > see the changes, which took a while. Is it possible to simply rerun > 'make web' to avoid rebuilding the docs from scratch? > > Regards with the patch now... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Figured bass doc patch
Hello, Here's a patch for the figured bass docs. I tried to follow the "Hints for style". In general, I wonder whether the snippets should be real-life examples (I mean, music that that sounds well when you play it) or simply demonstrate Lily features. Please read the patch carefully, there are certainly English mistakes and some other details. For example, I suppose "Bugs Slash notation for alterations is not supported." should be removed if "slash notation for alterations" means "slashed numbers for diminished intervals", as they are now implemented ;-) I tested my changes; I had to run 'make web-clean' before 'make web' to see the changes, which took a while. Is it possible to simply rerun 'make web' to avoid rebuilding the docs from scratch? Regards -- John Mandereau <[EMAIL PROTECTED]> ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
