Re: Invalid overrides in ly/gregorian.ly?
Hi, all! The horizontal placing of breathing signs in Gregorian Chant is anyway somewhat broken. Looking e.g. at the Sanctus, Sanctus, Sanctus example in 2.8.4 Typesetting Gregorian chant, the distance for the second divisio minima (after the second Sanctus) is fine, while the distance for the other two divisiones minimae is too wide. I suggest the following: If removing the extra-X-extent from gregorian-init.ly does not increase the distance between the breathing sign and the preceding note (particularly the distance after the second Sanctus), then please remove it without replacement, since the minimum distance looks ok and the other bad distances can not be fixed by a constant extra extent anyway. For double-checking, you should also ensure that removing the extra X extent has no visible impact on the Salve, Regina example at the beginning of chapter 2.8. Many thanks greetings, Juergen On Sat, 31 Jan 2009, Patrick McCarty wrote: Hello, After looking through source, I can't find a spot where 'extra-X-extent and 'extra-Y-extent are recognized, yet they are documented in the grob interface and an 'extra-X-extent override is used six times in ly/gregorian.ly. If they are no longer functional, should a convert-ly rule be added for them? Do 'minimum-X-extent and 'minimum-Y-extent replace these old properties? If not, which overrides should be used instead for \virgula, \caesura, etc. in ly/gregorian.ly? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mensural style
On Sun, 4 Jan 2009, Trevor Daniels wrote: BTW, the term accidental style appears twice in the documentation with a completely different meaning: - in 1.1.3, meaning the way how to display and reset accidentals In the detailed explanation they are named rules so I propose to always call them accidental rules and remove the word styles from the whole section. Hmm. Unfortunately the function is called set-accidental-style, so calling them rules might be just as confusing. - in 2.8.3, meaning the graphical appearance of accidentals If we do the latter, this can be kept as accidental styles or be augmented with graphic accidental styles. I think changing the description here to glyph might be better, since the override here already uses glyph-name So The style for accidentals and key signatures is ... would become The glyphs used for accidentals and key signatures are ... The Accidental property style has only recently been replaced by a new property glyph-name-alist. Apart from that, Lily almost consistently uses the term style for choosing between different sets of related glyphs: - a style property is available and documented at least for each of the grobs Notehead, Rest and TimeSignature; - a property flag-style is available and documented for Stem grobs; - clef styles for the \clef command are documented in Sect. 2.8.3 and 2.8.4. I heavily vote for sticking to this naming convention as consistently as possible. Best wishes, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.8 Ancient music ready for review
Very nice, I like the structure and your explanatory add-ons! Just a few nitpicking comments: * 2.8.3 (Typesetting mensural music): There are no rests in Gregorian chant notation; instead, it uses Divisiones. I would have expected this statement to appear somewhere in 2.8.4 (Typesetting Gregorian chant) instead. * 2.8.4 (Typesetting Gregorian chant): * ... by placing one of the joining commands pes or flexa ... = ... by placing one of the joining commands \pes or \flexa ... * ... by modifying the shape of a single-note neume with \auctus and one of the direction markers \descendens or \ascendens, e.g. \[ \auctus \descendens a \] ...: Replace \auctus = \auctum. N.B.: From an implementation point of view, I felt the need to minimize redundancy in the input language and therefore only defined the neutrum form auctum. Maybe users prefer using the correctly declined forms? * FYI: gregorian.ly defines also the commands \versus, \responsum, \ij, \iij, \IJ, and \IIJ that will produce the corresponding characters (e.g. for use in lyrics). However, since these commands uses quite special unicode characters, they will only work with properly installed unicode fonts that support these characters. Unfortunately, to my knowledge there is no slashed A character available in unicode. (As far as I know, all of these commands have not at all been documented so far.) * 2.8.5 (Working with ancient music): When talking about incipits and Mensurstriche layout, maybe one could refer to Learning Manual A.5.1 (Transcription of mensural music) for a more comprehensive example. Greetings, Juergen On Wed, 1 Oct 2008, =?ISO-8859-1?Q?Eyolf_=D8strem_ wrote: The section on Ancient music is now ready for comments. It has been completely rewritten and reorganized, so please have a look at it and comment, correct, or criticize. Here's a changelog: - The main change is that the general organization has been revised into two main sections: Gregorian chant notation and Mensural music. There was fairly little overlap between the alternative signs, which were mostly ancient, and the additional, which mostly belonged to the Gregorian section. - The two ligature tables in the Gregorian section have been merged into one. - There are still a few TODOs left, as well as missing cross references here and there, the odd example of bad formatting, etc. This is particularly true about the last section, which has not yet been written. I focused on the main text for this first round; there will be another round for this kind of formalities later on. Eyolf ___ 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: Three questions for ancient.itely
On Wed, 24 Sep 2008, =?ISO-8859-1?Q?Eyolf_=D8strem_ wrote: I'm working on the docs for ancient music, Nice to hear! 3. The form Episem is used, both as a lilypond command and in the documentation text. Since it's not really a medieval concept at all, but a term invented by the Solesmes monks when plainchant was revised/-vived in the late nineteenth century, it is not an established term in any language other than french, where it is episeme (and it doesn't appear neither in Merriam-Webster nor in the full OED). If anything, Episem is the german form. I would strongly recommend going with the latinized greek episema, which is what the Vatican editions have. Originally, I borrowed the term Episem from the OpusTeX implementation of Gregorian Chant. Just a couple of minutes ago, I did a small search on Google and have to agree that the form Episema is obviously much more used than Episem, especially in non-German languages. As you are working on the docs, there is another thing that comes into my mind: Currently, \augmentum is introduced in Sect. 2.8.3.6 (Gregorian square neumes ligatures). This was motivated from an implementation point of view, which is special for \augmentum within ligatures. However, from a user's perspective, I think \augmentum should be introduced in Sect. 2.8.3.1 (Ancient articulations), showing simply an augmented punctum note. Then, in Sect. 2.8.3.6, it should be stated that \augmentum is treated specially within ligatures (i.e. all dots vertically aligned after the ligature), showing \[ \augmentum a \flexa \augmentum g \] as an example. And yet another thing: The Hufnagel style of Gregorian Chant is in English language obviously better known as Gothic style. However, now that lily 2.12 is already in beta release stage, I would not recommend performing such a big rename at present. Thanks greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Episema not showing
On Thu, 25 Sep 2008, =?ISO-8859-1?Q?Eyolf_=D8strem_ wrote: It is mentioned as one of the known issues in the ancient section of the documentation that The episema line is not displayed in many cases. That in itself does not make it very useful, but it's doubly bad when it doesn't even show up in the example that illustrates it. Yes. Over the last few years, the episema first worked, then broke, then worked again, then broke again, and so forth, probably because people were working on the text spanner implementation. I still have the vision that with the next revision of the text spanner code, the episem will be (re-)fixed as if by a ghost's hand. Hence, the documentation sounds currently odd, but I hope it can be left as is in prospect of future lily releases... ;-) Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sad news
To all, also my condolences to all of Rune's family and friends. I fully agree with at least dedicating a lily version to him! Sad greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
On Mon, 11 Feb 2008, Robert Memering wrote: Am Montag, 11. Februar 2008 16:36 schrieb Juergen Reuter: IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. IMO, horizontal spacing in incipits should be completely turned off, i.e. uniform (and rather tight) spacing regardless of note values, as seen in the renaissance manuscripts. Robert Yes, IIRC we once used to have a global boolean variable compact for exactly this purpose, but I think it never worked as expected due to the complex resolving of competetive spacing constraints. Remember that you almost always need to stretch something somewhere to get your line of score filled; so you can not achieve solely uniform spacing unless in combination with ragged printing of systems. I guess switching from uniform ragged spacing in the incipit to non-uniform spacing in the remaining score would require a major rewrite of the whole horizontal spacing engine. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Hi all, as far as I understand, all problems with incipits boil down to the following two major issues: (1) horizontal spacing, and (2) the system start delimiter. Karl's solution unfortunately leaves horizontal space between the incipit and the actual score; hence it does *not* solve issue (2). Rather, the score lines should not stop inbetween. IMHO, all other features have been quite well demonstrated in template A.5.1 for a while now. Hence, you probably should concentrate on solving these two remaining issues. Regarding issue (2), maybe the right solution is to extend the system start delimiter implementation in such a way, that (a) automatic printing at the system start may be suppressed for a specific range of the score with kind of \turnSystemStartDelimiterOff and \turnSystemStartDelimiterOn commands, and (b) a kind of \bar #'system-start-delimiter command prints an additional system start delimiter whereever you want. (But if this bar should happen to appear at the system start, the delimiter should not be printed twice.) Regarding issue (1), I am not sure what the right solution is. Please note that the note durations in the incipit are typically much larger than in the actually score. Karl and Nicolas, did you check what happens with the horizontal spacing in your incipit solutions, if you double or quadruple the note durations in the incipit (and only there)? In your examples, in the incipts you are unfortunately using the same durations as in the actual score. I may be wrong, but I suspect that your solutions do *not* solve issue (1). IIRC, the spacing engine maintains a variable that keeps track of shortest available duration in a peace in computes the ideal distance of larger note values in a logarithmic scale based on the shortest duration. Maybe this computation needs to be changed for the incipit (and only there!) to get tighter spacing in the incipit. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
On Sat, 2 Feb 2008, Nicolas Sceaux wrote:
...
Anyway, wouldn't it be nicer to have some kind of scheme macro that expands
to code that prints an incipit? Your first clef could then be just part
of the incipit that the macro creates. And maybe the clef's name either
could passed as argument to the scheme macro. Or, alternatively, you set
an, say, original-clef property that the macro recognizes and accordingly
acts upon.
As I understand it, incipits are hackingly achieved using the
instrument name.
This is just one possible approach. Template A.5.1 demonstrates a
different approach. Apparently, both approaches have limitations/flaws.
I want instrument names to be defined separately
from incipit (they are not the same thing, there is no serious
reason to bind them, beside purely technical ones):
\new Staff
\global
\set Staff . instrumentName = \markup { The instrument name }
\clef xyz %% automagically set the incipit clef
{ ... the notes ... }
How could you make the mix of the two?
Ok, I think I understand the problem.
Now, seeing the incipt examples, I realize that my patch is a hack
too, for it would be nice to have also the time and key signatures,
not only the ancient clef.
Maybe creating an incipit engraver, reading new context properties,
like incipitKeySignature, incipitTimeSignature, etc, and creating a
grob of the same nature as the instrument name.
Yes, this idea definitely sounds very reasonable! Still, implementing
such an engraver may turn out challenging...
Greetings,
Juergen
nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postponed Bugs #83 and #297: a Someone Else Problem
On Sun, 27 Jan 2008, Han-Wen Nienhuys wrote: Juergen (CC-d) is the person who wrote the ligature code, including the one for the brackets. Yepp, ages ago (around early 2002)... I'm looking at the issues now, but there is something I don't understand. The ligature events are implemented as 'command-event', like \bar and \time, which fall in between the notes.This is inconsistent with start/stop commands like [ ] , but I can't really judge if that is the best way to do it. Hmmh, I don't understand. In Lily 2.7.x, in define-music-types.scm, LigatureEvent has (types . (general-music span-event ligature-event event)), i.e. it is a SpanEvent, or am I missing something? In Lily 2.11.x, it is implemented as StreamEvent, due to Erik's changes. How is this related to command-event (which, btw, I could not find in the sources)? For issue 297, I can change the formatting to end exactly on the last note; would that solve the problem? Juergen? Probably yes, at least in many cases, as far as I understand. 2008/1/27, Robert Memering wrote If this is the case, is there any chance I might sponsor fixing this bug? Speaking for me personally, it's more a problem of time lacking rather than of sponsoring (I even did not yet get acquainted with the git versioning system)... But there may be other people interested. And, by the way, as I haven't been involved in Lilypond development: Who is Juergen? Me! :-) (Oh, you are right, it's difficult to find me on the web, since my old home page unfortunately died a while ago; there is now a new one at www.juergen-reuter.de). Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MIDI staffs or voices?
On Sun, 28 Oct 2007, Paco Vila wrote: El Sat, 20 de Oct de 2007, a las 11:45:28AM -0200, Han-Wen Nienhuys dijo: IIRC the real problem is the limits that MIDI imposes (IIRC: you can have only 15 channels/track); They are 16, numbered from 1 to 16 (conventionally) but coded 0 to 15 in binary. Yes, but according to the GM standard channel #10 is reserved for drums; hence only 15 are left. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update to mf/README
Hi, by the way, when creating the ancient font many years ago, I added documentation in a similar vein which is now at the top of the files parmesan-clefs.mf and parmesan-heads.mf, but is also valid for the feta font. I guess this docu could also be moved to the README file. However, the docu is very old and possibly partially outdated; so it may have to be proof-read by someone more qualified/up-to-date than me. Greetings, Juergen On Tue, 2 Oct 2007, Maximilian Albert wrote: Hi, long ago I promised to add some info to mf/README about how stem attachments work for lilypond glyphs. Here finally is a patch. Since the conclusions I drew were derived by trial and error, I may have misinterpreted or overlooked something. Thus I'd be grateful if one of the metafont experts could give it a quick review. Also, please feel free to modify the wording as you like - I keep realizing that in English I find it difficult to write clearly and concisely at the same. Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accidental changes: review
On Tue, 25 Sep 2007, Han-Wen Nienhuys wrote: 2007/9/25, Rune Zedeler [EMAIL PROTECTED]: + int octave_; + int notename_; + Rational alteration_; Why don't you use a Pitch object for this combination? You would get Scale* for free. Primarily because the two values octave_ and has_octave_ are very closely related. They really /should/ be joined to an int option - if such a thing did exist in c++. you might want to look into making octave optional for pitch; I'm not sure if it is worth the trouble, but it would make key signatures more logical to specify. Otherwise, you could use an int* I am just curious: Why not introducing a new class Octaveless_pitch or Octave_Pitch (i.e. pitch within an octave) that contains all of Pitch except for the octaves, and then making Pitch a subclass of Octaveless_pitch that just adds the octaves to its superclass? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: documentation guidelines
On Fri, 21 Sep 2007, Graham Percival wrote: I've updated the README.txt with more guidelines about writing/maintaining documentation. I'll be asking the GDP Helpers to fix any Section organiztion and Formatting issues, as well as any Readability or Technical writing issues they feel comfortable updating. If I've forgotten anything from this list, please speak up so we can add them now. I would expect the contents of README.txt to be part of the online documentation and therefore available at: http://lilypond.org/doc/v2.10/Documentation/user/README However, obviously this file is not generated from README.txt or at least not put into the documentation out directory. Or is it available under some different URL? I also strongly suggest to put a link to this resource on some prominent page, maybe on: http://lilypond.org/web/devel/participating/ Otherwise, I think this file is too well hidden to be found by occasional documentation writers. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond crash in 2.11.32
On Wed, 19 Sep 2007, Till Rettig wrote: ... Sounds great! I am really unhappy with the German translation for the binary (e.g. ligature is translated as Bindung (sic!)). ... Ouch, I did not recognize that one yet! (Maybe that's why/because the default language on my machine is set to English...) Yes, of course you are right, this should be Ligatur. Thanks, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond crash in 2.11.32
On Tue, 18 Sep 2007, Reinhold Kainhofer wrote: ... Fortsetzung, die Finger kreuzen Segmentation fault By the way, I guess a proper translation of crossing fingers into German would be something like Daumen druecken... Till, what do you think? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: six
Just for the record: Ancient notation _could_ be split genre-wise into two separate chunks Gregorian Chant and Mensural Notation. However, for a _reference_ manual, I think it is ok as it currently is (e.g. having a single section on ligatures rather than separate ones per genre). For a _tutorial_, however, IMO you definitely would like to split it genre-wise. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Logo for Lilypond
On Fri, 14 Sep 2007, Jonas Nystr�m wrote: As I reviewed the website, I thought that perhaps something as simple as replacing the photograph of the pond with a beautifully-engraved piece of complex music might improve the first impression. Carl Sorensen Exactly! The site should communicate the unique qualities and possibilites of the program. Why not doing that the first seconds a new visitor reaches the site, using nice and clarifying graphics? Right now, you have to search to find examples that make that clear. Well, I guess that I should stop talking and try to create something myself... Take a look at the attached pictur. Regards / Jonas Also very nice, but I suggest _not_ to chose the Jubilate snippet as traditional notation, since it may actually scare new users (e.g. observe that the Ju in the alto voice is vertically aligned with the soprano bi, although the Ju occurs one quarter note earlier than the bi, which may be considered even as a bug, just like the bar lines that are missing from this snippet...). The Screech and boink snippet (see Sect. 1.5 in the manual) may be another interesting snippet. Greetings, Juergen___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Logo for Lilypond
OK. This is a first draft. (but we can just use the character, as Rune suggested) Very nice! It's IMO the best choice for a lily logo that I have seen so far. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: rearrangement
2007/9/11, Till Rettig [EMAIL PROTECTED]: Hello, For instance I could imagine a chapter Ancient music, and one on educational subjects. At least I don't see why Ancient is instrument specific, so why not put it in 7 from the current suggestion, right after educational and special noteheads. Maybe genre specific instead of instrument specific is the correct term here. Then, the vocal music can also stay in the chapter without singers complaining that the the human voice is not an instrument (btw. IMO the human voice _is_ an instrument, though a very special one). But, of course, I am also happy if you think that ancient music deserves a chapter of its own. ;-) Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: length/page-splitting of subsections
On Mon, 10 Sep 2007, Graham Percival wrote: To summarize some discussions: ... - Does anybody _like_ the current layout? If so, speak up now or forever hold your peace. :) I am _fine_ with the current layout. However, I agree that for global searching in the web browser, you need a big html page, as has already pointed out by various other people. However, if you really _cry_ for global searching, this fact may indicate that the current index is (for whatever reason) unsufficient. Regarding the current index, I wonder why the items of the command index also appear in the large index, thus making it unnecessarily long. Lack of consistency is IMHO another major problem (btw. there is a typo in the index as of .32: \displayLilyMusc iso. \displayLilyMusic). Another problem is that documentation writers often do not consider under which terms a reader of the manual may try to look up a feature; often only the most specific term is used; synonyms or categorizing terms are missing. One example (which is most likely my own fault ;-)) is ancient notation: if you are looking for ancient in alphabetical order, you will not find anything in the index. Ancient only occurs in composed terms such as rests, ancient or as part of the associated section name. At least in the printed version (i.e. without CTRL-F search available) you are lost. Similarly, you will find killCues only under k but not under cues (i.e. if you do not know the exact name, it will be hard for you to find it in the manual). Furthermore, I would like to see entries like \displayLilyMusic: Displaying LilyPond notation \displayLilyMusic: Displaying music expressions rather being structured as follows: \displayLilyMusic: Displaying LilyPond notation Displaying music expressions Given the large size of the documentation, a single person probably can not care for documentation-wide consistency of these (important!) nitpicks. Maybe a general good idea is to collect a couple of do and don't examples as guideline for documentation writers? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
\markup placement (Was: Re: collision barline with accidental)
Hi all, while you are at it (I mean, the placement/spacing code, though I am not sure if this is anyhow related)... I noticed that in Manual Sect. 7.7.10.2 (Gregorian square neumes ligatures) the placement of the letters in the neumes table changes from almost each version of the lily 2.11.x series to the next release: sometimes, the letters appear above the glyph, sometimes below, sometimes they are stacked upon each other, sometimes they appear in a horizontal row, with these flavors mixing even within the same version of lily... Is this intended behavior? (N.B.: In lily 2.10.29, the letters are placed consistently above the glyphs and in horizontal rows.) Btw., I do not mind where the letters actually appear, as long as the placement is somewhat consistent and it gets clear that each letter is associated with a glyph. Maybe the letters should not be typeset with the \markup command, as it is currently done? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: license of Lilypond
On Fri, 17 Aug 2007, Elie Roux wrote: Hello, I'm the developper of gregorio (http://home.gna.org/gregorio/), a software under GPLv3. I would like to integrate the font parmesan in it, and redistribute the font under GPLv3. But I can't find in the site or in the source if the files are GPLv2 or GPLv2 or later. In debian they say in the copyright file GPLv2 or later, but I'd like to know if it is official. I guess somewhere it says GPLv2 or later, but I am not 100% sure. Anyway, regarding the parmesan font, if it says GPLv2 only, personally I am also fine with GPLv3. Greetings, Juergen Thank you in advance, -- Elie ___ 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
[PATCH] Bugfix: ancient accidentals mapping
The attached patch (untested since I currently have no running copy of lily, but it's a trivial patch) should fix the wrong mapping of ancient accidentals to glyph names, that has recently be introduced. Greetings, JuergenFrom de6c6eab76592102d70b9406937b108e75b8bcf8 Mon Sep 17 00:00:00 2001 From: Juergen Reuter [EMAIL PROTECTED] Date: Thu, 2 Aug 2007 17:46:54 +0200 Subject: [PATCH] * Bugfix: correct order in accidentals glyph-name-alist --- scm/output-lib.scm | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/scm/output-lib.scm b/scm/output-lib.scm index bd3aa52..af454f2 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -398,24 +398,24 @@ centered, X==1 is at the right, X == -1 is at the left. )) (define-public alteration-hufnagel-glyph-name-alist - '((1/2 . accidentals.hufnagel-1) + '((-1/2 . accidentals.hufnagel-1) (0 . accidentals.vaticana0) - (-1/2 . accidentals.mensural1))) + (1/2 . accidentals.mensural1))) (define-public alteration-medicaea-glyph-name-alist - '((1/2 . accidentals.medicaea-1) + '((-1/2 . accidentals.medicaea-1) (0 . accidentals.vaticana0) - (-1/2 . accidentals.mensural1))) + (1/2 . accidentals.mensural1))) (define-public alteration-vaticana-glyph-name-alist - '((1/2 . accidentals.vaticana-1) + '((-1/2 . accidentals.vaticana-1) (0 . accidentals.vaticana0) - (-1/2 . accidentals.mensural1))) + (1/2 . accidentals.mensural1))) (define-public alteration-mensural-glyph-name-alist - '((1/2 . accidentals.mensural-1) + '((-1/2 . accidentals.mensural-1) (0 . accidentals.vaticana0) - (-1/2 . accidentals.mensural1))) + (1/2 . accidentals.mensural1))) -- 1.5.2.2 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dot changes break Gregorian notation
Sorry for this late answer, but I am still overloaded with work... :-( On Wed, 11 Jul 2007, Joe Neeman wrote: On Wednesday 11 July 2007 17:18, Werner LEMBERG wrote: Joe, your latest changes break the \augmentum stuff in Gregorian notation. (Do a search for `augmentum' and compare the example on the web page created from the current git with the one in http://lilypond.org/doc/v2.11/Documentation/user/lilypond-big-page Thanks for the heads-up; I'll have a look soon. Thanks Werner for pointing that out and thanks Joe for looking into it! I am also noticing that in the first table in manual Section 7.7.10.2 (Gregorian square neumes ligatures) the alignment of both the neumes and the text is (again/still?) broken: the letters appear sometimes over the neumes (e.g. in the line 3. Apostropha vel Stropha), sometimes below the neumes (e.g. in the line 7. Pes Quassus). Furthermore, few separate neumes collide (e.g. in the line 5. Clivis vel Flexa the neumes that are marked with letters l and m). I do not know if these problems are related with your (otherwise excellent!) work; I just want to point out that these things broke lately, compared to e.g. lily v2.10. (N.B.: These comments refer to the lily web site as of today, namely http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Gregorian-square-neumes-ligatures versus http://lilypond.org/doc/v2.10/Documentation/user/lilypond/Gregorian-square-neumes-ligatures ). There are some other spacing problems with the Gregorian stuff -- are you in the mood to handle this too? Always happy to fix bugs, particularly if I'm already working on that code. But I'm not really familiar with pre-Baroque notation so I would need to be told exactly what needs fixing. It would be good if I had a decent pile of examples, too, because I'm unlikely to come up with useful ones myself. Most often, there is too much space after ligatures. A good example is the 2nd line of score in 7.7.12 Mensural contexts in the 2.11.27 manual (the San - - - - ctus). The problem is that a ligature consists of multiple note heads that are collapsed into a single coherent set of glyphs, while lily still tries to distribute remaining space *between* these note heads, according to the rythmic duration of each note head. As a result, behind each ligature, the spaces for multiple note heads are cumulated. In fact, for computing the space between musical columns (and only for computing the space), all note heads of a ligature should be considered like a single note head with an unspecified duration (i.e. assume a duration of 0). On the other hand, for assigning ligature glyphs to musical columns, durations do have to be considered, such that e.g. ligatures in different lines of the score that start at the same time are vertically aligned (this assignment to musical columns is already done by the ligature implementation with the help of the Coherent_ligature_engraver::move_related_items_to_column function). There are surely more subtle spacing problems, but I think the above is the most outstanding and pressing one. If that one could be solved, ancient music should hopefully look much better overall. Hope that helps! Greetings thanks, Juergen Joe ___ 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: New bug priority: postponed
FYI: There are vague chances, that in 2008 I will be able to schedule a little bit more of my time for lilypond again. ;-) Greetings, Juergen On Wed, 28 Mar 2007, Graham Percival wrote: About six months ago, there was discussion about a priority level below low; at the time I argued against it. I've now changed my mind and added a Priority-Postponed tag. Here's my interpretation of the bug priorities: High, Regression: fix within one or two releases Medium: fix before next big Low: might be fixed in one or two stable releases Postponed: fix would be difficult without major restructuring of the lilypond internals, and/or there is no developer actively working in this area. IMO, all ancient notation bugs qualify for this, as do esoteric collision bugs. Cheers, - Graham ___ 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: Does the center of the staff need to be zero?
On Mon, 19 Mar 2007, Kevin Dalley wrote:
...
The G clef is correct, if you change your interpretation a bit. It
confused me for quite a while also. The documentation needs to be
improved, but I haven't figured out exactly how.
The G-clef is centered around the G note. The center of the staff at
B above middle C, however many lines there are.
So a 4-line G-clef leaves the G-clef centered around a space,
rather than around a bar.
If you typeset a G note, it will be in the same position on the G
clef.
You are right, but this is not the issue I was trying to point out. The
problem is neither of musical nor notational kind, but of typographical
kind. Maybe I should have chosen the bass clef as a more evident example:
If you reduce the number of stafflines to 4, the bass clef will always be
set in such a way, that the two dots of the bass clef glyph collide with
the stafflines. The problem is, that the typograhical design of the bass
clef assumes that the f pitch (the f which the bass clef references) is
always typeset on a staffline, but not in the space between two
stafflines, such that the bass clef's two dots are always printed between
stafflines. Similar typographical aspects hold for other clefs.
If the y origin of a staff would always be on, say, the lowest staffline
rather than on the center of the staff, then the bass clef would be
aligned correctly even on a staff with 4 stafflines.
\new Staff \with {
middleCPosition = #-2
clefGlyph = #clefs.G
clefPosition = #2
}
No, unfortunately, the clefPosition property does not help here at all,
since it shifts the clef by an integer multiple of staffline space, while,
in the case of an even number of stafflines, it would need to be shifted
by an odd integer multiple of half a staffline space.
In other words, a clef is typographical designed to be always aligned with
a staffline, but not to be aligned with the space between two stafflines.
The only exception that I know of is the drum clef, which is typically
always centered, regardless of the number of stafflines.
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does the center of the staff need to be zero?
Hi, all! Just a few comments: Actually, binding the origin to a staff line (e.g. the most lower staff line) rather than to the center of the origin (as we currently do) would solve the current problem that you have to design clefs explicitly either for staves with an even number of staff lines or for staves with an odd number of staff lines. In this sense, I would really welcome such a change (even though some of the ancient clefs would then have to be shifted by 1/2 staff line in the metafont code)! If you do not understand what I mean, then just try to apply the ordinary G clef to a score with 4 staff lines or 6 staff lines instead of the ordinary 5 staff lines. You will see that the clef will always be off 1/2 staff line (unless you do some y-offset trickery with backend properties). However, the drum clef will suffer from such a change, since the drum clef is usually always centered on the staff, regardles of the number of staff lines. I think, the drum clef is the only clef for which this problem will arise. Also, I am not sure if there are some serious implications of such a change for the pitch squash engraver. Greetings, Juergen On Sat, 17 Mar 2007, Han-Wen Nienhuys wrote: As far as I can see there is no strict need, fot it to be zero, so if you have a sensible patch to change it, go ahead and post it. BTW I know that you have an interesting patch for Lily to make line configurations more flexible. I'll try to review it this week. regards, Han-Wen 2007/3/15, Kevin Dalley [EMAIL PROTECTED]: In LilyPond, using line-positions, the center is required to be at 0, otherwise there are problems with the created score. There are a couple of possibilities. One is to make the documentations more clear that staffs must be centered at 0. The other possibility is to modify LilyPond to take staffs which are not centered at 0. I notice 2 areas which need to be modified. I have a small patch for bar-line.cc, which otherwise draws the bar line of the correct size, but centered around 0 rather than centered around the real center. Ledger lines need some work as well, though there are problems even if the staff is centered, particularly if the top and bottom lines are on even positions. Should I post my patch for bar lines for staffs which are not centered at 0? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Hi, all! What about unifying \paper and \layout into a single \layout directive, such that in the input language there is no syntactical difference any more between \paper and \layout block? (Of course, in the implementation, the different scopes still could be kept.) Then the place where the \layout occurs in the .ly file determines which properties can be changed (that is exactly what scopes are about). Obviously, if someone operates in the wrong scope, i.e. if someone tries to change things on score level \layout block which only should be changed globally (such as paper margin), lily should emit a warning. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: valid html?
Nope, not a bug. The problem is that characters in http references must be escaped (I think by amp;). Greetings, Juergen On Thu, 1 Feb 2007, Bertalan Fodor wrote: I think that's a bug in the validator :-) Bert Korneel írta: This little note, only to say that your current homepage does NOT validate through this URL: http://validator.w3.org/check?uri=referer Best wishes and please continue developping this wonderful software! Korneel ___ 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: medieval font design
On Thu, 1 Feb 2007, Till Rettig wrote: Hei, I am slowly evolving in my ideas and trials on the ancient fonts for lilypond. So far I have a couple of good scans from which I would like to take the shapes. But how is the best to get them into metafont? I found something about mfpic (probably not good in this case), fig2mf (sounds already better) and ps2mf (this might be the best?). But are they good, can they do the job? I am so far imaginating that I would take the scans as a picture and then kind of draw around them inside of a vector programm. This would give them at least a really handwritten lining. The other idea that somehow sounded logical to me was the way suggested in the fontforge tutorial: designing a glyph by setting points at the outline of the glyph until there are enough points to describe the form. But how is this done for instance in xfig? (As far as I understand fontforge doesn't export to fm). I acknowleged the fact that I will have to learn something about metafont anyways, I thought I would go through the metafont tutorial by Christophe Grandsire, this is old but since the program seems to be the same... At the moment it just seems that I won't be able to draw the wanted forms nonvisually, that is in the way that I would just write a mf file. Hi, Till! My personal experience is that you have to fine tune the glyphs anyway; hence, determining just a few coordinates should suffice (this can be easily done manually if you have a really big printout of the scan). Then about the single parts of the font (now for some white and black mensural notation): I will create noteheads and stems extra, but since the stems in some cases will have a form like the stem from the ! sign (bigger at top), they won't fit together with the flags. So should there be a separate flag + stem or rather a stem-flag combination? For each glyph, a charbox must be specified, such that lily knows how wide/high the glyph is. In practice, a glyph may stick out of the charbox (even though you probably should have a good reason to do so). In this case, I think sticking out glyphs could be useful; see attached drawing (suppose that the blue curve represents the stem, the red curve the flag, and the dotted lines the corresponding (simplified) charboxes). However, as far as I know, stems are currently drawn dynamically by just creating rectangles on the fly, rather than outputting a fixed glyph. The reason for doing so is that the actual stem length in general depends on a lot of other things, and therefore there is no fixed stem glyph. I guess the stem printing code in lily/stem.cc would need to be slightly revised to enable printing of stem glyphs. Or, even better, if you could express the stem by a polygonal shape and, given a stem length, devise a method for determining this polygonal shape's coordinates, then polygonal stems could be drawn on the fly in lily/stem.cc, analogous to the rectangular stems that we currently have. And still the idea about introducing some variability to mimick the handscribe, that is to have about four or five slightly different glyphs that would be used in arbitrary order. Is something like this possible in lilypond? Should be basically possible, if you modify lily/stem.cc accordingly. However, I guess the result would not look beautiful, since the arbitrariness of hand-writings actually comprehends a very complex process of balancing unevenness; I fear that simulating this process based on just some random numbers will not work well. Greetings, Juergen Ok, so far Greetings Till attachment: IMG_0951_small.JPG ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal: second style for quartertone accidentals
On Mon, 29 Jan 2007, Han-Wen Nienhuys wrote: . So it seems that the use of Accidental #'style is deprecated and one should set the alteration-alist directly. (But changing the style property still works in v2.11.13, even if I don't know why, given that I couldn't find the code handling it). What is the reason for this? To me the former notation seems much more intuitive and easy to use. The recent microtone improvements needed a much more flexible way to map pitches onto symbols, and it seems superfluous to have two mechanisms for setting glyphname at the same time. It would be possible to have a mechanism to set the alist based on the style property, but I thought it would be overkill. Maybe I should re-propose an idea that I posted maybe 5 years ago, but which was considered overkill at that time. Styles could be defined in a cascaded way. Say, there is an Accidental style default that just maps the standard non-microtonal accidentals to the modern accidental glyphs. The style should be however undefined for microtonal accidentals. Now, suppose that there is another style arrow-microtonals that only maps microtonal accidentals to arrow-style glyphs, but keeps silent on non-microtonal accidentals. Then it would be nice for the lily user to compose a style by setting a list of such predefined styles: \override Accidental #'style = #'(arrow-microtonals default). That is, for each accidental, lily should first search in the arrow-microtonals mapping if the acciental is mapped to some glyph. If no glyph is defined in this mapping, lily should look at the next mapping default. That is, you get a combination of standard modern accidentals with arrowed microtonals. There is one downside: If the style default defines only the glyphs for non-microtonal accidentals, one always has to explicitly set a microtonal style, if microtonals are to be used. In other ways, the value for the style property tends to become a long list. In order to fix this downside, one may also allow a style to import further styles. For example, suppose accidental style standard implicitly imports non-arrow-microtonals. That is, if you set \override Accidental #'style = #'(default), you also implicitly get non-arrow-microtonal accidentals, just as if you would have said \override Accidental #'style = #'(default non-arrow-microtonals). Note that you still can say \override Accidental #'style = #'(arrow-microtonals default). This will effectively override the non-arrowed microtonals that are implicit in the default style with arrowed microtonals, because the arrowed microtonals mapping occurs earlier in the list. Another downside of this approach could be performance, since each glyph lookup would result in iterating through nested scheme lists. Maybe, a sophisticated caching or precomputing approach could alleviate any performance issues. No, unfortunately I have currently no time to work on this :-(. These are just generic thoughts... Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal: second style for quartertone accidentals
On Sun, 28 Jan 2007, Juergen Reuter wrote: ... Unfortunately, the code for checking and handling the Accidental style property is still hardcoded in lily/accidental.cc in method string Accidental_interface::get_fontcharname (string style, int alteration) rather than being handled at runtime through scheme code, as is done with notehead style in the scheme function note-head::calc-glyph-name in file scm/output-lib.scm. ... Ooops, I just recognized that accidental handling obviously has changed during the last two months. Accidentals are now indeed handled via scheme; see scm/output-lib.scm for details. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond font design
On Tue, 16 Jan 2007, Till Rettig wrote: Hei, I was wondering if I could start some contribution to the medieval notation support That would be great! via redesigning the fonts that in my opinion don't look very good. Especially referring to the mensural notehead style (I think the petrucci looks quite fine, but neomensural and mensural heads are lot too small and also a bit boring, eg. too conform). Agreed. I have been mainly concentrating on Vaticana style and Petrucci style. As Werner already indicated, the ancient font was written before Lily used fontforge et al. Therefore, the glyphs do not follow all prerequisites that Lily glyphs are nowadays supposed to consider (in particular, there are some metafont constructs, that should not be used). Personally, I had so far no time to convert them. So, if you design new glyphs, please follow the guidelines that Werner mentioned. Also, you should be aware of some subtle optical pitfalls such as the fact that e.g. the slightly thickened lines on the lower left and upper right of the semibrevis head make the head look asymetrical, which you may want to compensate by its geometry (IIRC this is partially commented somewhere in the .mf files). I know there are thouthands of styles due to the fact that everybody wrote their own style, but we might choose from them one that would be really nice looking (kind of the same as the feta font does). I am not yet quite finished with my thinking how the heads really should look, but I think a really nice overall look gives the Copenhagen chancionnier, Burgung, late 15th century. Compare for example this page: http://base.kb.dk/pls/hsk_web/hsk_vis.side?p_hs_loebenr=27p_sidenr=8p_illnr=0p_frem=20p_tilbage=9p_navtype=relp_lang=dan or others from this book. For experimenting, maybe at first you want to introduce a new style (similarly to the Petrucci style)? Later, if your glyphs are mature, you still can replace the mensural/neo-mensural glyphs with those from you. So I would like to hear some opinions on this issue and also some hints about how Lilypond's fonts work (fontforge doesn't show any glyphs on the emental and I have no idea how to open svg fonts nor how they work). Also other issues about the mensural notation support could be solved, especially spacing (as in the picture), then those ligature issues. And Most spacing problems in ancient notation are related with the spacing engine, rather than with the font (actually, the bounding boxes of the ancient glyphs should be fairly good). You may find some further hints as comments in the lily/*ligature*.cc files as well as in ly/gregorian-init.ly and the ancient context definitions in ly/engraver-init.ly. A couple of months ago, I figured out three places in the spacing engine which have to be tweaked in order to get equally tight spacing (although these changes also affected spacing of clefs, accidentals, etc., which is not desirable). However, many things have changed since then in the spacing engine. it would probably be convenient to have also a kind of init file same as for the gregorian notation style. Agreed. Especially, one may want move stuff from engraver-init.ly to a mensural-init.ly. On the other side, then the user will have to add a \include mensural-init.ly, which you currently do not need to do (as the definitions in engraver-init.ly are automatically imported). I am not sure about this point (i.e. having clearly separated definitions that you manually have to import versus putting them into engraver.ly and friends versus having them clearly separated but automatically always importing them). On a later plane I would also like to have integration of other styles of mensural notation, even starting from the modal notation of the 12th century France. Yes, sounds interesting. Also, mannered notation would be nice. However, be aware that you easily end up in a kind of bottomless pit. I think the real challenge here is to make the associated mechanisms on the C++ level more flexible (spacing engine, glyph selection, ...), such that you have sufficient infrastructure in order to plug-and-play styles on the scheme level. Greetings, Juergen Greetings Till ___ 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: Re-write of documentation tree build process
On Thu, 21 Dec 2006, John Mandereau wrote: ... doctype = '!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN\n' s = doctype + s Does the 'EN' means that the page language is English? If so, it should be modified to handle pages of any language. No. The whole string is just the ID of the HTML DTD and thus does not change as long as you stick to HTML 4.01 Transitional). See: http://www.w3.org/TR/html4/struct/global.html#h-7.2 I am not sure about the exact meaning of the EN within the DTD ID string; you probably would have to look into ISO 8879; but that's not online available, as far as I know. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: replacement for pfx2ttf.fontforge
I don't know, if this matters, but in ancient notation, there definitely is an ij ligature (as well as an IJ ligature) that is quite often used as a textual repetition directive in lyrics. I hope the according definitions at the very beginning of ly/gregorian-init.ly will still work and handled as ligatures? Greetings, Juergen On Fri, 15 Dec 2006, Werner LEMBERG wrote: Well, my tests have worked. BTW, there are other ligatures also: I+J - IJ, i + j-ij I think those two should be removed also (just think of Strawinskij). This is now in the git repository. Werner ___ 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: replacement for pfx2ttf.fontforge
On Fri, 15 Dec 2006, Werner LEMBERG wrote: I don't know, if this matters, but in ancient notation, there definitely is an ij ligature (as well as an IJ ligature) that is quite often used as a textual repetition directive in lyrics. I hope the according definitions at the very beginning of ly/gregorian-init.ly will still work and handled as ligatures? Ah, we use different terminology. With *ligature* I mean the process of mapping the input character sequence `I' + `J' to `IJ', not the *ligature glyph* `IJ' -- this is still there, of course. Ah, ok; then I am relieved! ;-) Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dejavu kievan notation message
Actually, as far as I can see, it was not a repeat, but a delay of one week. Maybe you were not subscribed to this list when you sent it, and it was therefore sent to the list moderator for manual approval. Anyway, it's nothing to worry about. ;-) Greetings, Juergen On Thu, 7 Dec 2006, Monk Panteleimon wrote: Hi. Just got a lilypond-devel email with first message about kievan notes in it again. I'm not sure how that happened, but I'm sorry for the repeat. Fr. P ___ 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: There no ligatures in Kievan notation (was Re: Kievan hatchet notes for lilypond?)
On Thu, 30 Nov 2006, Monk Panteleimon wrote: On Thursday 30 November 2006 06:01, you wrote: Hello, Panteleimon! Hello, thank you for your response I fear the task of fully implementing kievan chant notation is more than just a question of adding thirteen glyphs. recognize at least pes ligatures (those pairwise stacked rhombic glyphs) and clivis ligatures (e.g. the third glyph in the last line of the long example). Actually, those are not ligatures, and there are no ligatures at all in Kievan notation. The two stacked diamond-shapes you refer to are simply a half note. They refer to the space inbetween the two diamonds, in this case mi or b-natural. If the diamonds where in spaces, they would refer to the line in-between. The squiggly-with-stem and double-diamond-with-stem notes that also seem to take up several spaces are not ligatures either, just 16th notes. (By the way, the durations I cite are doubled by some transcribers in order to have a whole-note as the longest duration, but this gives an incorrect impression of the flow of the chant). Ok, I understand. This, of course, simplifies things a lot. Then the main task really should be to incorporate these glyphs into lily. Though I unfortunately have to confess that I currently have no time at all to care for it (I am currently working hard on a thesis, and my remaining time is running out soon). Maybe Han-Wen/Jan would do it as a sponsored feature? I am not sure what is the latest state of incorporating new glyphs into lily; so far, we used to have to design glyphs by manually writing Metafont code, which may result in high-quality glyphs, but is also an extremely time-consuming process. But nowadays, lily supports a couple of font formats. Maybe there is a simpler way of getting font characters into lily, e.g. by scanning + tracing them? Han-Wen, Werner, what do you think? In any case, I guess you would at least need to have high-resolution scans of hand-writings or printings (which should be sufficiently old in order to not violate copyright laws). To me, the notation looks structurally quite similar to gothic (also called hufnagel) chant notation, though the glyphs are somewhat different. I would be interested to know what notation looked like in Poland in the 1600's, to see if it has a parent for this style Unfortunately, I am not familiar with Polish ancient notation. Still, since (at least the northern and western part of) Poland is mostly Catholic rather than Orthodox, I strongly guess that they used gothic and Roman (i.e. square) neumes, as well as mensural notation. I suspect, however, that it may be different for those parts of Poland near to the Ukrainian or Russsian border. As I understand it, the only things necessary *besides* adding the glyphs would be: 1. Spacing according text syllable. This is the only way notes are spaced in this chant, as you can see. There is a small even block of space between each textual syllable, all the notes whereof are equidistant and very close. %%%(This is part of what makes this notation better for Znamenny Chant, being closer in this regard to the neumatic origins and taking up less space for long, involved melismata. It looks ugly if you try to do it with round notes.)%%% My hope is that this can be accomplished simply making slurs invisible in the kievan-init.ly file | Slur #'transparent = ##t | and then convincing lilypond to put an appropriate block of space between syllables. At first I thought that this could be done with LyricSpace #'minimum-distance , but that would only work for short syllables. Right. There are a tricks that will force lily to typeset notes rather densely, thus resulting in almost what you probably would like to get. Still, I do not know how you could achieve strictly equidistantly and densely spaced noteheads within melismas. 2. Right now we can set shaped noteheads in LP like this: \set shapeNoteStyles = ##(fa # la fa # la mi) (or something like that). We'd have to do something similar but different in the init.ly for kievan, since several symbols (the quarter and the eight) have slightly different forms for lines and spaces. These differences are very important to the overall look of the music. Note that they differ not to according scale-position (like shapenotes) but according to whether they are on a line or space. That means that g,8 looks different from g8 There is currently support for line/space glyph distinction for custodes and mensural flags in the c++ backend. It should not be too hard to also add it for noteheads, but I guess Han-Wen will not be too happy to add new program logic to the c++ backend. Hence I guess, for the long term, this cries for migrating the whole logic to scheme. Furthermore, the eigth note (block with long tail) has not two but *four* slightly different forms: two for stem-up and two for stem-down. Just like with the custos glyphs, I guess. I think that
Re: skyline vertical spacing
Maybe the real point here is that for almost all glyphs we want to have a _convex_ outline (such that e.g. stems do not extend into glyphs) rather than a tight skyline? On Tue, 14 Nov 2006, Han-Wen Nienhuys wrote: Werner LEMBERG escreveu: I'm not sure whether an automated process really gives satisfactory results. The skyline could approximate the real outline with arbitrary precision. What's the problem? It's the opposite. A too-good approximation of the outline might be too tight. It should be easy to fatten an outline to get some extra padding. Making outlines by hand will be error prone, and time consuming, as they have to scale exactly with all the MF parameters. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: skyline vertical spacing
On Tue, 14 Nov 2006, Werner LEMBERG wrote: ... I've already `converted' all symbols except the one for ancient notation -- Jürgen, do you have time to work on improving the glyph shapes of the ancient notation so that mf2pt1 produces sensible results? Mmmh, looks currently really bad: during the next couple of months, I still have to work on my thesis, but I am severely behind schedule... Sorry! Greetings, Juergen___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Juergen Reuter wrote: On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: Without knowing the details, I think it is easiest to define a LigatureNoteHead or XLigatureNoteHead, and a XxxxLigature in define-grobs.scm. (X = Gregorian, Vaticana, Coherent, Mensural) By copying some definitions of the NoteHead grob, some C++ of Note_head can be shared. A special XXX_Ligature engraver will create those heads, and arrange them correctly within the appropriate XxxxLigature. If the XLigature is an Item, then it will be on a single PaperColumn. By putting the XxxxNoteHeads on the XLigature Item, the notes will also be on the same PaperColumn. The XxxxLigature knows all of the ligature contents, and hence, it can determine the final desired shape. Ok, this may work provided that there is no code elsewhere in lily that receives grobs, looks into them and does some things if and only if this grob is a NoteHead. Otherwise, this code would not apply to ligature heads, thus failing special treatment of note heads that should also apply on ligature heads. I actually tried this approach a couple of years ago, and it did not work for this reason. Of course, lily has changed dramatically since then; probably I should try again. Actually, the above approach will not work without further modification: Currently, note-heads-engraver.cc listens for note events and creates NoteHead grobs; the ligature engraver takes over these note heads and manipulates them. To follow the above approach, I would have to make the note heads engraver stop producing note head grobs (and instead let the ligature engraver produce LigatureHead grobs). But how can I achieve this? Removing the note heads engraver completetly from its context is no option, since both usual note heads as well as ligatures have to appear in the same context. So, how can I signal the note heads engraver that a ligature is in process and that it should stop producing note heads? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: Werner LEMBERG escreveu: Consider the test file apply-output.ly. During `make web', extended debugging is active, and processing the file gives this warning: programming error: Grob `NoteHead' has no interface for property `text' continuing, cross fingers Hanwen, do you have an answer to my original question? Or is this `ancient notation'? There is no easy way. You have to write a bit of scheme code that adds to the list in the interfaces detail property in the meta property. There are many other warnings similar to this, and I think it would be good to fix them all. 95% of these warnings come from the ancient notation code; that needs to be fixed first IMO. Please give an example, together with the `right' syntax. this is not about syntax, but about the ancient notation code misusing the current structure in ways that it wasn't designed to do. Ancient notation uses head prefixes like \virga, \quilisma, etc. that are kind of attributes of the note heads for their further characterization (in the source code, these note heads also called ligature primitives, if used in the context of ligatures). These attributes further describe the heads, such as select a virga glyph for this note head. Still, the actual note head glyph depends not only on the attribute(s) of the note head, but also on the attributes of the left and right neighbour note head. Hence, it does not make sense to store these attributes e.g. as notehead style. Additionally, some implicit attributes derive from the combination of attributes of two adjacent note heads (e.g. for deciding if a vertical line has to be drawn between two adjacent note heads). When the music is processed by the parser, I somewhere have to store this information that refers to individual note heads. Obviously, the note heads themselves are the best place. However, one of the design requirements of adding ancient notation to lily was to separate the new code as far as possible from existing code; in particular, ancient notation code was required not to pollute existing code of lily, such as note-heads.cc. As a result, ancient notation inofficially uses these attributes without officially declaring them in noteheads.cc. One theoretical solution would be to introduce a new ligatureheads.cc file instead of using the noteheads.cc functionality. However, it turned out that almost all of the functionality of noteheads.cc would have to be cloned. Even worse, some other parts of lily call methods in noteheads.cc (at least in earlier versions of lily they did; I have not checked for recent versions). That is, when introducing a ligatureheads.cc I would have to add calls to methods in ligatureheads.cc all around the existing code, which would also pollute the code; i.e. introducing a ligatureheads.cc is not a solution. Subclassing noteheads.cc did not work for some technical detail that I currently can not remember. The easiest solution that I can see is to tolerate little polution of noteheads.cc and just add the missing interface declaration at the end of this file. However, that's not my decision... Any comments to solve this problem are welcome; however, my time is currently extremely limited (still writing on my thesis and running out of time...), so I currently can contribute only cosmetic changes, if at all. By the way, the particular warning programming error: Grob `NoteHead' has no interface for property `text' does not origin from ancient notation, as far as I can see. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: draft release announcement
elegant input format and hard for other programs to parse sounds somewhat like a contradiction. Maybe sophisticated instead of elegant would be more appropriate? I am not sure about capitalization in English language, but shouldn't * all words in the headline except than start with a capital letter and * the itemized texts start with small letters (except DocBook), since they continue an incomplete sentence? Shouldn't there be a full-stop dot after the last item? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: newweb ChangeLog site/news.ihtml
By the way, to make site/news.ihtml result in valid HTML 4.01 again, I guess the unencoded characters in the Bugfixes href attribute values should be replaced with amp; or %26 (untested)? Greetings, Juergen On Mon, 23 Oct 2006, Han-Wen Nienhuys wrote: CVSROOT:/cvsroot/lilypond Module name:newweb Changes by: Han-Wen Nienhuys hanwen 06/10/23 00:09:26 Modified files: . : ChangeLog site : news.ihtml Log message: (href): close parenthesis. (Preferably): typo. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/newweb/ChangeLog?cvsroot=lilypondr1=1.498r2=1.499 http://cvs.savannah.gnu.org/viewcvs/newweb/site/news.ihtml?cvsroot=lilypondr1=1.158r2=1.159 Patches: Index: ChangeLog === RCS file: /cvsroot/lilypond/newweb/ChangeLog,v retrieving revision 1.498 retrieving revision 1.499 diff -u -b -r1.498 -r1.499 --- ChangeLog 23 Oct 2006 00:06:15 - 1.498 +++ ChangeLog 23 Oct 2006 00:09:25 - 1.499 @@ -1,6 +1,7 @@ 2006-10-23 Han-Wen Nienhuys [EMAIL PROTECTED] * site/news.ihtml (href): close parenthesis. + (Preferably): typo. 2006-10-22 Han-Wen Nienhuys [EMAIL PROTECTED] @@ -155,7 +156,7 @@ * site/about/automated-engraving/scoring-esthetics.html, site/about/automated-engraving/divide-and-conquer.html: add - Translation of CVS $Revision: 1.498 $ comment. + Translation of CVS $Revision: 1.499 $ comment. 2006-06-19 Han-Wen Nienhuys [EMAIL PROTECTED] Index: site/news.ihtml === RCS file: /cvsroot/lilypond/newweb/site/news.ihtml,v retrieving revision 1.158 retrieving revision 1.159 diff -u -b -r1.158 -r1.159 --- site/news.ihtml 23 Oct 2006 00:06:15 - 1.158 +++ site/news.ihtml 23 Oct 2006 00:09:26 - 1.159 @@ -1,6 +1,6 @@ !-- -*- html -*- -- !-- -Translation of CVS $Revision: 1.158 $ +Translation of CVS $Revision: 1.159 $ Translators must leave this comment intact, but remove any dollar signs ($) from the CVS Revision indicator. @@ -35,7 +35,7 @@ The last months, Erik Sandberg has been overhauling the internals of Lily. This change introduces a new intermediate format, Music Streams, which will make it easier get music data out of LilyPond. A copy of -the thesis is now avalaible from lilypond.org (a +the thesis is now available from lilypond.org (a href=@[EMAIL PROTECTED]download PDF 750k/a) /dd ___ Lilypond-cvs mailing list Lilypond-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-cvs ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug] bad size of piano brace
Right. Though, afterwards I noticed that the bug obviously had already
been fixed when I reported it; only the online Documentation is slightly
outdated. Sorry for the unnecessary uproar!
Greetings,
Juergen
On Mon, 23 Oct 2006, Phillip Kirlin wrote:
All,
Just thought I'd echo this sentiment on the piano brace, they all seem to be
displaying too small in any document that uses a PianoStaff (including the
2.9 documentation online).
Example: (straight from
http://lilypond.org/doc/v2.9/Documentation/user/lily-580882106.ly)
\new PianoStaff
\new Staff { \time 2/4 c4 c g' g }
\new Staff { \clef bass c,, c' e c }
--Phil Kirlin
___
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: [Bug?] Dotting notes by music function
FYI: After looking once more through a couple of files in the scm directory, I finally found the shift-duration-log function that exactly does what I wanted. For the moment, I take this one. Thanks again, Juergen On Wed, 18 Oct 2006, Juergen Reuter wrote: On Sun, 15 Oct 2006, Nicolas Sceaux wrote: Juergen Reuter [EMAIL PROTECTED] writes: By the way, do we have a generic substitution function that you can pass an event type and some replacement expression to? Maybe something like (replace-for-all-matches #(define-matching-expression (any-music-event-of-type 'NoteEvent)) Music #(define-replacement-expression (original-match) (... an expression in terms of original-match that is used as replacement for original-match ...))), There is some kind of music pattern matcher in scm/display-lily.scm: the with-music-match macro, which is not exported from this module however. nicolas Thanks, I will look into it! Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Small doc updates
Hi, Graham! I had to make small updates to some of the ancient notation examples in the docs to make them better reflect the current implementation. Accordingly, I also updated tiny parts of the text refering to these examples. I hope, that's ok? Of course, feel free to change my changes! Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] bad size of piano brace
Hi, in the online manual, Sect. 14.1 (An example of a musicological document), in the screech and boink example, the piano brace is too small. At least, I can not see in the .ly source any reason why the brace should be printed smaller. See: http://lilypond.org/doc/v2.9/Documentation/user/lilypond/An-example-of-a-musicological-document.html#An-example-of-a-musicological-document Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Bug?] Dotting notes by music function
On Sun, 15 Oct 2006, Nicolas Sceaux wrote: Juergen Reuter [EMAIL PROTECTED] writes: By the way, do we have a generic substitution function that you can pass an event type and some replacement expression to? Maybe something like (replace-for-all-matches #(define-matching-expression (any-music-event-of-type 'NoteEvent)) Music #(define-replacement-expression (original-match) (... an expression in terms of original-match that is used as replacement for original-match ...))), There is some kind of music pattern matcher in scm/display-lily.scm: the with-music-match macro, which is not exported from this module however. nicolas Thanks, I will look into it! Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
make web error (current cvs)
IIRC, I have seen this error from the very beginning of the new ~ feature for lyrics. Greetings, Juergen Processing `/home/reuter/project/lilypond-2.9/input/regression/out-www/lily-1431938706.ly' Parsing...[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/init.ly[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/declarations-init.ly[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/music-functions-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/nederlands.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/drumpitch-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/chord-modifiers-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/script-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/scale-definitions-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/grace-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/midi-init.ly[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/performer-init.ly]][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/paper-defaults.ly[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/titling-init.ly]][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/engraver-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/dynamic-scripts-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/spanners-init.ly][/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/property-init.ly]][/home/reuter/project/lilypond-2.9/input/regression/out-www/lily-1431938706.ly[/home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/lilypond-book-preamble.ly] Renaming input to: `lyric-tie.ly' Interpreting music... [2] elapsed time: 0.00 seconds Element count 10 (spanners 5) Preprocessing graphical objects... Grob count 14Backtrace: In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/lily.scm: 453: 12* [ly:parse-file lily-1431938706] In unknown file: ?: 13* [#procedure #f # # #] In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/ly/lilypond-book-preamble.ly: 3: 14* (if (not (eq? # #t)) (print-score-with-defaults p (scorify-music m p))) 4: 15 [print-score-with-defaults # #] In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/lily-library.scm: ... 117: 16 [ly:score-process #Score #module b69af430 ...] In unknown file: ?: 17* [ly:spacing-spanner::set-springs #Grob SpacingSpanner ] ?: 18* [ly:axis-group-interface::width #Grob PaperColumn ] ?: 19* [ly:self-alignment-interface::aligned-on-x-parent #Grob LyricText ] ?: 20* [ly:grob::stencil-width #Grob LyricText ] ?: 21* [lyric-text::print #Grob LyricText ] In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/output-lib.scm: 441: 22* (let* (# # # #) (ly:text-interface::interpret-markup layout props #)) 447: 23 [ly:text-interface::interpret-markup # Output_def (# # #) ...] In unknown file: ?: 24* [tied-lyric-markup # Output_def ((# # # ...) (# # # ...) (# # #)) ...] In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/define-markup-commands.scm: 292: 25* (if (string-contains str ~) (let* # #) ...) 293: 26 (let* (# # # #) (interpret-markup layout # #)) 300: 27 [ly:text-interface::interpret-markup # Output_def (# # #) ... 305: 28* [make-line-markup (bla ? bla ? ())] In unknown file: ?: 29 (let ((sig #)) (make-markup line-markup make-line-markup sig ...)) In /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm: ... 91: 30 [ly:error ... 92: 31* [string-append make-line-markup : ...] /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: In procedure string-append in expression (string-append make-name : ...): /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: Wrong type argument (expecting STRINGP): (1 list of markups (bla ? bla ? ())) command failed: /home/reuter/project/lilypond-2.9/out/bin/lilypond --backend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=texidoc -I /home/reuter/project/lilypond-2.9/input/manual -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I /home/reuter/project/lilypond-2.9/input/regression -I /home/reuter/project/lilypond-2.9/input/regression -I /home/reuter/project/lilypond-2.9/input/regression/out-www -I /home/reuter/project/lilypond-2.9/input -I /home/reuter/project/lilypond-2.9/input/regression -I /home/reuter/project/lilypond-2.9/input/manual -I /home/reuter/project/lilypond-2.9/input/tutorial -I /home/reuter/project/lilypond-2.9/mf/out -I /home/reuter/project/lilypond-2.9/mf/out
Re: make web error (current cvs)
On Sat, 14 Oct 2006, Han-Wen Nienhuys wrote: Juergen Reuter schreef: /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: In procedure string-append in expression (string-append make-name : ...): /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: Wrong type argument (expecting STRINGP): (1 list of markups (bla ? bla ? ())) I can't reproduce this, but it seems that your version of list-join doesn't work. Which version of GUILE do you have? ~/project/lilypond-2.9 guile --version Guile 1.6.7 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make web error (current cvs)
On Sat, 14 Oct 2006, Han-Wen Nienhuys wrote: Juergen Reuter schreef: On Sat, 14 Oct 2006, Han-Wen Nienhuys wrote: Juergen Reuter schreef: /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: In procedure string-append in expression (string-append make-name : ...): /home/reuter/project/lilypond-2.9/out/bin/../share/lilypond/2.9.24/scm/markup.scm:92:10: Wrong type argument (expecting STRINGP): (1 list of markups (bla ? bla ? ())) I can't reproduce this, but it seems that your version of list-join doesn't work. Which version of GUILE do you have? ~/project/lilypond-2.9 guile --version Guile 1.6.7 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. can you investigate whether the list-join function works for you, and if no, why not? Yes, eventually (I have 3 deadlines next week, 2 papers and 1 presentation :-(, so I may try to have a look next weekend into it, as I guess that may take some time...). By the way, could it be related to a character encoding problem? I have a couple of programs on my system (Fedora Core 5) that have severe problems regarding encoding, especially when data is passed between apps; my system seems to assume a default encoding of sometimes utf-8, sometimes iso-latin. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] line breaking
Hi,
in the following file:
\version 2.9.24
\context Voice \transpose c c'' {
c8 c4
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
}
the leading c8 causes that never in this score a barline coincides with
a note starting/ending. As a result, no line break is found for this
score, and the whole score is printed in a single line, thus exceeding the
right margin of the paper.
I think, the score should, regardless of the missing coincidence, still be
breakable at each of the barlines. Or I am missing something? (Btw., I
found this example by investigating reasons for the often weird spacing in
mensural notation.)
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug] line breaking
On Sun, 15 Oct 2006, Han-Wen Nienhuys wrote:
Juergen Reuter schreef:
\version 2.9.24
\context Voice \transpose c c'' {
c8 c4
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c
}
the leading c8 causes that never in this score a barline coincides with a
note starting/ending. As a result, no line break is found for this score,
and the whole score is printed in a single line, thus exceeding the right
margin of the paper.
I think, the score should, regardless of the missing coincidence, still be
breakable at each of the barlines. Or I am missing something?
Yes; normally you'd use barchecks and figure this out immediately.
Not in (at least transciptions of) mensural music. See, e.g. in the
manual, Sect. D.5.1 the horrible mess of where you can and where you can
not use barchecks.
Or remove
Forbid_break_engraevr.
Ah, ok, thanks!
Switching this off would mean that we print scores with messed up spacing in
this case.
No, seems to work for me (I removed Forbid_line_break_engraver from Voice
context). At least, for the moment it works. ;-)
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Bug?] Dotting notes by music function
Ah, thanks, now I understand! But then, in the manual in Sect. 12.1.2
(Simple substitution functions), in the
custosNote = #(define-music-function (parser location note)
(ly:music?)
example, note should better be renamed into event or something similar
to avoid misunderstandings, right?
By the way, do we have a generic substitution function that you can pass
an event type and some replacement expression to? Maybe something like
(replace-for-all-matches
#(define-matching-expression (any-music-event-of-type 'NoteEvent))
Music
#(define-replacement-expression
(original-match) (... an expression in terms of original-match that
is used as replacement for original-match ...))),
where, in this example, the specified replace function is executed exactly
once for each 'NoteEvent (i.e. the matching expression) in Music (with
the note event passed as original-match argument to the replacement
expression) in order to replace the original match by the result of the
replacement expression?
(By the way, please note that I do not explicitly specify here the type of
the matching expression, i.e. the return type of the
any-msuic-event-of-type function. In the most general case, it could be
an attributed music expression subgraph in order to implement a graph
rewriting system. For now, I would be happy, if it would be just
a music event type such as 'NoteEvent, in order to match all events of a
given specific type.)
I guess, such a function would save lots of duplicated code used for
navigating through music expressions, right? Or do we already have such a
function?
Thanks Greetings,
Juergen
On Fri, 13 Oct 2006, Nicolas Sceaux wrote:
Juergen Reuter [EMAIL PROTECTED] writes:
Hi, all!
I would expect the following lily file:
\version 2.9.22
dottedQuarter =
#(define-music-function (parser location note) (ly:music?)
(make-music
'NoteEvent
'duration (ly:make-duration 2 1)
'pitch (ly:music-property note 'pitch)))
\new Voice \transpose c c' {
f4 f \dottedQuarter f f f
}
to produce the notes:
f4 f4 f4. f4 f4
However, it produces:
f4 f4 c4. f4 f4
That is, the pitch changes from f to c, although I am trying to
copy it from the original note. Is this a bug or am I doing something
wrong?
Are you sure that the note argument as a pitch property? Try:
\displayMusic f4
nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond COPYING ChangeLog
On Fri, 13 Oct 2006, Han-Wen Nienhuys wrote: If you modify this font, you may +extend this exception to your version of the font, but you are not +obligated to do so. If you do not wish to do so, delete this exception +statement from your version. I.e., effectively, we change the licence for the font to BSD-style? (That's fine with me, but I would like to point out this explicitly.) Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond COPYING ChangeLog
On Fri, 13 Oct 2006, Han-Wen Nienhuys wrote: Juergen Reuter schreef: On Fri, 13 Oct 2006, Han-Wen Nienhuys wrote: If you modify this font, you may +extend this exception to your version of the font, but you are not +obligated to do so. If you do not wish to do so, delete this exception +statement from your version. I.e., effectively, we change the licence for the font to BSD-style? (That's fine with me, but I would like to point out this explicitly.) No, if you change the font, you're still obliged to put changes under GPL again. This exception means that PDF files don't fall under GPL. Mmmh, I am not a lawyer, so I may be totally wrong, but ... sounds to me like LGPL is what are you looking for? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Bug?] Dotting notes by music function
Hi, all!
I would expect the following lily file:
\version 2.9.22
dottedQuarter =
#(define-music-function (parser location note) (ly:music?)
(make-music
'NoteEvent
'duration (ly:make-duration 2 1)
'pitch (ly:music-property note 'pitch)))
\new Voice \transpose c c' {
f4 f \dottedQuarter f f f
}
to produce the notes:
f4 f4 f4. f4 f4
However, it produces:
f4 f4 c4. f4 f4
That is, the pitch changes from f to c, although I am trying to copy
it from the original note. Is this a bug or am I doing something wrong?
I just want to have a function that adds a dot to the next notehead, and
just that one notehead, and preferably without needing surrounding {}
around the (unary) music argument.
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dots grob
On Wed, 11 Oct 2006, Han-Wen Nienhuys wrote:
why not simply do
string style =
if (scm_is_symbol (scm_style))
style = ly_symbol2string (scm_style);
string idx = dots.dot + style;
Because, historically, there is no difference in lily's behaviour between
setting style to #'default and #'(). However, if you do not mind, I am
also happy with the simpler solution.
Attached is a revised version that issues a proper warning if style is set
to #'default or some other unsupported value, such that the dot is not
found.
Should I apply it?
Greetings,
JuergenIndex: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5395
diff -u -r1.5395 ChangeLog
--- ChangeLog 10 Oct 2006 13:38:32 - 1.5395
+++ ChangeLog 11 Oct 2006 10:03:50 -
@@ -1,3 +1,10 @@
+2006-10-10 Jürgen Reuter [EMAIL PROTECTED]
+
+ * mf/parmesan-dots.mf (new), mf/parmesan-generic.mf,
+ ly/engraver-init.ly: Added vaticana-style augmentum dot glyph.
+
+ * lily/dots.cc: Added style property for dots.
+
2006-10-10 Han-Wen Nienhuys [EMAIL PROTECTED]
* scm/output-lib.scm (fingering::calc-text): use origin
Index: lily/dots.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/dots.cc,v
retrieving revision 1.79
diff -u -r1.79 dots.cc
--- lily/dots.cc11 Feb 2006 11:35:18 - 1.79
+++ lily/dots.cc11 Oct 2006 10:03:50 -
@@ -14,6 +14,7 @@
#include lookup.hh
#include staff-symbol-referencer.hh
#include directional-element-interface.hh
+#include international.hh
MAKE_SCHEME_CALLBACK (Dots, print, 1);
SCM
@@ -26,7 +27,17 @@
if (scm_is_number (c))
{
- Stencil d = Font_interface::get_default_font (sc)-find_by_name (string
(dots.dot));
+ SCM scm_style = sc-get_property (style);
+ string style =;
+ if (scm_is_symbol (scm_style))
+ style = ly_symbol2string (scm_style);
+ string idx = dots.dot + style;
+ Stencil d = Font_interface::get_default_font (sc)-find_by_name (idx);
+ if (d.is_empty ())
+ {
+ sc-warning (_f (dot `%s' not found, idx.c_str ()));
+ return SCM_EOL;
+ }
Real dw = d.extent (X_AXIS).length ();
/*
@@ -55,5 +66,6 @@
/* properties */
direction
- dot-count);
-
+ dot-count
+ style
+ );
Index: mf/parmesan-generic.mf
===
RCS file: /cvsroot/lilypond/lilypond/mf/parmesan-generic.mf,v
retrieving revision 1.10
diff -u -r1.10 parmesan-generic.mf
--- mf/parmesan-generic.mf 6 Jan 2006 09:13:23 - 1.10
+++ mf/parmesan-generic.mf 11 Oct 2006 10:03:50 -
@@ -33,6 +33,7 @@
input parmesan-flags;
input parmesan-timesig;
input parmesan-scripts;
+ input parmesan-dots;
else:
fi
Index: ly/engraver-init.ly
===
RCS file: /cvsroot/lilypond/lilypond/ly/engraver-init.ly,v
retrieving revision 1.309
diff -u -r1.309 engraver-init.ly
--- ly/engraver-init.ly 4 Oct 2006 10:32:26 - 1.309
+++ ly/engraver-init.ly 11 Oct 2006 10:03:50 -
@@ -765,6 +765,7 @@
\override Custos #'style = #'vaticana
\override Custos #'neutral-position = #3
\override Custos #'neutral-direction = #DOWN
+ \override Dots #'style = #'vaticana
}
\context {
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dots grob
On Wed, 11 Oct 2006, Han-Wen Nienhuys wrote: Because, historically, there is no difference in lily's behaviour between setting style to #'default and #'(). However, if you do not that must have been a long time ago; I think I've tried to remove this feature for some time now. Ok. + input parmesan-dots; I'm missing this file in the patch. Sorry, it's still the same one as in the previously sent mail (cvs diff -u unfortunately only spits out cvs diff: mf/parmesan-dots.mf is a new entry, no comparison available for new files). It's attached to this mail once again. Greetings, Juergenfet_begingroup (dots); save dot_diam; 3 dot_diam# = staff_space# - stafflinethickness#; define_whole_blacker_pixels (dot_diam); fet_beginchar (duration dot, dotvaticana); pickup pencircle scaled dot_diam; lft x0 = 0; top y0 = vround (.5 dot_diam); drawdot z0; set_char_box (0, dot_diam#, .5 dot_diam#, .5 dot_diam#); fet_endchar; fet_endgroup (dots); ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dots grob
On Wed, 11 Oct 2006, Han-Wen Nienhuys wrote: Juergen Reuter schreef: On Wed, 11 Oct 2006, Han-Wen Nienhuys wrote: why not simply do string style = if (scm_is_symbol (scm_style)) style = ly_symbol2string (scm_style); string idx = dots.dot + style; Because, historically, there is no difference in lily's behaviour between setting style to #'default and #'(). However, if you do not that must have been a long time ago; I think I've tried to remove this feature for some time now. By the way, it has not completely been removed. The code related to the longa note bug reported last week by Ralph Little for example still contains some reminiscences to the old #'default feature. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: Status of Ancient Notation Implementation
On Sun, 8 Oct 2006, Juergen Reuter wrote: * The longa notes bug (cp. http://lists.gnu.org/archive/html/lilypond-devel/2006-10/msg00022.html) has been tracked down to a general problem in output-lib.scm (see http://lists.gnu.org/archive/html/lilypond-devel/2006-10/msg00050.html for details). However, to fix it properly, note-head::calc-glyph-name should be completely rewritten (i.e. add test for empty style value in case statement and handle it identically as default style; also replace case statement by completely different way of dispatch to gain speed, e.g. with a hashtable or alist or...), which goes beyond my scheme skills. Any help from scheme/guile gurus is appreciated! Attached patch should fix this one and theoretically even *speed up* glyph name lookup, since it removes obsolete scheme code. Instead of trying to fix the scheme code, I added a new longa note head to the feta font. It looks exactly like a brevis head, but with a stem like quarter note. Maximae are not handled by this patch, but I actually have not ever seen a Maxima in modern font, so this is a generally open issue to be handled separately. May I apply this patch? Greetings, JuergenIndex: ChangeLog === RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v retrieving revision 1.5397 diff -u -r1.5397 ChangeLog --- ChangeLog 11 Oct 2006 19:54:32 - 1.5397 +++ ChangeLog 11 Oct 2006 20:12:37 - @@ -7,6 +7,10 @@ * mf/parmesan-heads.mf: Fix typo in comment. + * mf/feta-bolletjes.mf, scm/output-lib.scm: Fix longa notes bug by + adding longa head to feta font and removing obsolete default + mapping scheme code. + 2006-10-10 Han-Wen Nienhuys [EMAIL PROTECTED] * scm/output-lib.scm (fingering::calc-text): use origin Index: mf/feta-bolletjes.mf === RCS file: /cvsroot/lilypond/lilypond/mf/feta-bolletjes.mf,v retrieving revision 1.79 diff -u -r1.79 feta-bolletjes.mf --- mf/feta-bolletjes.mf4 Oct 2006 16:00:19 - 1.79 +++ mf/feta-bolletjes.mf11 Oct 2006 20:12:37 - @@ -148,6 +148,77 @@ % % dimensions aren't entirely right. % +def draw_longa (expr up) = + save stemthick, fudge; + + stemthick# = 2 stafflinethickness#; + define_whole_blacker_pixels (stemthick); + + fudge = hround (blot_diameter / 2); + + draw_outside_ellipse (1.80, 0, 0.707, 0); + undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#); + + pickup pencircle scaled stemthick; + + if up: + bot y1 = -d; + y2 = h; + rt x1 - fudge = 0; + x1 = x2; + + fudge + lft x3 = w; + x4 = x3; + top y4 = h + 3.0 staff_space; + y3 = y1; + else: + bot y1 = -d - 3.0 staff_space; + top y2 = h; + rt x1 - fudge = 0; + x1 = x2; + + fudge + lft x3 = w; + x4 = x3; + y4 = y2; + bot y3 = -d; + fi; + + draw_gridline (z1, z2, stemthick); + draw_gridline (z3, z4, stemthick); +enddef; + + +fet_beginchar (Longa notehead, u-2); + draw_longa (true); + + draw_staff (-2, 2, 0); +fet_endchar; + +fet_beginchar (Longa notehead, d-2); + draw_longa (false); + + draw_staff (-2, 2, 0); +fet_endchar; + + +if test 0: + fet_beginchar (Longa notehead, u-2); + draw_longa (true); + + draw_staff (-2, 2, 0.5); + fet_endchar; + + fet_beginchar (Longa notehead, d-2); + draw_longa (false); + + draw_staff (-2, 2, 0.5); + fet_endchar; +fi; + + +% +% dimensions aren't entirely right. +% def draw_brevis = save stemthick, fudge; Index: scm/output-lib.scm === RCS file: /cvsroot/lilypond/lilypond/scm/output-lib.scm,v retrieving revision 1.115 diff -u -r1.115 output-lib.scm --- scm/output-lib.scm 10 Oct 2006 13:38:32 - 1.115 +++ scm/output-lib.scm 11 Oct 2006 20:12:37 - @@ -119,6 +119,10 @@ (log (min 2 (ly:grob-property grob 'duration-log (case style + ;; default style is directly handled in note-head.cc as a + ;; special case (HW says, mainly for performance reasons). + ;; Therefore, style default does not appear in this case + ;; statement. -- jr ((xcircle) 2xcircle) ((harmonic) 0harmonic) ((baroque) @@ -137,16 +141,6 @@ (string-append (number-string log) (symbol-string style ((neomensural) (string-append (number-string log) (symbol-string style))) - ((default) - ;; The default font in mf/feta-bolletjes.mf defines a brevis, but - ;; neither a longa nor a maxima. Hence let us, for the moment, - ;; take
dots grob
Hi,
may I apply attached patch in order to fix the size/shape of dots for
ancient notation? This patch adds a style property to the Dots grob
and a new glyph to the parmesan font.
Greetings,
JuergenIndex: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5395
diff -u -r1.5395 ChangeLog
--- ChangeLog 10 Oct 2006 13:38:32 - 1.5395
+++ ChangeLog 10 Oct 2006 17:29:40 -
@@ -1,3 +1,10 @@
+2006-10-10 Jürgen Reuter [EMAIL PROTECTED]
+
+ * mf/parmesan-dots.mf (new), mf/parmesan-generic.mf,
+ ly/engraver-init.ly: Added vaticana-style augmentum dot glyph.
+
+ * lily/dots.cc: Added style property for dots.
+
2006-10-10 Han-Wen Nienhuys [EMAIL PROTECTED]
* scm/output-lib.scm (fingering::calc-text): use origin
Index: lily/dots.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/dots.cc,v
retrieving revision 1.79
diff -u -r1.79 dots.cc
--- lily/dots.cc11 Feb 2006 11:35:18 - 1.79
+++ lily/dots.cc10 Oct 2006 17:29:40 -
@@ -26,7 +26,16 @@
if (scm_is_number (c))
{
- Stencil d = Font_interface::get_default_font (sc)-find_by_name (string
(dots.dot));
+ SCM scm_style = sc-get_property (style);
+ string style;
+ if (scm_is_symbol (scm_style))
+ style = ly_symbol2string (scm_style);
+ else
+ style = default;
+
+ string idx =
+ (style == default) ? dot : string (dot) + style;
+ Stencil d = Font_interface::get_default_font (sc)-find_by_name (dots.
+ idx);
Real dw = d.extent (X_AXIS).length ();
/*
@@ -55,5 +64,6 @@
/* properties */
direction
- dot-count);
-
+ dot-count
+ style
+ );
Index: mf/parmesan-generic.mf
===
RCS file: /cvsroot/lilypond/lilypond/mf/parmesan-generic.mf,v
retrieving revision 1.10
diff -u -r1.10 parmesan-generic.mf
--- mf/parmesan-generic.mf 6 Jan 2006 09:13:23 - 1.10
+++ mf/parmesan-generic.mf 10 Oct 2006 17:29:40 -
@@ -33,6 +33,7 @@
input parmesan-flags;
input parmesan-timesig;
input parmesan-scripts;
+ input parmesan-dots;
else:
fi
Index: ly/engraver-init.ly
===
RCS file: /cvsroot/lilypond/lilypond/ly/engraver-init.ly,v
retrieving revision 1.309
diff -u -r1.309 engraver-init.ly
--- ly/engraver-init.ly 4 Oct 2006 10:32:26 - 1.309
+++ ly/engraver-init.ly 10 Oct 2006 17:29:40 -
@@ -765,6 +765,7 @@
\override Custos #'style = #'vaticana
\override Custos #'neutral-position = #3
\override Custos #'neutral-direction = #DOWN
+ \override Dots #'style = #'vaticana
}
\context {
fet_begingroup (dots);
save dot_diam;
3 dot_diam# = staff_space# - stafflinethickness#;
define_whole_blacker_pixels (dot_diam);
fet_beginchar (duration dot, dotvaticana);
pickup pencircle scaled dot_diam;
lft x0 = 0;
top y0 = vround (.5 dot_diam);
drawdot z0;
set_char_box (0, dot_diam#, .5 dot_diam#, .5 dot_diam#);
fet_endchar;
fet_endgroup (dots);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: Status of Ancient Notation Implementation
On Sun, 8 Oct 2006, Juergen Reuter wrote: * Section 7.7.7: The episem articulation does not appear (there should be a horizontal line above the three last noteheads). In 2.7.x, the right ending was badly placed; now the episem is completely invisible. Also, the text scripts are colliding (but that is not really an ancient notation issue); they did not collide in 2.7.x. There are obviously multiple bugs behind this one, which are not easy to fix. In particular, the TextSpanner under certain circumstances produces lines with strange end points. If the line is (should be) quite short, it is not at all displayed. For the moment, I have tuned the figure in Sect. 7.7.7 such that the episem is displayed (still with bad right ending) and added an appropriate comment to the @refbugs paragraph (patch attached). Graham, what do you think, should this patch be applied? Without this patch, the reader of the documentation immediately sees that there must be something wrong but is left alone, as the figure does not show what is explained in the text. With the attached patch, the reader will (hopefully) see that episem to some extent works (to the same extent as in the lily 2.7.x series), but there is an explanation in the @refbugs paragraph that states that the episem feature is rather buggy. Of course, I would like to get this bug fixed, but it looks like I would have to rewrite major parts of TextSpanner and LineSpanner. Greetings, JuergenIndex: ChangeLog === RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v retrieving revision 1.5391 diff -u -r1.5391 ChangeLog --- ChangeLog 9 Oct 2006 14:14:42 - 1.5391 +++ ChangeLog 9 Oct 2006 15:52:03 - @@ -1,3 +1,8 @@ +2006-10-09 Jürgen Reuter [EMAIL PROTECTED] + + * Documentation/user/instrument-notation.itely: Tune Ancient + Articulations figure, such that the episem actually shows. + 2006-10-09 Han-Wen Nienhuys [EMAIL PROTECTED] * ly/generate-documentation.ly: update option name. Index: Documentation/user/instrument-notation.itely === RCS file: /cvsroot/lilypond/lilypond/Documentation/user/instrument-notation.itely,v retrieving revision 1.106 diff -u -r1.106 instrument-notation.itely --- Documentation/user/instrument-notation.itely27 Aug 2006 06:54:06 - 1.106 +++ Documentation/user/instrument-notation.itely9 Oct 2006 15:52:03 - @@ -2911,11 +2911,11 @@ \override TextScript #'font-family = #'typewriter \override TextScript #'font-shape = #'upright \override Script #'padding = #-0.1 -a4\ictus_ictus s1 -a4\circulus_circulus s1 -a4\semicirculus_semicirculus s1 s -a4\accentus_accentus s1 -\[ a4_episem \episemInitium \pes b \flexa a \episemFinis \] +a\ictus_ictus \break +a\circulus_circulus \break +a\semicirculus_semicirculus \break +a\accentus_accentus \break +\[ a_episem \episemInitium \pes b \flexa a b \episemFinis \flexa a \] } } @end lilypond @@ -2925,6 +2925,10 @@ Some articulations are vertically placed too closely to the correpsonding note heads. +The episem line is not displayed if its length is shorter than the +width of roughly 4 note heads. The right end of the episem line is +often too far to the right. + @node Custodes @subsection Custodes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: Status of Ancient Notation Implementation
On Mon, 9 Oct 2006, Geoff Horton wrote: FWIW, I'm not sure that the horizontal episema is best done with a TextSpanner anyhow. In Solesmes notation, at least, it goes right over the notes, not over the staff. Gepff Right. But I vaguely remember (I may be wrong) that a long time ago, spanner lines/brackets were able to follow into the staff directly over the notes. Anyway, I currently have no time for fixing this bug in a serious way. The question that I addressed to Graham is, should I just ignore this bug for now and do nothing about it at all, or should I try to apply minor tweaks to get it at least partially working in the documentation (with proper explanations in the @refbugs paragraph)? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: Status of Ancient Notation Implementation
On Sun, 8 Oct 2006, Juergen Reuter wrote: * Section 7.7.10.1, second figure: Ligature brackets are not at all displayed anymore. Same problem also in the introductionary Section 7.7.10. Should be fixed now in cvs. The adaption to the new stream event code was incomplete. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
FYI: Status of Ancient Notation Implementation
Hi all, just for the record in expectation of lily 2.10, here is a summary report of known _NEW_ bugs in ancient notation that were newly introduced in the 2.9.x series. I list them here as a collective todo list, for myself remembering them easier, but also for anybody else interested in the status of ancient notation implementation. I would like to see these bugs fixed, such that ancient notation at least does not get worse with each new release of lilypond, but my time is currently extremely limited; nevertheless, I will try having a look at one or another bug in the next couple of weeks/months. Of course, any help is highly appreciated! Mainly looking at the manual at the website (stamped as lily 2.9.21) and also considering the longa notes thread (cp. http://lists.gnu.org/archive/html/lilypond-devel/2006-10/msg00022.html), I currently see the following bugs that were introduced in 2.9.x: * Section 7.7.7: The episem articulation does not appear (there should be a horizontal line above the three last noteheads). In 2.7.x, the right ending was badly placed; now the episem is completely invisible. Also, the text scripts are colliding (but that is not really an ancient notation issue); they did not collide in 2.7.x. * Section 7.7.9: The text scripts in the figure are unnecessarily widely spaced; the whole thing could be placed more tightly. However, in lily 2.7.x, it was placed too tightly, such that the text scripts were colliding. So I am not sure, if the situation now is to be seen as an improvement or worsening. Anyway, this issue is a general script placing issue rather than an ancient notation specific issue. * Section 7.7.10.1, first figure: In HTML, the figure does not show at all (in PDF, it does; probably some arithmetic problem in spacing calculation that lets the bounding box of the figure horizontally collapse; cp. http://lists.gnu.org/archive/html/lilypond-devel/2006-06/msg00133.html). Actually, I am not sure, if this problem was not already introduced in the 2.7.x series. * Section 7.7.10.1, second figure: Ligature brackets are not at all displayed anymore. Same problem also in the introductionary Section 7.7.10. * Appendix D.5.2: Horizontal padding around divisio maior (the vertical bar-like line) is far too narrow. Note, that the horizontal spacing looked (almost) ok, when Geoff Horton rewrote this template, cp. http://lists.gnu.org/archive/html/lilypond-devel/2006-03/msg00174.html, even though, at that time I already warned about possible problems... * The longa notes bug (cp. http://lists.gnu.org/archive/html/lilypond-devel/2006-10/msg00022.html) has been tracked down to a general problem in output-lib.scm (see http://lists.gnu.org/archive/html/lilypond-devel/2006-10/msg00050.html for details). However, to fix it properly, note-head::calc-glyph-name should be completely rewritten (i.e. add test for empty style value in case statement and handle it identically as default style; also replace case statement by completely different way of dispatch to gain speed, e.g. with a hashtable or alist or...), which goes beyond my scheme skills. Any help from scheme/guile gurus is appreciated! Finally, the good news: Meanwhile, I could partially solve the separation-item problems reported in http://lists.gnu.org/archive/html/lilypond-devel/2006-04/msg00313.html, so I hope to eventually correct placement of augmentum dots for vaticana-style ligatures. That's all for now... Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Longa notes
Hi all,
the longa notes problem reduces to this piece of code in method
internal_print (Grob *me, string *font_char) in file lily/note-head.cc:
if (!scm_is_symbol (style))
style = ly_symbol2scm (default);
[... snip ...]
if (style != ly_symbol2scm (default))
{
SCM gn = me-get_property (glyph-name);
if (scm_is_string (gn))
suffix = ly_scm2string (gn);
}
The problem here is that 'me-get_property (glyph-name)' is called only
if 'style != ly_symbol2scm (default)'. That is, the code in
output-lib.scm for default style is dead. That is, why longa notes are
not working for default style.
If I remove the 'if (style != ly_symbol2scm (default))' condition _and_
if I explicitly say: \override NoteHead #'style = #'default
then the longa notes show correctly. However, without explicitly setting
#'style to #'default, I get:
/home/reuter/project/lilypond-2.9/share/lilypond/2.9.22/scm/output-lib.scm:144:58:
In procedure symbol-string in expression (symbol-string style):
/home/reuter/project/lilypond-2.9/share/lilypond/2.9.22/scm/output-lib.scm:144:58:
Wrong type argument in position 1 (expecting SYMBOLP): ()
Hence, obviously, the above 'if' condition was introduced to suppress this
error, but this fix is bad, since it makes the code for the default style
in output-lib.scm dead.
The real problem is the case style switch statement in line 114 of
output-lib. If style is not set, it erroneously selects the else case
(rather than the default case) and dies when trying to execute
symbol-string on the undefined style.
Does some scm guru know how to test _before_ the case style switch, if
style is undefined, and if so, set it to default? This would be
the real fix, I guess.
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Longa notes
On Wed, 4 Oct 2006, Mats Bengtsson wrote: If I remember correctly, it's not included when you have the default note head style, simply since there is not real established standard for the layout of a longa note in modern typesetting. However, if you use \override NoteHead #'style = #'mensural you can see what \longa note looked like in the old times when it was actually used. Not really. Citing scm/output-lib.scm: (case style [...snip...] ((default) ;; The default font in mf/feta-bolletjes.mf defines a brevis, but ;; neither a longa nor a maxima. Hence let us, for the moment, ;; take these from the neo-mensural font. TODO: mf/feta-bolletjes ;; should define at least a longa for the default font. The longa ;; should look exactly like the brevis of the default font, but ;; with a stem exactly like that of the quarter note. -- jr (if ( log -1) (string-append (number-string log) neomensural) (number-string log))) That is, lily should take a longa from neo-mensural font. The real problem is the 'u' in 'noteheads.u-2': The parmesan font defines a symmetric 'noteheads.s-2neomensural', but neither up/down specific heads. I wonder why an upwards head is at all requested for the default note head font. Maybe something has changed in the noteheads engraver which causes this problem? /Mats Ralph Little wrote: Hi, Running 2.9.17-1 on Windows, I get the following error for c\longa: warning: note head 'noteheads.u-2' not found. I don't really know anything about longas, but I was just experimenting with different aspects of lily and this popped up... c\breve works fine though. Cheers, Ralph ___ 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: Another patch (this one is important) to abc2ly
On Mon, 2 Oct 2006, Laura Conrad wrote: I just tested it and in actual code, yours seems to do the same thing mine does, N.B.: There should be a minor difference in the handling of white space before/after the hyphen, which however is not essential, I guess. except I find it harder to read. What do you think is the advantage of yours over mine? Your approach a = re.sub ( '-', '- ', a)# split words with - applies a rule which holds for most cases, but not all cases. Therefore, you introduce another rule +a = re.sub ( ' - - ', ' -- ', a) # unless was originally -- to compensate for the error in the first rule. Why not fixing the original rule rather than adding another rule for compensation? Compensation usually increases the oevrall complexity and thereby makes the code difficult to understand. As far as readability is concerned, well, this probably depends on the point of view. Looking at your compensation rule, I find it difficult to understand, as it is not immediately clear to me, what happens if e.g. you have --- or similar. My suggested rule simply says: replace - by - if and only if there is not another - immediately before or after the -, and no further compensation is needed (hopefully). This is quite clear to understand, isn't it? ;-) The code I tested on was: The normal way to type multiple syllables in ABC: a = mul- ti- ple syl- la- bles Where your version produces: a = re.sub ( '([^-])-([^-])', '\\1- \\2', a) print a mul- ti- ple- syl- la- bles ... There shouldn't be a hyphen after ple. I hope, that's just a typo? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Longa notes
On Wed, 4 Oct 2006, Juergen Reuter wrote:
That is, lily should take a longa from neo-mensural font. The real problem
is the 'u' in 'noteheads.u-2': The parmesan font defines a symmetric
'noteheads.s-2neomensural', but neither up/down specific heads.
On a second thought, not the u is a problem, but the error message is
wrong. The attached patch fixes the wrong error message (but not the
original problem; that's a different issue). Should I apply the patch?
Greetings,
JuergenIndex: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5374
diff -u -r1.5374 ChangeLog
--- ChangeLog 4 Oct 2006 19:53:54 - 1.5374
+++ ChangeLog 4 Oct 2006 20:37:25 -
@@ -1,3 +1,7 @@
+2006-10-04 Jürgen Reuter [EMAIL PROTECTED]
+
+ * lily/note-head.cc: Fixed programming_error message.
+
2006-10-04 Graham Percival [EMAIL PROTECTED]
* Documentation/user/advanced-notation.itely: added
Index: lily/note-head.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/note-head.cc,v
retrieving revision 1.167
diff -u -r1.167 note-head.cc
--- lily/note-head.cc 5 May 2006 11:26:06 - 1.167
+++ lily/note-head.cc 4 Oct 2006 20:37:25 -
@@ -43,8 +43,9 @@
Font_metric *fm = Font_interface::get_default_font (me);
- string idx = noteheads.s + suffix;
- Stencil out = fm-find_by_name (idx);
+ string idx_symmetric, idx_directed, idx_either;
+ idx_symmetric = idx_either = noteheads.s + suffix;
+ Stencil out = fm-find_by_name (idx_symmetric);
if (out.is_empty ())
{
string prefix = noteheads.;
@@ -55,18 +56,20 @@
if (stem_dir == CENTER)
programming_error (must have stem dir for note head);
- idx = prefix + ((stem_dir == UP) ? u : d) + suffix;
- out = fm-find_by_name (idx);
+ idx_directed = idx_either =
+ prefix + ((stem_dir == UP) ? u : d) + suffix;
+ out = fm-find_by_name (idx_directed);
}
if (out.is_empty ())
{
- me-warning (_f (note head `%s' not found, idx.c_str ()));
+ me-warning (_f (none of note heads `%s' or `%s' found,
+ idx_symmetric.c_str (), idx_directed.c_str ()));
out = Stencil (Box (Interval (0, 0), Interval (0, 0)), SCM_EOL);
}
else
-*font_char = idx;
+*font_char = idx_either;
return out;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Another patch (this one is important) to abc2ly
a = re.sub ( '-', '- ', a)# split words with - +a = re.sub ( ' - - ', ' -- ', a) # unless was originally -- Just being curious: Maybe I am totally wrong (since I do not know the abc format in detail), but shouldn't this be rather something like a = re.sub ( '([^-])-([^-])', '\\1- \\2', a)# split words with - unless was originally -- or similar (untested)? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: petrucci-f3 clef
Hi, Pal! Nice to see you back on this list! Mmmh, do you know when Petrucci engraved this piece of music? Petrucci is known to have started with beautiful printings around 1600. At that time, he demonstrated what is possible with printing as compared to manual writing, because he wanted to compete with manual writings and had to convince musicians and publishers/copyers of what is technical possible. However later, due to lack of money of his customers, he had to simplify his process of printing. Maybe this simplification also affected the choice of clefs? I do not see any other reason why Petrucci should have perfectly balanced all clefs, but not the f3/f4 clef, other than maybe he was lacking a sufficient number of printing types. As far as I know, many pages of a book were printed in parallel (rather than one page after the next one), for whatever reason, such that a huge number of identical types had to be used at the same time. So, maybe he just run out of a particular printing type such as the f4 clef and chose the f3 clef instead (or the other way around)? In doubt, we should decide in favour of the beauty of printing. What do you think, does the overall appearance of a piece of music improve with the change that you propose? Greetings, Juergen On Wed, 27 Sep 2006, Pal Benko wrote: 2006-09-26 Pal Benko [EMAIL PROTECTED] * scm/parser-clef.scm: add petrucci-f3 and -f4 clefs (the latter is the same as petrucci-f which is kept for compatibility) Petrucci uses the exact same drawing for the f3 clef as for f4, just a line lower (at least in the Missae Obrecht). pal Index: parser-clef.scm === RCS file: /sources/lilypond/lilypond/scm/parser-clef.scm,v retrieving revision 1.2 diff -u -r1.2 parser-clef.scm --- parser-clef.scm 6 Jan 2006 09:13:22 - 1.2 +++ parser-clef.scm 26 Sep 2006 18:39:15 - @@ -60,6 +60,8 @@ (petrucci-c3 . (clefs.petrucci.c3 0 0)) (petrucci-c4 . (clefs.petrucci.c4 2 0)) (petrucci-c5 . (clefs.petrucci.c5 4 0)) +(petrucci-f3 . (clefs.petrucci.f 0 0)) +(petrucci-f4 . (clefs.petrucci.f 2 0)) (petrucci-f . (clefs.petrucci.f 2 0)) (petrucci-g . (clefs.petrucci.g -2 0 ___ 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: petrucci-f3 clef
Oh, sorry! Please forget about my last mail; it's nonsense; I looked wrong at the patch and thought you wanted to change c clefs, rather than adding 2 f clefs. Your patch looks perfect! Maybe I have slept too little... Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing the midi instrument; broken
On Sun, 27 Aug 2006, Mats Bengtsson wrote:
Some further clarifications below.
...
However, as Erik says below, if you want to store the lyrics into a variable,
you have to do
mylyrics = \lyricmode { Here is my ly -- rics }
and then \lyricsto ... \mylyrics
Still remains the question why at all you would want to store the lyrics
into a variable.
Possible answer: Because you want to reuse the same lyrics at multiple
places in the score.
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond ChangeLog lily/instrument-name-engrave...
On Wed, 26 Jul 2006, Han-Wen Nienhuys wrote:
...
Index: lily/instrument-name-engraver.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/instrument-name-engraver.cc,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -b -r1.86 -r1.87
--- lily/instrument-name-engraver.cc26 Jul 2006 11:40:14 - 1.86
+++ lily/instrument-name-engraver.cc26 Jul 2006 11:57:22 - 1.87
@@ -41,13 +41,13 @@
if (!text_spanner_)
{
SCM long_text = get_property (instrument);
Shouldn't this be instrumentName?
Greetings,
Juergen
@@ -115,9 +115,9 @@
/* read */
currentCommandColumn
- instr
- instrument
- vocNam
+ shortInstrumentName
+ instrumentName
+ shortVocalName
vocalName
,
...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Problem with partial
Oh, true. Yes, I remember having seen these double bar-like lines in the middle of a bar, now that you are mentioning it. So, summarizing, we actually have two totally different types of bar lines: * Pseudo bar lines, which are actually sectioning marks (||, repeat signs). Virtually, they may appear anywhere in a bar; and they should not affect the bar number. * True bar lines, which indicate where the heavy beat is. The bar number should increase only after a true bar line (unless manually tweaked). I am not sure, if line breaks by default should be allowed only on true bar lines or also on pseudo bar lines. Greetings, Juergen On Mon, 10 Jul 2006, Anthony Youngman wrote: The repeat sign probably should include a double bar line ... In my type of music (concert, brass band) it is quite normal to put a double bar line in the middle of a bar when there is a major section change, eg at the Trio. I've never come across a repeat in the middle of a bar, though... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] u.org] On Behalf Of Juergen Reuter Sent: 07 July 2006 17:31 To: Mats Bengtsson Cc: lilypond-devel@gnu.org; Juergen Reuter Subject: Re: Problem with partial Ah, ok; I understand. Still, I think that using \partial in this situation is kind of abuse that accidentally works. I guess the real problem here is that lily models repeat signs as bar lines; but I am also wondering how a repeat sign should actually look like, if it does not coincide with the bound of a bar (it probably should not consist of a vertical line)... Greetings, Juergen On Thu, 6 Jul 2006, Mats Bengtsson wrote: One common example where people today use it in the middle of a score is repeats, where the repeat sign is in the middle of a bar (especially in combination with prima/secunda volta). Currently, LilyPond doesn't automatically take this into account. Of course, the best solution in this situation would be if LilyPond treated the measure position correctly for repeats. /Mats Quoting Juergen Reuter [EMAIL PROTECTED]: Hi all, please note that \partial or \upbeat, whatever you call it, has musicologically a special meaning: the first, incomplete bar, and the last bar of a piece or of a major section of a piece (typically the bar before the next || bar glyph) should sum up to a complete bar. For example, if a song with 4/4 meter starts with \partial 4 f4, the last bar should, by convention, have a total length of 3 quarter notes. Having said that, you never should use \partial or \upbeat somewhere within a piece. If lily nevertheless accepts it within a piece without issuing an error or warning, I consider this a bug. Having a bar within a piece that differs in length from the foreassigned meter is a different concept. Greetings, Juergen On Thu, 6 Jul 2006, Graham Percival wrote: Erik Sandberg wrote: On Wednesday 05 July 2006 17:54, Graham Percival wrote: IMO, \partial is just fine. If there's some confusion, by all means we can clarify the docs. As always, I gratefully accept any specific recommendations for doc changes. IMHO using \partial in the middle of a bar is confusing; I think there should be some other command that sets the length of an individual bar. Do you think it would make sense to invent such a command? I'd rather keep the behavior of \partial -- ie add an extra X duration to this bar, rather than this bar should have X duration. That said, I suppose we could rename \partial to \addTime or something like that. I don't think that \upbeat is appropriate, but we could find some other name. Cheers, - Graham ___ 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel * * This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. * * ___ lilypond-devel mailing list
Re: Problem with \partial
On Fri, 7 Jul 2006, Graham Percival wrote:
In my example, I _did_ state
\noTimeSignature
c4 c c c | d d d d \partial 4 d | c c c c
... and some contemporary music may want to change the number of beats in a
bar without changing the notated time signature. Whatever we think of that
practice (and I dislike it too :) , I don't think we should explicitly
disallow it inside lilypond.
Cheers,
- Graham
... want to change the number of beats just in a single bar or in many
bars? When bars are frequently changing in length, you probably want to
completely forget about the meter and do something like this:
\version 2.9.0
sep = \bar |
\score {
\transpose c c' {
c4 d \sep
e f g \sep
f e d c \bar |.
}
\layout {
\context {
\Staff
\remove Time_signature_engraver
}
\context {
\Score
timing = ##f
}
}
}
If you just want to change the meter for a single or very few bars, you
really should do it with the \time command (because that is what \time is
for). If you do not like the time signature change to be printed, you
still can remove the time signature engraver or set it to transparent.
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with partial
Ah, ok; I understand. Still, I think that using \partial in this situation is kind of abuse that accidentally works. I guess the real problem here is that lily models repeat signs as bar lines; but I am also wondering how a repeat sign should actually look like, if it does not coincide with the bound of a bar (it probably should not consist of a vertical line)... Greetings, Juergen On Thu, 6 Jul 2006, Mats Bengtsson wrote: One common example where people today use it in the middle of a score is repeats, where the repeat sign is in the middle of a bar (especially in combination with prima/secunda volta). Currently, LilyPond doesn't automatically take this into account. Of course, the best solution in this situation would be if LilyPond treated the measure position correctly for repeats. /Mats Quoting Juergen Reuter [EMAIL PROTECTED]: Hi all, please note that \partial or \upbeat, whatever you call it, has musicologically a special meaning: the first, incomplete bar, and the last bar of a piece or of a major section of a piece (typically the bar before the next || bar glyph) should sum up to a complete bar. For example, if a song with 4/4 meter starts with \partial 4 f4, the last bar should, by convention, have a total length of 3 quarter notes. Having said that, you never should use \partial or \upbeat somewhere within a piece. If lily nevertheless accepts it within a piece without issuing an error or warning, I consider this a bug. Having a bar within a piece that differs in length from the foreassigned meter is a different concept. Greetings, Juergen On Thu, 6 Jul 2006, Graham Percival wrote: Erik Sandberg wrote: On Wednesday 05 July 2006 17:54, Graham Percival wrote: IMO, \partial is just fine. If there's some confusion, by all means we can clarify the docs. As always, I gratefully accept any specific recommendations for doc changes. IMHO using \partial in the middle of a bar is confusing; I think there should be some other command that sets the length of an individual bar. Do you think it would make sense to invent such a command? I'd rather keep the behavior of \partial -- ie add an extra X duration to this bar, rather than this bar should have X duration. That said, I suppose we could rename \partial to \addTime or something like that. I don't think that \upbeat is appropriate, but we could find some other name. Cheers, - Graham ___ 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with \partial
Hi all, please note that \partial or \upbeat, whatever you call it, has musicologically a special meaning: the first, incomplete bar, and the last bar of a piece or of a major section of a piece (typically the bar before the next || bar glyph) should sum up to a complete bar. For example, if a song with 4/4 meter starts with \partial 4 f4, the last bar should, by convention, have a total length of 3 quarter notes. Having said that, you never should use \partial or \upbeat somewhere within a piece. If lily nevertheless accepts it within a piece without issuing an error or warning, I consider this a bug. Having a bar within a piece that differs in length from the foreassigned meter is a different concept. Greetings, Juergen On Thu, 6 Jul 2006, Graham Percival wrote: Erik Sandberg wrote: On Wednesday 05 July 2006 17:54, Graham Percival wrote: IMO, \partial is just fine. If there's some confusion, by all means we can clarify the docs. As always, I gratefully accept any specific recommendations for doc changes. IMHO using \partial in the middle of a bar is confusing; I think there should be some other command that sets the length of an individual bar. Do you think it would make sense to invent such a command? I'd rather keep the behavior of \partial -- ie add an extra X duration to this bar, rather than this bar should have X duration. That said, I suppose we could rename \partial to \addTime or something like that. I don't think that \upbeat is appropriate, but we could find some other name. Cheers, - Graham ___ 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: user manual
On Thu, 6 Jul 2006, Mark Van den Borre wrote: Graham, General improvements to working on lilypond files, focusing on teaching users how to write files that are easier to update. Not that it will do any good, since nobody reads the manual anyway. I was not aware that you underestimate the relevance of your work so much. It is a splendid piece of work and very important to the Lilypond user experience. ... 100% agreed! At least, I *do* read now and then in the manual, and it's now _extremely_ better than, say, 2 or 3 years ago! Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: test results available!
On Wed, 7 Jun 2006, Han-Wen Nienhuys wrote: ... I changed this a bit. Now, you need to use http://lilypond.org/doc/v2.9/compare-v2.8.4/index.html Maybe you should correct the broken link on http://lilypond.org/web/index ? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug?] eps versus pdf problem?
Hi, the white mensural ligature example lily-2147380820.ly in Sect. 7.7.10.1 collapses in the HTML manual to a width of a few pixels (see the _first_ (almost invisible) png image in http://lilypond.org/doc/v2.9/Documentation/user/lilypond/White-mensural-ligatures.html). However, in the PDF manual, the same example shows up perfectly. Hence, I guess this behaviour is probably an eps versus pdf problem rather than a problem of the ligature implementation, right? Greetings, Juergen P.S.: I can eliminate the symptom in the manual by slightly modifying the example, but I guess finding the bug would be more satisfactory... ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Scripts Manual Sect. 6.6.1 (Articulations)
Hi, just a comment to Sect. 6.6.1 (Articulations): IMHO, the signum congruentiae, all fermatas, the segno sign and the coda signs are no articulation signs. Historically, they were put together with the articulation signs into the same manual section, because their implementation was based on the same piece of C++ code. Musicologically, I think they should go into a separate section, maybe called Rehearsal directives or similar. Or maybe they should be just merged into Sect. 8.2.3 (Rehearsal marks)? However, I am not sure what you would do about the Commonly tweaked properties paragraph in 6.6.1 when splitting this section (Duplicate it? Add a See also?). Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Bug?] Concatening syllables
Hi,
Sect. 7.3.2 (Entering lyrics) of the manual says:
In order to assign more than one syllable to a single note, you must
surround them with quotes or use a _ character between the syllables.
This works fine e.g. for:
\addlyrics { gran- de_a- mi- go }
However, neither
\addlyrics { gran- \lyricmode { de }_a- mi- go }
nor
\addlyrics { gran- \lyricmode { de_ }a- mi- go }
nor
\addlyrics { gran- \lyricmode {de}_a- mi- go }
works as expected (the _ just shows no effect at all). I need this
problem get fixed in order to get \versus, \responsum commands of ancient
notation properly working, such that you can e.g. say:
\addlyrics { \versus_Here comes the text. }
(where \versus constructs a special char, see ly/gregorian-init.ly).
Any ideas?
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with spanish update (Re: My patch to music glossary)
On Tue, 30 May 2006, Francisco Vila wrote: Also, after a '$ cvs co' my local copy has strange ''- and ''-filled lines surrounding some of my changes, don't know if they have been applied or not. So I really don't know how to obtain a second patch from this. See: http://www.tigris.org/nonav/scdocs/ddCVS_cvscontributing.html#cvsresolving However, this should not happen with cvs co. At least in the HEAD of the 2.9 branch, I can not see an unresolved conflict. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autotester: FAIL make BRANCH=HEAD darwin-ppc
Hi, just being curious: is it intended that these Autotester messages are sent to lilypond-cvs rather than just to the author/committer of the changes? Greetings, Juergen P.S.: By the way, what is the Autotester? Is it run upon every cvs commit? Is a commit rejected, if the test fails? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gregorian chant improvement
By the way, you may also be interested in the following related work from a workshop on Braille Notation of Psalmodia and Gregorian Chant, held in Marburg, Germany, on October 2-3, 2002: http://www.sbs-online.ch/musik/conference/documents/gregor.pdf In order to make Gregorian chant notation readable for blind people, the authors define how to decompose complex neumes into primitives, which in turn are mapped to braille. In fact, their breaking-down approach is very similar to what lily does, such that it should not be too complicated to implement their specification as an extension to LilyPond (which would probably be a nice student project). Greetings, Juergen On Tue, 21 Mar 2006, Elie Roux wrote: ... 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). ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Separation_item problem
Hi,
I have been trying to fix the misplaced dot bug in Gregorian chant
notation -- without sucess:
void
Vaticana_ligature_engraver::add_mora_column (Grob *parent)
{
if (!parent) // empty ligature
return;
if (augmented_primitives_.size () == 0) // no dot for column
return;
Item *dotcol = make_item (DotColumn, SCM_EOL);
for (vsize i = 0; i augmented_primitives_.size (); i++)
{
Item *dot = make_item (Dots, augmented_primitives_[i]-self_scm ());
dot-set_parent (augmented_primitives_[i], X_AXIS);
dot-set_parent (parent, Y_AXIS);
dot-set_property (Y-offset, Grob::x_parent_positioning_proc);
augmented_primitives_[i]-set_object (dot, dot-self_scm ());
Axis_group_interface::add_element (dotcol, dot);
Side_position_interface::add_support (dot, augmented_primitives_[i]);
Pointer_group_interface::add_grob (dot, ly_symbol2scm (note-heads),
augmented_primitives_[i]);
Dot_column::add_head (dotcol, augmented_primitives_[i]);
}
}
The above code should create a dot column, which should be horizontally
placed immediately behind Grob *parent. The dot column should consist of
a number of dots, one for each notehead grob held in the
vectorItem * augmented_primitives_
variable.
The only thing that this code produces is a Separation_item: I've been
drinking too much error, and no dot is printed.
Once, when writing the porrectus engraver, I had similar problems, and as
the cause, I suspected the discrepancy between the column of the music
cause and the column of where to print the outcome. This discrepancy is
also true in the above code: the notehead, which is the cause of the dot,
may arise earlier in time than the column where the dots are collected.
Has someone an idea how I can fix this problem?
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug?] lily chokes on unavailable unicode char
Hi, lyrics with non-latin characters, such as in input/sakura-sakura.ly, basically compile fine on my machine without any error message, and the output looks fine. If, however, I replace one of the non-latin characters with an obviously unavailable utf-8 code (at least with the fonts currently installed on my machine) such as the character with the code (hexadecimal) 211F or 2123, lily spits out the following messages: warning: no PostScript font name for font `/usr/share/fonts/bitmap-fonts/10x20.pcf' warning: FreeType face has no PostScript font name programming error: Improbable offset for stencil: -inf staff space Setting to zero. continuing, cross fingers That is, lily does not even consider that a unicode character may not be available? By the way, do you know of any freely available fonts that include characters 211F and 2123? It would be nice to have them for Gregorian chant notation. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request: Hairpin.hairpinFullLength
On Tue, 11 Apr 2006, Graham Percival wrote: (this'll probably get lost while HWN is away, but anyway...) From the docs, A hairpin starts at the left edge of the beginning note and ends on the right edge of the ending note. tupletFullLength (boolean) If set, the tuplet is printed up to the start of the next note. Could we have a feature, similar to tupletFullLength, which places the end of a hairpin just before the start of the next note? And a similar thing for TextSpanner would probably fix the \episem, which broke at some time during the 2.7 series (see manual Sect. 7.7.7). It seems that, for TextSpanners, the FullLength behavior is now always true, while it must be false for the \episem. Or do I miss something? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
Hi, maybe I should also comment on this topic, since I originally contributed the whole polygon stuff in order to implement clusters, and thus still feel (very) little responsible for it. ;-) As for the triangle, yes, I also think it _is_ abuse to use the blot-diameter in order to control the line thickness of an unfilled polygon. In fact, an unfilled polygon should ideally have two separate parameters for controlling line thickness and blot-diameter. However, implementing such a drawing routine for unfilled polygons appears quite complicated to me. At least, you could re-use the polygon shrinking algorithm in lookup.cc in order to calculate the edges of the inner path of the polygon outline. However, the restrictions mentioned in lookup.cc would unfortunately also apply. BTW, I just noticed, that in define-markup-command.scm, markup commands draw-cricle and beam have an explicit thickness parameter, while all other markup commands retrieve the thickness value from the props parameter. Maybe this could be made more consistent. Greetings, Juergen On Wed, 12 Apr 2006, David Feuer wrote: On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: Indeed; no need for an assert. But in that case ... found it define-markup-command.scm: (define-markup-command (triangle layout props filled) (boolean?) A triangle, filled or not we use it to draw `white' triangles for chords... Yuck. This makes a great argument for my proposal to get the arbitrary Scheme code out of stencils (so there's only -one- place in the source that produces output code). The easiest way to keep this working the same as it does now is to name my new functions filled-polygon and retain the old (really simple) polygon drawers in the backends. The polygon procedure in lookup.cc can still go away. I'm a bit curious, though, why the triangles are done that way, which lets the blot exceed the normal bounds. If that behavior is a bug, then something else will need to be done. One option might be to make triangle-shrinking code, which would be a bit icky, but not as icky as general polygon-shrinking code, because triangles have some pretty nice geometric properties. I have another couple ideas, but I'm still working those out. David ___ 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: State of the docs, April 2006
On Tue, 11 Apr 2006, Graham Percival wrote:
...
TEMPLATES
Lilypond knowledge required: moderate
Estimated time: 5 hours
Do all the templates in chapter 3 work? I know that the Jazz ensemble one
is very old, and is generally icky. If nobody updates it, I think we should
just delete it. I don't know what the status is on the other templates. In
addition, all the templates should follow the same general style.
Attached is a diff that makes the template working again, with a minimal
set of changes. Still, the general style of the template is rather
peculiar, such that the comments immediately before the template still
hold. I do not know if this patch is of any value for user reading the
manual, but at least it fixes the appearance of the example.
Greetings,
JuergenIndex: examples.itely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/examples.itely,v
retrieving revision 1.60
diff -u -r1.60 examples.itely
--- examples.itely 28 Mar 2006 20:47:21 - 1.60
+++ examples.itely 12 Apr 2006 21:52:52 -
@@ -1033,8 +1033,12 @@
composer = Me
meter = moderato
piece = Swing
- tagline = LilyPond example file by Amelie Zapf,
- Berlin 07/07/2003
+ tagline = \markup {
+\column {
+ LilyPond example file by Amelie Zapf,
+ Berlin 07/07/2003
+}
+ }
texidoc = Jazz tune for combo
(horns, guitar, piano, bass, drums).
}
@@ -1082,7 +1086,7 @@
\global
\set Staff.instrument = #Trumpet
\clef treble
- \new Staff
+
\trpt
}
@@ -1099,7 +1103,7 @@
\global
\set Staff.instrument = #Alto Sax
\clef treble
- \new Staff
+
\alto
}
@@ -1116,7 +1120,7 @@
\global
\set Staff.instrument = #Bari Sax
\clef treble
- \new Staff
+
\bari
}
@@ -1133,7 +1137,7 @@
\global
\set Staff.instrument = #Trombone
\clef bass
- \new Staff
+
\tbone
}
@@ -1153,7 +1157,7 @@
\global
\set Staff.instrument = #Guitar
\clef treble
- \new Staff
+
\gtr
}
@@ -1185,7 +1189,7 @@
\clef treble
\global
\set Staff.midiInstrument = acoustic grand
- \new Staff
+
\new Voice = one \rhUpper
\new Voice = two \rhLower
@@ -1194,14 +1198,14 @@
\clef bass
\global
\set Staff.midiInstrument = acoustic grand
- \new Staff
+
\new Voice = one \lhUpper
\new Voice = two \lhLower
}
piano = {
- \new PianoStaff
+
\set PianoStaff.instrument = #Piano
\new Staff = upper \PianoRH
\new Staff = lower \PianoLH
@@ -1217,7 +1221,7 @@
\global
\set Staff.instrument = #Bass
\clef bass
- \new Staff
+
\Bass
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docu Sect. 3.5.2
The introduction for the Gregorian transcription template currently says: This example demonstrates how to do modern transcriptions of Gregorian music. Gregorian music has no measure, no stems; it uses only half and quarter notes, and two types of barlines, a short one indicating a rest, and a second one indicating a breath mark. The template has been recently updated, such that the text is now somewhat outdated. I would like to propose a slightly modified text, maybe something like: This example demonstrates how to do modern transcription of Gregorian music. Gregorian music has no measure, no stems; it uses only half and quarter noteheads, and special marks, indicating rests of different length. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docu Sect. 7.7.10.2
Hi,
considering the recent misreading of lily's Gregorian chant capabilities
that could be seen on this list, I would like to propose a minor update
with clarifications to Sect. 7.7.10.2. See attachment.
Greetings,
JuergenIndex: Documentation/user/instrument-notation.itely
===
RCS file:
/cvsroot/lilypond/lilypond/Documentation/user/instrument-notation.itely,v
retrieving revision 1.80
diff -u -r1.80 instrument-notation.itely
--- Documentation/user/instrument-notation.itely5 Apr 2006 00:01:18
- 1.80
+++ Documentation/user/instrument-notation.itely12 Apr 2006 23:37:30
-
@@ -3881,6 +3881,20 @@
@code{\[ \stropha b \stropha b \stropha a \]}
@end multitable
+The ligatures listed above mainly serve as a limited, but still
+representative pool of Gregorian ligature examples. Virtually, within
+the ligature delimiters @code{\[} and @code{\]}, any number of heads
+may be accumulated to form a single ligature, and head prefixes like
[EMAIL PROTECTED], @code{\flexa}, @code{\virga}, @code{\inclinatum},
+etc. may be mixed in as desired. The use of the set of rules that
+underlies the construction of the ligatures in the above table is
+accordingly extrapolated. This way, infinitely many different
+ligatures can be created.
+
[EMAIL PROTECTED] TODO: create a regression or tips tricks example document
with
[EMAIL PROTECTED] even more Gregorian ligatures, and add a link to this document
[EMAIL PROTECTED] here.
+
@refcommands
The following head prefixes are supported
@@ -3902,7 +3916,11 @@
@cindex @code{\quilisma}
@code{\quilisma},
@cindex @code{\deminutum}
[EMAIL PROTECTED]
[EMAIL PROTECTED],
[EMAIL PROTECTED] @code{\cavum}
[EMAIL PROTECTED],
[EMAIL PROTECTED] @code{\linea}
[EMAIL PROTECTED]
Head prefixes can be accumulated, though restrictions apply. For
example, either @code{\descendens} or @code{\ascendens} can be applied
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Page and line penalties
On Fri, 7 Apr 2006, Joe Neeman wrote: [...] OK, so the solution will always have a certain level of instability. Just to put some idea of scale on my previous example graphs, it's possible that LilyPond will be tossing up between using 5 systems and using 10 systems. 5 systems provides much better spacing but 10 systems has less penalties. The total badness is _slightly_ less for 5 systems so Lily goes with that. Then the user inserts an extra bar and the number of systems doubles. I think that instability shouldn't occur on this scale. Now, I haven't been playing around with any line penalties, but I have done experiments with page turn penalties and I have seen scores go from 5 to 8 pages with only small changes. Maybe I am totally wrong, but this discussion reminds me of an issue that I raised on Nov 18, last year; see the thread starting here: http://lists.gnu.org/archive/html/lilypond-devel/2005-11/msg00088.html I am mentioning this thread just in case that you are looking for interesting test examples. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Style
Hi, indeed, this topic has been brought up at least in early 2003 (maybe even earlier) and also went into Han-Wen's and Jan's XIV CIM 2003 paper (see right column of page 4 in this paper). There _is_ already an implicit way of writing style sheets (although somewhat limited), but let me explain in detail, using ancient notation as an example. Lily's ancient notation has been designed from its very beginning with having in mind the principle of separating musical content from notational style. A convincing argument for doing so is, for example, the task of generating both, old (i.e. original) and new (i.e. transcibed) notation of an ancient piece from a single source. This is done by controlling a bunch of grob and context properties, such as TimeSignature #'style. Nowadays, in Lily you could achieve the goal of creating old and new notation from the same source with the \tag command, but it is still handy to collect control of style at a central spot in the source, rather than scattering tagged \set or \override commands all over the source. The point here is, that you may want to change whatever aspect of the notational style at a central place rather than having to scan through the whole source and maybe need to introduce a new tag name. In Lily, the notational style is currently unfotunately not explicitly factored out into a separate style file like .css or .sty. Still, it is in most cases possible and usually good practice to set such properties only once per staff (or score) at the beginning of the piece. Following this thought a little bit further, there actually _is_ a (limited) way of separating style into a different file. For example, the context definitions of VaticanaVoice and VaticanaStaff in ly/engraver-init.ly in combination with the definitions in ly/gregorian-init.ly initialize a bunch of properties, such that you will get ancient notation. If you replace all occurrences of \VaticanaStaff and \VaticanaVoice with \GregorianTranscriptionVoice and \GregorianTranscriptionStaff, you should (at least in theory) get the same music, but in contemporary notation. This way, the context definitions in ly/engraver-init.ly serve as predefined style sheets for a selected number of styles (at least for ancient notation). You can add new styles by overriding these context definitions. That is, writing a style sheet in Lily currently reduces to the matter of redefining context definitions. Greetings, Juergen On Tue, 4 Apr 2006, David Feuer wrote: I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, and I would suggest that Lilypond might do something similar: let users name timesteps, timestep edges, measures, and categories of such, and format them according to a separate program. Obviously this would be loads of work, and I don't even know if it would be feasible, but that's what I'm thinking. David Feuer ___ 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: Tremolo positioning
Please note that the property name style currently (hopefully) consistently denotes _font_ style. It is defined with this meaning for noteheads, rests, accidentals, time signatures, flags, and custos. Nowadays, that Lily supports subproperties (cp. manual Sect. 9.1.4 or 9.2.1), maybe, on the long term, the property style should be split into subproperties font and shape or similar? Then you could use subproperty shape of property style for stem tremolos. I _really_ would prefer to keep the naming of properties as consistent as possible. Greetings, Juergen On Wed, 29 Mar 2006, Han-Wen Nienhuys wrote: Joe Neeman wrote: On Tue, 28 Mar 2006 20:20, Han-Wen Nienhuys wrote: Han-Wen Nienhuys wrote: Can you resend the patch using more idiomatic code? Thanks! Also, can you include a small regression test sample, so it's obvious when we break something? I'm not quite sure if we reached a conclusion on the default behaviour of tremolos and I'm also not quite sure what the protocol is for adding things to interfaces (I added style to stem-tremolo-interface. It can be 'rectangle or 'default) but here is another try anyway. I also enclose a looks good, although default is usually signaled with '() regression test and an image of the output. thanks. I've added your changes to 2.9 ; I'll probably backport the diff of 2.9.0 to 2.8.1 as a whole. Can you look at the regtests stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor them so they don't have overlaps? thanks for your patch! ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
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
