gregorian chant improvement
Hello, I'm working on gregorian chant reprensentation for a project student in a graduate ingeneering school in France, and I have had a lot of discussion with a monk on it. My aim is to improve gregorian chant representation in free softwares for monk to use it. I read the latest version of the documentation and I saw a lot of changes since the previous one, this makes me hope that people are working on gregorian chant and it is I think a very good thing, because there is still a lot to do. The first thing I would like to say is that taking the table of neumes of Solesmes is good... for Solesmes books, but there are a lot of neumes used in a lot of books that do not appear in this table. I do not think it is a good idea to list them : I have a swiss book where 188 different neumes are listed (without figurae). So it seems very hard to count all neumes. But in my work with the monk we discovered that the most simple was to decompose neumes in simpler elements. We are able to list all the simple elements, and so we can make all possible neumes. It would be much simpler I think, than listing all possible neumes. It would also permit to put quilismas everywhere, not only in pes (they can be at any place in most of neumes). If you want more details about these simple elements tell me, I will translate a document I made about a XML schema for gregorian chant (in french on http://omega.enstb.org/eroux/doc_fr.pdf). A lot of details on it are in a document I made : http://omega.enstb.org/eroux/notation_en.pdf . I do not think this notation can be used in Lilypond (in fact no one responded to me so I do not really know...), but the philosophy is interesting I think. There are also things that are missing : In some score there are a lot of larger spaces (due to the translation from very ancient notation). (example in my document) In every gregorian chant score (I do not know any exception) there is a dropped initial, and small informations above the dropped initial. The alignment of lyrics under notes is... very bad in currend version. In fact the first note that corresponds to a syllable is above the fist vowel of this syllable (every neume corresponds to a syllable), except if it is a diphtong (the alignment is between the two vowels). This point is fundamental, it is for that reason that when I showed a Lilypond example to the monk I know he said it was horrible. Thank you by advance for an answer, -- Elie ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Page and line penalties
As far as I can tell, page and line penalties are used _only_ for forbidding and forcing page breaks. Is there much chance they will ever be used for anything else? If not, they could be replaced by booleans - this would make the breaking algorithms a bit easier. Also, there seems to be some confusion as to where the line break penalties are used. Paper_column_engraver interprets the penalty as a boolean anyway (when it is over 1). Of course, page turn penalties would need to be introduced because we (will) make a distinction between allowable and desirable page turns. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vocal music and beaming
Alle 09:48, mercoledì 22 marzo 2006, Marco Gusy ha scritto: (ignoring ties) I meant ignoring slurs, ties are ok ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
please spread release announcement
Hello! you can help promote lilypond by spreading the release announcement. * The HTML version is at http://lilypond.org/web/announce-v2.8.html * The text version is at http://cvs.savannah.gnu.org/viewcvs/*checkout*/workbook/press.txt?root=lilypond note that the text is UTF-8 ; take care with accented letters, eg. in Trevor's name. * Here are good places to announce the new release, News: comp.music.research comp.os.linux.announce comp.text.tex,rec.music.compose Mail: info-lilypond@gnu.org [EMAIL PROTECTED] linux-audio-dev@music.columbia.edu tex-music@icking-music-archive.org [EMAIL PROTECTED] [EMAIL PROTECTED] info-gnu@gnu.org [EMAIL PROTECTED] Web: lilypond.org freshmeat.net linuxfr.com http://www.apple.com/downloads harmony-central.com ([EMAIL PROTECTED]) linux audio blog versiontracker.com hitsquad.com http://www.svgx.org * If you report a release somewhere, please send a note to lilypond-devel to prevent double work. Thanks! -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vocal music and beaming
I don't really understand what you mean. If you don't want any connection between the lyrics and the notes, just skip \lyricsto and specify the duration of each syllable. If you want information from the lyrics to affect the notes, then you would still have to specify the duration of each syllable in the lyrics. Beaming is just one way to indicate melismas. Another common alternative is to use slurs. Therefore, \lyricsto treats both manual beams and slurs as melismas, by default. Yet another possibility is to insert \melisma ... \melismaEnd among the notes. Quoting Marco Gusy [EMAIL PROTECTED]: Alle 15:16, venerdì 17 marzo 2006, Marco Gusy ha scritto: By default, LilyPond supports the opposite, namely that when you use \lyricsto it interprets all manually inserted beams as melismas and only attach one syllable to each beam. But there's an issue: a melisma isn't always entirely tied in a beam (look at the example in my previous post, the Ma - - - beaming breaks every beat ). Anyway, think to a song with many 8th syllabes and many melismas (i.e. renaissance polyphony), it would be very tricky to manage the thing in the voice context, while the easier way should be to insert notes without specify beaming (and melismatas), add lyrics with dashes ( In vo -- ci -- fe -- ra - ti -- o -- _ _ ne) and apply the new rule 'break the beam before each new syllable' to automatic beaming. Could it be possible? Thanks Please answer i would like to sponsor the feature if it is possible... Question is is it possible to add a 'break beam on every new syllable' rule to automatic beaming beahviour in order to type correct vocal music only by using text and dashes in the lyrics contest? (no manual beams, no /melisma, ignoring ties) Thanks Marco ___ 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
Re: Vocal music and beaming
Marco Gusy wrote: I just want to obtain the correct beaming behaviour in vocal music (like in the sample image i sent) without getting mad beaming and melismaing by hand. The rule should simply be Break beam on every new syllable. Since lilypond implemented the auto-melisma using dashes in lyrics context, i think this little auto-unbeaming rule will improve much output fidelity to traditional engraving. -Traditional scores *always* separate each syllable in beaming -two syllables *never* are beamed together. -beaming is used only on the same syllable Yeah, i said the same thing in 3 different ways Now it's clear, i hope ;-) My point is that if you want LilyPond to break a beam whenever there is a new syllable, then it has to know how long each syllable is. If you use \lyricsto, then LilyPond figures out the duration of each syllable based on information in a music voice. In that process, it looks at beams and slurs to figure out if there are any melismas. If you want the beaming to be determined based on the syllables, then LilyPond needs some other method to figure out the duration of each syllable. How do you want that to work? /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB: error 404 osx-lilypad-0.2.tar.gz
Pedro Kröger wrote: I get a 404 not found error when make download tries to fetch http://lilypond.org/~hanwen/osx-lilypad-0.2.tar.gz. this happens with darcs up to this patch: Thu Mar 23 11:08:27 BRT 2006 [EMAIL PROTECTED] * document why NSIS_CONFIG_LOG is switched off. thanks. fixed. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book and included files
Lilypond-book doesn't seem to understand the include structure very well. That is, it's using the included files, but doesn't seem to know that it needs to rebuild the snippets if you change an included file. I'm working around this by removing all the snippets when I change anything, but obviously this is going to be a problem with large books. In the past, I've worked around this by not using included files, but I really want to be able to get score and parts from the same source. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Lily2.8.0-5 on Windows
Hi, I've just upgraded to version 2.8.0-5 on Windows. Firstly, it seems to be slower than the 2.7.x series, about the same speed as the old 2.6.x series. Secondly, could a compressed archive of the files installed by the installer be added as a target of the GUB? Alternatively, an option could be added to the installer to not install the python files (I've already got a Python installation that needs to be reset everytime). Aligorith _ Become a fitness fanatic @ http://xtramsn.co.nz/health ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Postscript Backend patches with lines fixed (hopefully)
It looks like my email client messed up the lines on the patches I
sent in. I'm trying again with a different one. Hope this works. I
also attached the patches, just in case. Note: I'm pretty sure these
changes won't break CID fonts, but it'd be a good idea to double check
that.
David Feuer
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/ps/music-drawing-routines.ps
2006-03-16 05:52:27.0 -0500
+++ music-drawing-routines.ps 2006-03-25 18:25:10.447408000 -0500
@@ -241,10 +241,7 @@
% JUNKME: Use color.
/draw_white_text % text scale font
{
- %font
- findfont
- %scale
- exch scalefont setfont
+ exch selectfont
1 setgray
0 0 moveto
%-0.05 -0.05 moveto
@@ -276,5 +273,19 @@
stroke
} bind def
+/printletter {
+ currentpoint
+ 3 2 roll
+ glyphshow
+ moveto
+} bind def
+/printglyphs {
+ -1 1
+ {
+ 3 mul -3 roll
+ printletter
+ rmoveto
+ }for
+}bind def
%end music-drawing-routines.ps
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/scm/framework-ps.scm
2006-03-20 19:45:18.0 -0500
+++ framework-ps.scm2006-03-25 18:25:43.875475200 -0500
@@ -42,8 +42,10 @@
(define font-list (ly:paper-fonts paper))
(define (define-font command fontname scaling)
(string-append
- / command { / fontname findfont
- (ly:number-string scaling) output-scale div scalefont } bind def\n))
+ / command { / fontname (ly:number-string scaling)
output-scale div selectfont } bind def\n))
+;(string-append
+; / command { / fontname findfont
+; (ly:number-string scaling) output-scale div scalefont } bind def\n))
(define (standard-tex-font? x)
(or (equal? (substring x 0 2) ms)
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/scm/output-ps.scm
2006-03-07 13:14:23.0 -0500
+++ output-ps.scm 2006-03-25 18:25:34.061363200 -0500
@@ -54,6 +54,21 @@
(define (ps-encoding text)
(escape-parentheses text))
+(define (round2 num)
+ (/ (round (* 100 num)) 100))
+
+(define (round4 num)
+ (/ (round (* 1 num)) 1))
+
+(define (str4 num)
+ (format #f ~f (round4 num)))
+
+(define (number-pair-string4 numpair)
+ (format #f ~f ~f (round4 (car numpair)) (round4 (cdr numpair
+
+(define (numbers-string4 numlist)
+ (apply string-append (map (lambda (x) (string-append (str4 x) ))
numlist)))
+
;; FIXME: lily-def
(define-public (ps-string-def prefix key val)
(string-append / prefix (symbol-string key) (
@@ -75,59 +90,61 @@
;; two beziers
(define (bezier-sandwich lst thick)
(string-append
- (string-join (map ly:number-pair-string lst) )
+ (string-join (map number-pair-string4 lst) )
- (ly:number-string thick)
+ (str4 thick)
draw_bezier_sandwich))
(define (char font i)
(string-append
- (ps-font-command font) setfont
- (\\ (ly:inexact-string i 8) ) show))
+ (ps-font-command font) ;
+(\\ (ly:inexact-string i 8) ) show))
(define (circle radius thick fill)
(format
- ~a ~a ~a draw_circle radius thick
+ ~f ~f ~a draw_circle (round4 radius) (round4 thick)
(if fill
true
false )))
(define (dashed-line thick on off dx dy)
(string-append
- (ly:number-string dx)
- (ly:number-string dy)
- (ly:number-string thick)
+ (str4 dx)
+ (str4 dy)
+ (str4 thick)
[
- (ly:number-string on)
- (ly:number-string off)
+ (str4 on)
+ (str4 off)
] 0 draw_dashed_line))
;; what the heck is this interface ?
(define (dashed-slur thick on off l)
(string-append
- (string-join (map ly:number-pair-string l) )
+ (string-join (map number-pair-string4 l) )
- (ly:number-string thick)
+ (str4 thick)
[
- (ly:number-string on)
+ (str4 on)
- (ly:number-string off)
+ (str4 off)
] 0 draw_dashed_slur))
+;; s/\.\([0-9]\{-}\)0* /\1 /g
+
(define (dot x y radius)
(string-append
- (ly:numbers-string
+ (numbers-string4
(list x y radius)) draw_dot))
(define (draw-line thick x1 y1 x2 y2)
(string-append
1 setlinecap 1 setlinejoin
- (ly:number-string thick) setlinewidth
- (ly:number-string x1)
- (ly:number-string y1) moveto
- (ly:number-string x2)
- (ly:number-string y2) lineto stroke))
+ (str4 thick) setlinewidth
+ (str4 x1)
+ (str4 y1) moveto
+ (str4 x2)
+ (str4 y2) lineto stroke))
(define (embedded-ps string)
string)
@@ -138,12 +155,10 @@
w-x-y-named-glyphs)
(format #f gsave
- /~a ~a ~a output-scale div scalefont setfont\n~a grestore
+ /~a ~a output-scale div selectfont\n~a grestore
postscript-font-name
- (if cid?
- /CIDFont findresource
- findfont)
size
+ (string-append
(apply
string-append
(map (lambda (item)
@@ -154,9 +169,12 @@
(g (cadddr item))
Re: GUB: darwin7-sdk
Pedro Kröger wrote: GUB asks for a darwin7-sdk-0.4.tar.gz file. where can I download it? I google for it but I found nothing useful. you should get it automatically if you do make download -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB: gub-builder.py fails to build flex
Pedro Kröger wrote: The command: python gub-builder.py -p local build flex fails because flex-2.5.4a.tar.gz unpacks to flex-2.5.4 (without the a) and gub-builder is trying to do: tar -C /home/kroger/devel/gub/target/local/src -zcf /home/kroger/devel/gub/uploads/local/flex-2.5.4a-src.local.gub flex-2.5.4a but the directory flex-2.5.4a doesn't exist. This is very strange. I can't duplicate this. Can you send the full build log? Are you using python 2.4 ? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some newbie troubles, especially with text
From: Mats Bengtsson [EMAIL PROTECTED] To: Graham Percival [EMAIL PROTECTED] Cc: Stephen [EMAIL PROTECTED]; lily-devel lilypond-devel@gnu.org Sent: Monday, March 20, 2006 4:09 PM Graham Percival wrote: On 20-Mar-06, at 8:18 AM, Stephen wrote: I don't think Rehearsal Marks are as flexible as \markup. There may still be a need to align markup text to barlines rather than just to notes. Rehearsal marks _are_ just \markup that is aligned to barlines. See Text marks (particularly in the 2.7 docs) Except that they only are typeset above the topmost stave, not above every stave in scores with multiples staves. /Mats That still works for Fine and D.C. al fine which must be right-aligned with the barline, but is usually on the topmost stave. Bottom line is we have a system that works for them, considering how flexible it needs to be anyway to cover all cases. The only generalization that we could make would be a version of \mark that right-aligns, allows markup of the last bar of a score, and uses a smaller font size by default (with a slightly smaller padding as well) than \mark uses. Stephen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Manual tie formatting, slight inconsistency
I am personally extremely grateful for all of the great changes in LilyPond's tie formatting code during these last many months: both the improvements in the default tie formatting and especially the new ability to override the default formatting with manual adjustments. I have thought of an inconsistency though which may confuse some people, especially new users of LilyPond. As of version 2.7.40 and now 2.8, users may now manually format single ties (between two notes, or chords which have just one note tied between them) in addition to entire tie columns between chords that have more than one tied note. The inconsistency is that in the case of single ties, the manual formatting command(s) *precede* the first of the two tied notes (or chords that have only a single note tied), whereas when manually formatting entire tie columns, the formatting commnd(s) are placed *between* the two tied chords-- Example for single tie formatting (in this case, using chords with only a single tied note between them)-- \once \override Tie #'staff-position = #2.5 c'' e''4 ~ a' e''4 Example for multiple tie (tie column) formatting between chords-- c'' e''4 ~ \once \override TieColumn #'tie-configuration = #'((0 . -1) (4.5 . 1)) c'' e''4 As you can see, for single ties the command is placed _before_ the two tied notes or chords, but for multiple simultaneous ties, the command is placed _between_ the two chords. Best wishes all, Steve D New Mexico US -- If you can't be a good example, then you'll just have to be a horrible warning. -Catherine Aird ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
slur between fingers
I would like to now if it is possible to type the change of fingers not only using the two numbers(i.e 5-1) but also adding a little slur above the two fingers. I found lots of score with the little slurs between fingers without dash Thanks Gianni Bertoni ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Improvements to Postscript backend (patches included)
I made some changes to the Postscript backend, making the output more
readable (especially for text), around 10% shorter, and, at least in theory,
also faster to interpret. These changes are just a start, but I hope they
help. I'd like to know if it might be possible to make the backend work at
a slightly higher level, which should allow much smaller files (e.g.,
Postscript could easily understand the concept of filled dotted quarter
note in current note font with upward stem 3 staff spaces long).
I'm not a master of diff, so let me know if the following aren't done right.
Diffs (made with -u) against the 2.8.0 source:
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/scm/framework-ps.scm
2006-03-20 19:45:18.0 -0500
+++ framework-ps.scm2006-03-25 18:25:43.875475200 -0500
@@ -42,8 +42,10 @@
(define font-list (ly:paper-fonts paper))
(define (define-font command fontname scaling)
(string-append
- / command { / fontname findfont
- (ly:number-string scaling) output-scale div scalefont } bind
def\n))
+ / command { / fontname (ly:number-string scaling)
output-scale div selectfont } bind def\n))
+;(string-append
+; / command { / fontname findfont
+; (ly:number-string scaling) output-scale div scalefont } bind
def\n))
(define (standard-tex-font? x)
(or (equal? (substring x 0 2) ms)
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/ps/music-drawing-routines.ps
2006-03-16 05:52:27.0 -0500
+++ music-drawing-routines.ps 2006-03-25 18:25:10.447408000 -0500
@@ -241,10 +241,7 @@
% JUNKME: Use color.
/draw_white_text % text scale font
{
- %font
- findfont
- %scale
- exch scalefont setfont
+ exch selectfont
1 setgray
0 0 moveto
%-0.05 -0.05 moveto
@@ -276,5 +273,19 @@
stroke
} bind def
+/printletter {
+ currentpoint
+ 3 2 roll
+ glyphshow
+ moveto
+} bind def
+/printglyphs {
+ -1 1
+ {
+ 3 mul -3 roll
+ printletter
+ rmoveto
+ }for
+}bind def
%end music-drawing-routines.ps
--- ../Installation
Programs/lilypond-2.8.0-src/lilypond-2.8.0/scm/output-ps.scm
2006-03-07 13:14:23.0 -0500
+++ output-ps.scm 2006-03-25 18:25:34.061363200 -0500
@@ -54,6 +54,21 @@
(define (ps-encoding text)
(escape-parentheses text))
+(define (round2 num)
+ (/ (round (* 100 num)) 100))
+
+(define (round4 num)
+ (/ (round (* 1 num)) 1))
+
+(define (str4 num)
+ (format #f ~f (round4 num)))
+
+(define (number-pair-string4 numpair)
+ (format #f ~f ~f (round4 (car numpair)) (round4 (cdr numpair
+
+(define (numbers-string4 numlist)
+ (apply string-append (map (lambda (x) (string-append (str4 x) ))
numlist)))
+
;; FIXME: lily-def
(define-public (ps-string-def prefix key val)
(string-append / prefix (symbol-string key) (
@@ -75,59 +90,61 @@
;; two beziers
(define (bezier-sandwich lst thick)
(string-append
- (string-join (map ly:number-pair-string lst) )
+ (string-join (map number-pair-string4 lst) )
- (ly:number-string thick)
+ (str4 thick)
draw_bezier_sandwich))
(define (char font i)
(string-append
- (ps-font-command font) setfont
- (\\ (ly:inexact-string i 8) ) show))
+ (ps-font-command font) ;
+(\\ (ly:inexact-string i 8) ) show))
(define (circle radius thick fill)
(format
- ~a ~a ~a draw_circle radius thick
+ ~f ~f ~a draw_circle (round4 radius) (round4 thick)
(if fill
true
false )))
(define (dashed-line thick on off dx dy)
(string-append
- (ly:number-string dx)
- (ly:number-string dy)
- (ly:number-string thick)
+ (str4 dx)
+ (str4 dy)
+ (str4 thick)
[
- (ly:number-string on)
- (ly:number-string off)
+ (str4 on)
+ (str4 off)
] 0 draw_dashed_line))
;; what the heck is this interface ?
(define (dashed-slur thick on off l)
(string-append
- (string-join (map ly:number-pair-string l) )
+ (string-join (map number-pair-string4 l) )
- (ly:number-string thick)
+ (str4 thick)
[
- (ly:number-string on)
+ (str4 on)
- (ly:number-string off)
+ (str4 off)
] 0 draw_dashed_slur))
+;; s/\.\([0-9]\{-}\)0* /\1 /g
+
(define (dot x y radius)
(string-append
- (ly:numbers-string
+ (numbers-string4
(list x y radius)) draw_dot))
(define (draw-line thick x1 y1 x2 y2)
(string-append
1 setlinecap 1 setlinejoin
- (ly:number-string thick) setlinewidth
- (ly:number-string x1)
- (ly:number-string y1) moveto
- (ly:number-string x2)
- (ly:number-string y2) lineto stroke))
+ (str4 thick) setlinewidth
+ (str4 x1)
+ (str4 y1) moveto
+ (str4 x2)
+ (str4 y2) lineto stroke))
(define (embedded-ps string)
string)
@@ -138,12 +155,10 @@
w-x-y-named-glyphs)
(format #f gsave
- /~a ~a ~a output-scale div scalefont setfont\n~a grestore
+ /~a ~a output-scale div selectfont\n~a grestore
Re: gregorian chant improvement
On Tue, 21 Mar 2006, Elie Roux wrote: Hello, I'm working on gregorian chant reprensentation for a project student in a graduate ingeneering school in France, and I have had a lot of discussion with a monk on it. My aim is to improve gregorian chant representation in free softwares for monk to use it. Hi, that sounds good. You are very welcome to help improving Lily's Gregorian chant implementation! I read the latest version of the documentation and I saw a lot of changes since the previous one, this makes me hope that people are working on gregorian chant and it is I think a very good thing, because there is still a lot to do. Lily's implementation of Gregorian chant unfortunately has been somewhat stagnating for the last three years. In particular, I have currently effectively no time to contribute (I hope this will change in a year or two). The first thing I would like to say is that taking the table of neumes of Solesmes is good... for Solesmes books, but there are a lot of neumes used in a lot of books that do not appear in this table. I do not think it is a good idea to list them : I have a swiss book where 188 different neumes are listed (without figurae). So it seems very hard to count all neumes. Exactly. The graphical Solesmes table in the documentation mainly serves as an example for a limited number, but still representative set of Gregorian ligatures. The textual table below the graphical table explains how to construct these examples by mapping the Gregorian ligatures to Lily's low-level Gregorian syntax. A higher-level syntax (very similar to that one in OpusTeX, but with a variable number of arguments) was planned, but never implemented (except for the (undocumented) \ligature command), mostly due to my lack of time to dive into the details on writing Scheme-based Lilypond macros. For a Lily/Scheme expert, it should be rather trivial to implement, just following the mapping of the textual table (but extending it to support variable number of arguments). But in my work with the monk we discovered that the most simple was to decompose neumes in simpler elements. This is exactly, what Lily's Gregorian chant implementation is based on. We are able to list all the simple elements, and so we can make all possible neumes. Lily does this already (unless there are bugs in the implementation). For the Solesmes neumes, the textual table in Sect. 7.7.10.2 shows how this is done. It would be much simpler I think, than listing all possible neumes. As just said, the table just lists examples, rather than all possible neumes. Maybe, this should be stated more clearly in the documentation. It would also permit to put quilismas everywhere, not only in pes (they can be at any place in most of neumes). This can already be done with the current implementation. If you want more details about these simple elements tell me, I will translate a document I made about a XML schema for gregorian chant (in french on http://omega.enstb.org/eroux/doc_fr.pdf). I just had a look at the neumes that appear in your document. Most of these neumes appear in the Solesmes table in Sect. 7.7.10.2 of Lily's manual. For those that do not appear there, here are some comments: punctum-cavum (page 5): this is done with Lily as follows: \[ \cavum g \] linea-punctum (page 5): this is done with Lily as follows: \[ \linea g \] linea-punctum-cavum (page 5): this is done with Lily as follows: \[ \linea \cavum g \] (Ok, looks like \linea and \cavum are not mentioned in the current documentation.) left-virga (page 5): there is no real left virga in Gregorian chant; it is a pure typographical result from connecting adjacent notes e.g. in a pes or flexa, which accidentally looks like a reverse virga. It has no musical meaning and therefore should not appear in the input syntax. In Lily, such connections are drawn automatically where appropriate, such there is no need for special input syntax. pes-quadratum (page 8): this is done with Lily as follows: \[ f \pes \virga b \] torculus-resupinus (page 8): this is done with Lily as follows: \[ f \pes a \flexa f \pes g \] porrectus-flexus (page 8): this is done with Lily as follows: \[ b \flexa a \pes b \flexa g \] torculus-resupinus-flexus (page 8): this is done with Lily as follow: \[ g \pes b \flexa g \pes a \flexa f \] right-pes (page 8): ok, this is currently not supported in Lily. Personally, I have not yet seen such a ligature. Can you please cite a source where this ligature appears? Thanks! Implementing it would be rather simple; the alignment looks identical to that of a virga, so the virga alignment code could be just reused for punctum heads that are marked with a special head prefix (e.g. \right). However, I wonder if this construct is really needed/useful/meaningful. right-porrectus (page 8): same as right-pes torculus-et-pes (page 8): this is done with Lily as follows: \[ g \pes b
Re: time signature in ancient notation
Yes, this looks better. Now, that we have barAlways = ##t, we can also
drop these dMinima etc. definitions. I also set the \version to 2.8.0
(just looks nicer in the source). Result is attached. I think it's still
not perfect, but much better than what is currently in the docu.
Graham, what do you think, could we put attached template into the docu
instead of that currently in 3.7.2? By the way, we have now 3.5.1
Transcription of mensural music and 3.7.2 Gregorian transcription
template. Maybe, these should be put together into a single section (and
maybe the two titles harmonized)?
Greetings,
Juergen
On Tue, 21 Mar 2006, Geoff Horton wrote:
Mmmh, well, it's neither a semantically clean nor a typographically
correct solution. I would call it a workaround...
Or an ugly hack :) But it works.
Did you try setting barAlways = ##t in Score context?
No, but I have now. I had to remove the bar engraver for that to work.
Is that better or worse than the way it is now? Neither one is pretty,
but then the whole thing isn't pretty, either.
(BTW, the \include english.ly in my original file isn't needed, of course.)
My new file:
\include gregorian-init.ly
\version 2.7.38
dMinima = { \divisioMinima \bar }
dMaior = { \divisioMaior \bar }
dfinalis = { \finalis \bar }
chant = \relative c' {
\set Score.timing = ##f
f4 a2 \dMinima
g4 b a2 f2 \dMaior
g4( f) f( g) a2 \dfinalis
}
verba = \lyricmode {
Lo -- rem ip -- sum do -- lor sit a -- met
}
\score {
\context Staff
\context Voice = melody {
\chant
}
\context Lyrics = one \lyricsto melody \verba
\layout {
ragged-right = ##t
\context {
\Staff
\remove Time_signature_engraver
\remove Bar_engraver
\override Stem #'transparent = ##t
}
\context {
\Voice
\override Stem #'length = #0
}
\context {
\Score
barAlways = ##t
}
}
}
Results are attached. I'd drop the ragged-right before putting it in the manual.
Geoff
\include gregorian-init.ly
\version 2.8.0
chant = \relative c' {
\set Score.timing = ##f
f4 a2 \divisioMinima
g4 b a2 f2 \divisioMaior
g4( f) f( g) a2 \finalis
}
verba = \lyricmode {
Lo -- rem ip -- sum do -- lor sit a -- met
}
\score {
\context Staff
\context Voice = melody {
\chant
}
\context Lyrics = one \lyricsto melody \verba
\layout {
\context {
\Staff
\remove Time_signature_engraver
\remove Bar_engraver
\override Stem #'transparent = ##t
}
\context {
\Voice
\override Stem #'length = #0
}
\context {
\Score
barAlways = ##t
}
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please spread release announcement
Good news: As of yesterday, there is an ebuild for 2.8.0 in Gentoo portage. Previously, the latest versions were 2.4.2 and 2.5.2. It's good not to have to roll my own ebuilds anymore. All Gentoo Lilypond users who update their systems regularly will see this if they have the unstable flag set for this application. Unfortunately the latest version marked stable in Portage is still 2.0.3. I hope this changes soon. --Daniel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB: patch for linux_kernel_headers
Hi,
You may want to apply the attached patch. It updates
linux_kernel_headers to 2.6.13+0rc3-2.1. I couldn't find
2.6.13+0rc3-2 from any mirror.
Pedro
New patches:
[updated version of Linux_kernel_headers
Pedro Kröger [EMAIL PROTECTED]**20060328000836] {
hunk ./lib/arm.py 18
- linux.Linux_kernel_headers (settings).with (version='2.6.13+0rc3-2', mirror=download.lkh_deb, format='deb'),
+ linux.Linux_kernel_headers (settings).with (version='2.6.13+0rc3-2.1', mirror=download.lkh_deb, format='deb'),
hunk ./lib/linux.py 52
- Linux_kernel_headers (settings).with (version='2.6.13+0rc3-2', mirror=download.lkh_deb, format='deb'),
+ Linux_kernel_headers (settings).with (version='2.6.13+0rc3-2.1', mirror=download.lkh_deb, format='deb'),
}
Context:
[Add quotes for GUB_DISTCC_ALLOW_HOSTS. What about /N suffixes?
[EMAIL PROTECTED]
[Cygwin installer fixes for LILYPOND_CVSDIR=lilypond-2.8.
[EMAIL PROTECTED]
[Add minimal Cygwin hints and readme; fixes cygwin build.
[EMAIL PROTECTED]
[Ugly lilypond-HEAD naming/versioning workarounds.
[EMAIL PROTECTED]
[Do version fixups for cygwin installer dependency manager.
[EMAIL PROTECTED]
[build fontconfig too.
[EMAIL PROTECTED]
[tweaks.
[EMAIL PROTECTED]
[local driver opts for bootstrap.
[EMAIL PROTECTED]
[ add patches/nsis-2.15-patchgenerator.patch
[EMAIL PROTECTED]
[move per-user fontconfig cache to lilypond.py , use .lilypond-VERSION-cache-1.
[EMAIL PROTECTED]
[add patches/fontconfig-2.3.2-mingw-fccache.patch
[EMAIL PROTECTED]
[apply fontconfig patch.
[EMAIL PROTECTED]
[use plain text for status file.
[EMAIL PROTECTED]
[trim fc-cache script
[EMAIL PROTECTED]
[add Fontconfig local package.
[EMAIL PROTECTED]
[only complain about branches if cvs_branch ''
[EMAIL PROTECTED]
[bootstrap reqs fontconfig too.
[EMAIL PROTECTED]
[tweaks.
[EMAIL PROTECTED]
[document why NSIS_CONFIG_LOG is switched off.
[EMAIL PROTECTED]
[urg. unprotect unquoted dirs.
[EMAIL PROTECTED]
[patches for nsis 2.15
[EMAIL PROTECTED]
[remove write protection from C:/windows before fc-caching.
[EMAIL PROTECTED]
[add patches/nsis-2.15-expand.patch
[EMAIL PROTECTED]
[remove simpleminded no-native patch
[EMAIL PROTECTED]
[use branch for gup2
[EMAIL PROTECTED]
[osx lilypad 0.2
[EMAIL PROTECTED]
[robust version subst for lilypad.
[EMAIL PROTECTED]
[Subst_method cvs_branch. Use in .hdr name.
[EMAIL PROTECTED]
[add python patch
[EMAIL PROTECTED]
[setup.py patch for cross building
[EMAIL PROTECTED]
[no verbose for binary pkgs.
[EMAIL PROTECTED]
[add branches, don't crash lilypondorg.py for nonexisting versions.
[EMAIL PROTECTED]
[update darwinppc osx lilypad subst
[EMAIL PROTECTED]
[move x-compiling mingw build to Python__mingw_cross. Use binary dist
[EMAIL PROTECTED]
of python for normal install.
]
[mail to janneke-list
[EMAIL PROTECTED]
[automatically update CVS sources for make doc.
[EMAIL PROTECTED]
[add make download
[EMAIL PROTECTED]
[Add src_package stub to Null_package.
[EMAIL PROTECTED]
[use SF.net address for nsis.
[EMAIL PROTECTED]
[bump nsis to 2.15
[EMAIL PROTECTED]
[force subprocess subst to succeed.
[EMAIL PROTECTED]
[also wipe usr/info/dir.
[EMAIL PROTECTED]
[README updates.
[EMAIL PROTECTED]
[rename patch.
[EMAIL PROTECTED]
[workaround for weird jpeg srcdir name.
[EMAIL PROTECTED]
[Actually working strip for Cygwin_package.
[EMAIL PROTECTED]
[nitpicks.
[EMAIL PROTECTED]
[Create CYGWIN-PATCHES.
[EMAIL PROTECTED]
[nitpicks
[EMAIL PROTECTED]
[update.
[EMAIL PROTECTED]
[update.
[EMAIL PROTECTED]
[Fix Cygwin src package.
[EMAIL PROTECTED]
[Add src_package stage.
[EMAIL PROTECTED]
[half assed attempt at src pkage for Cygwin.
[EMAIL PROTECTED]
[thinko.
[EMAIL PROTECTED]
[update.
[EMAIL PROTECTED]
[Add readmes for Cygwin, hint version fixes.
[EMAIL PROTECTED]
[Zip info files for Cygwin.
[EMAIL PROTECTED]
[Do not include gub in gup-manager.
[EMAIL PROTECTED]
[Sensible strip for Cygwin.
[EMAIL PROTECTED]
[Fix Cygwin `installer'
[EMAIL PROTECTED]
[don't repeat http://
[EMAIL PROTECTED]
[move defaults outside cmd line option processing.
[EMAIL PROTECTED]
[tweaks.
[EMAIL PROTECTED]
[get osx-lilypad version from file manager.
[EMAIL PROTECTED]
[strip install_manager arg
[EMAIL PROTECTED]
[further README updaets.
[EMAIL PROTECTED]
[remove wine requirements.
[EMAIL PROTECTED]
[revise README.
[EMAIL PROTECTED]
[change local.make location.
[EMAIL PROTECTED]
[copy subprocess.py from osx-lilypad.
[EMAIL PROTECTED]
[selectmodule patch.
[EMAIL PROTECTED]
[todo updates.
[EMAIL PROTECTED]
[reorganise GNUmakefile so local.make can overwrite local settings.
[EMAIL PROTECTED]
[be PC in patches.
[EMAIL PROTECTED]
[selectmodule.patch
[EMAIL PROTECTED]
[configure GMP for i386 target architecture.
[EMAIL PROTECTED]
[resolve.
[EMAIL PROTECTED]
[resolve.
[EMAIL PROTECTED]
[barf if libtool can't be updated.
[EMAIL PROTECTED]
[fix freetype url
[EMAIL PROTECTED]
[update bootstrap instructions
[EMAIL PROTECTED]
[Add W32api_in_usr_lib hack
Re: Tremolo positioning
It seems this issue doesn't bother anyone else? In any case, now that 2.8 is out there, I thought I'd start pushing this point again. I attach a patch that gives the behaviour that I think is correct. I also attach 2 examples of the differences between the existing and the proposed behaviours. Hmm, the Tchaikovsky solution is still incorrect -- some stems are too short, causing a collision with the note heads... It's a different bug, but it would be nice if it could be solved at the same time. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
On Tue, 28 Mar 2006 03:43, Werner LEMBERG wrote:
It seems this issue doesn't bother anyone else? In any case, now
that 2.8 is out there, I thought I'd start pushing this point again.
I attach a patch that gives the behaviour that I think is correct.
I also attach 2 examples of the differences between the existing and
the proposed behaviours.
Hmm, the Tchaikovsky solution is still incorrect -- some stems are too
short, causing a collision with the note heads... It's a different
bug, but it would be nice if it could be solved at the same time.
I've tweaked it by adding a little more to the minimum length of the stem. The
Franck output is unchanged, I've attached the new Tchaikovsky output.
Oh, and I remembered a ChangeLog entry this time :)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Index: ChangeLog
===
RCS file: /sources/lilypond/lilypond/ChangeLog,v
retrieving revision 1.4802
diff -u -r1.4802 ChangeLog
--- ChangeLog 24 Mar 2006 21:33:35 - 1.4802
+++ ChangeLog 28 Mar 2006 06:44:59 -
@@ -1,3 +1,13 @@
+2006-03-28 Joe Neeman [EMAIL PROTECTED]
+
+ * lily/stem-tremolo.cc (raw_stencil): position
+ the tremolo depending only on the end of the stem
+ and not on the notehead
+ (print) idem
+
+ * lily/stem.cc (calc_stem_info): make sure the stem
+ is long enough to fit the tremolo
+
2006-03-24 Graham Percival [EMAIL PROTECTED]
* Documentation/topdocs/NEWS.tely: add @end itemize
Index: lily/stem.cc
===
RCS file: /sources/lilypond/lilypond/lily/stem.cc,v
retrieving revision 1.304
diff -u -r1.304 stem.cc
--- lily/stem.cc 2 Mar 2006 10:50:40 - 1.304
+++ lily/stem.cc 28 Mar 2006 06:44:59 -
@@ -798,7 +798,6 @@
return si;
}
-/* TODO: add extra space for tremolos! */
MAKE_SCHEME_CALLBACK(Stem, calc_stem_info, 1);
SCM
Stem::calc_stem_info (SCM smob)
@@ -847,6 +846,13 @@
* staff_space
* length_fraction;
+ Real height_of_my_trem = 0.0;
+ Grob *trem = unsmob_grob (me-get_object (tremolo-flag));
+ if (trem)
+ height_of_my_trem = ly_scm2interval (trem-get_property (Y-extent)).length ()
+/* hack a bit of space around the trem. */
++ beam_translation;
+
/* UGH
It seems that also for ideal minimum length, we must use
the maximum beam count (for this direction):
@@ -859,6 +865,7 @@
Real ideal_minimum_length = ideal_minimum_free
+ height_of_my_beams
++ height_of_my_trem
/* stem only extends to center of beam */
- 0.5 * beam_thickness;
@@ -908,18 +915,11 @@
* staff_space
* length_fraction;
- Real minimum_length = minimum_free
+ Real minimum_length = max (minimum_free, height_of_my_trem)
+ height_of_my_beams
/* stem only extends to center of beam */
- 0.5 * beam_thickness;
- if (Grob *tremolo = unsmob_grob (me-get_object (tremolo-flag)))
-{
- Interval y_ext = tremolo-extent (tremolo, Y_AXIS);
- y_ext.widen (0.5); // FIXME. Should be tunable?
- minimum_length = max (minimum_length, y_ext.length ());
-}
-
ideal_y *= my_dir;
Real minimum_y = note_start + minimum_length;
Real shortest_y = minimum_y * my_dir;
Index: lily/stem-tremolo.cc
===
RCS file: /sources/lilypond/lilypond/lily/stem-tremolo.cc,v
retrieving revision 1.99
diff -u -r1.99 stem-tremolo.cc
--- lily/stem-tremolo.cc 10 Feb 2006 01:05:05 - 1.99
+++ lily/stem-tremolo.cc 28 Mar 2006 06:44:59 -
@@ -82,7 +82,8 @@
thick *= ss;
Stencil a (Lookup::beam (slope, width, thick, blot));
- a.translate (Offset (-width * 0.5, width * 0.5 * slope));
+ Interval a_ext = a.extent (Y_AXIS);
+ a.translate (Offset (-width * 0.5, a_ext.length () / 2 - a_ext[UP]));
int tremolo_flags = robust_scm2int (me-get_property (flag-count), 0);
if (!tremolo_flags)
@@ -147,6 +148,7 @@
Stencil mol = raw_stencil (me, robust_scm2double (me-get_property (slope),
0.25));
+
Interval mol_ext = mol.extent (Y_AXIS);
Real ss = Staff_symbol_referencer::staff_space (me);
@@ -160,29 +162,18 @@
Real end_y
= Stem::stem_end_position (stem) * ss / 2
-- stemdir * (beam_count * beamthickness
- + (max (beam_count -1, 0) * beam_translation));
-
- /* FIXME: the 0.33 ss is to compensate for the size of the note head. */
- Real chord_start_y = Stem::chord_start_y (stem) + 0.33 * ss * stemdir;
-
- Real padding = beam_translation;
+- stemdir * max (beam_count, 1) * beam_translation;
- /* if there is a flag, just above/below the notehead.
- if there is not enough space, center on remaining space,
- else one beamspace away from stem end. */
- if (!beam Stem::duration_log (stem) = 3)
+ /* the bottom flag is now centred on the middle of the staff.
Re: Tremolo positioning
Shouldn't all tremolo lines be at the same angle (usually about 30 degrees)? Sorry, I am new to the list, and am not sure where this thread started. But in standard notation, this is not what usual tremolo markings look like. Josh On Mar 28, 2006, at 9:48 AM, Joe Neeman wrote: On Tue, 28 Mar 2006 03:43, Werner LEMBERG wrote: It seems this issue doesn't bother anyone else? In any case, now that 2.8 is out there, I thought I'd start pushing this point again. I attach a patch that gives the behaviour that I think is correct. I also attach 2 examples of the differences between the existing and the proposed behaviours. Hmm, the Tchaikovsky solution is still incorrect -- some stems are too short, causing a collision with the note heads... It's a different bug, but it would be nice if it could be solved at the same time. I've tweaked it by adding a little more to the minimum length of the stem. The Franck output is unchanged, I've attached the new Tchaikovsky output. Oh, and I remembered a ChangeLog entry this time :) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel tremolo_20060328.patch tchaik_try2.jpeg ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ** Joshua Parmenter [EMAIL PROTECTED] Post-Doctoral Research Associate - Center for Digital Arts and Experimental Media Raitt Hall - University of Washington Seattle, Washington 98195 http://www.dxarts.washington.edu http://www.realizedsound.net/josh/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
I've tweaked it by adding a little more to the minimum length of the stem. The Franck output is unchanged, I've attached the new Tchaikovsky output. Very nice! Oh, and I remembered a ChangeLog entry this time :) Please add it just to the mail and don't include it into the diff directly. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
Shouldn't all tremolo lines be at the same angle (usually about 30 degrees)? AFAIK, this isn't true in the presence of beams. Can you provide a counterexample (this is, a small scanned image)? In that case we have to make it configurable. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
On Tue, 28 Mar 2006 07:01, Joshua Parmenter wrote: Shouldn't all tremolo lines be at the same angle (usually about 30 degrees)? Sorry, I am new to the list, and am not sure where this thread started. But in standard notation, this is not what usual tremolo markings look like. I started the thread on lilypond-user on 27/2 -- you can look in the archives -- with some scanned examples of tremolos but I moved it to this list when I made the patch. I believe that tremolos on beamed notes are always parallel to the beam. In fact, one of my examples (Cesar Franck sonata, Schirmer edition) has some horizontal tremolos. (In contrast, unbeamed tremolos are always the same slope). I agree that unsloped tremolos look a little strange, but sloped tremolos on unsloped beams look at least as bad. Looking at some of my first examples again, it seems that beams over tremolo stems have a tendency to be more sloped than beams over non-tremolo stems. This will increase the tendency of tremolos to be sloped. I'll look for some more examples. In the meantime, though, I think this patch improves the positioning of tremolos significantly. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
