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: 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: 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: 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:
...
I have worked today on a draft, simple incipit engraver, with clef,
key signature and time signature. Might someone comment on it? I have
no experience with that part of the code. If something can be made
more eleguant, please speak :-)
Thanks a lot! To me, your code looks fine, except for the condition
+ if (clef_)
+clef_ = key_signature_ = time_signature_ = 0;
which probably should be something like:
+ if (clef_ || key_signature_ || time_signature_)
+clef_ = key_signature_ = time_signature_ = 0;
Or maybe completely remove the condition.
However, I see a very important feature missing in this approach:
An incipit should (at least in my view) be thought of as the beginning of
a piece written in notation that comes close to the autograph or first
publishing. That is, the incipit actually starts the music. Then, at
some point (e.g. after the clef or after the first note of each voice or
after the first few notes), the music is reset to its start, the notation
switches to modern style, and printing starts again, this time from the
very beginning to the very end.
In particular, as Laura points out, many people want to include one or
more notes in the incipit. More generally, virtually any music expression
could appear in an incipit -- it's just printed in an old-fashioned style
or otherwise coming much closer to the original.
Thus, the ideal behavior of an incipt engraver would be to ordinary start
printing the piece, using (for example) a mensural context and the info
from IncipitClef, IncipitSignature, and IncipitTimeSignature. Then, when
the InciptEngraver has done its work, the music should rewind back to the
very beginning, and ordinary type setting should start.
A couple of weeks ago, I think I already posted the idea of having a
scheme function, say "\makeIncipit { }", that takes all
of the music as argument and creates from it another music expression with
the incipit. You could then say something like "\makeIncipt { }
" to create the incipit, followed by the actual music. However
note, that currently it is not possible to implement such a scheme
function for several technical details, such as the system start delimiter
that would also have to be placed *after* the incipit. Maybe with some
more changes at your incipit engraver, this engraver can be used to
actually implement the "\makeIncipit" scheme function. This is what I
thought of when I used the word "challenging". ;-)
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: [patch] first-clef property
Hmmh, maybe I do not understand correctly, but wouldn't it be possible to
get equivalent behavior with tagged music? I mean, put both \clef
commands ('\clef "soprano"' and '\clef "treble"') into the code, put
different tags on each of them, and then "turn" them "on/off" or switch
between the two editions by filtering the music for the proper tags.
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.
Greetings,
Juergen
On Fri, 1 Feb 2008, Nicolas Sceaux wrote:
Hi,
When typesetting ancient music, one may want to produce two editions:
eventually one with original clefs, as found in the manuscripts, and an
other one with new fashioned clefs. It is also custom in the later case
to print first the ancient clef (which bears some extra meaning, for
instance which particular instrument should play that part), then the
modern one, at the beginning of a piece.
I use a customized version of the \clef command, which allows specifying
two clefs, eg. \clef "soprano/treble". If some option is set, it behaves
like \clef "soprano", otherwise it behaves like \clef "treble", except
at the beginning of the first line, where a little soprano clef is
printed before the treble clef. The first-clef property makes it
possible to detect when it is the beginning of the piece.
The attached patch adds this first-clef grob property. May I apply it?
I understand that it may not be preferable to add code that presumably
would be useful to a single person... but this patch is very tiny :-)
And I've seen some posts showing interest for this kind of feature.
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 Tue, 29 Jan 2008, Han-Wen Nienhuys wrote:
2008/1/27, Juergen Reuter <[EMAIL PROTECTED]>:
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)?
this distinction is not in the music 'type-system', but rather how the
events are attached to other things. Beam/slur/etc. start/stop are
attached to the notes, so in
c4]
the ] starts at the beginning of the note. Commands like \bar , \clef
and \] are not attached to notes, so for
c4 \]
the event registers at the end of the note, at the start of the new time-step.
Aah, ok, I see.
I don't know what the best solution is, but for consistency, it would
probably be best if they were attached to notes like beams.
Yes. Honestly speaking, I did not feel too much comfortable, when the
post attributes-like "c4[ c4]" kind of notation for slurs and beams was
introduced. But you are right, for the sake of consistency, ligature
notation probably should follow this approach, too (as already mentioned
in the docs, btw.).
The
downside to attaching to notes is that you would not be able to do
ligs = { \[ s2 \] }
<< { c8 d e f }
\ligs >>
and have the ligature enclose the 4 notes.
I think this is a non-issue, because having a ligature in one voice
definitely does not imply that there are simultaneous ligatures in other
voices. That is, in the above example, having the ligature enclose the 4
notes would actually be a bug. By the way, if you are using ligature
brackets, there should be only a single voice per staff anyway; otherwise,
the notation would easily become confusing for the human reader (i.e.
which ligature bracket belongs to which notes, etc.).
(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).
maybe you can update the relevant web-pages? That would be a useful
exercise in git use :-)
You should claim sponsoring from the git guys for advertising and
spreading use of their piece of software among the lilypond community! :-)
Ok, I will eventually try, as soon as I find some time to browse through
the git docs!
Greetings,
Juergen
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 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: 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: 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: musicxml merge
On Thu, 13 Sep 2007, Han-Wen Nienhuys wrote:
2007/9/13, Reinhold Kainhofer <[EMAIL PROTECTED]>:
+if filename[-1] == '.':
+filename += "xml"
+elif not re.match ("\.xml$", filename):
+filename += ".xml"
this looks a bit strange.
Do you mean a boolean or here?
No, I'm checking the filename and appending .xml if it's not there (or only
xml if the filename already ends in a "."). The logic is:
If file with given filename exists => Use that filename
both if-bodies are the same. That can't be right.
Isn't the right thing to completely drop the first "if"? If a user really
choses a filename that ends with ".", I think the correct behavior
is to append ".xml" (rather than just "xml"). For example, imagine a
windows user chosing the filename "This is a complete sentence." If you
only append "xml", the dot will disappear from the filename that is
displayed to the user in the windows GUI. I think, the correct full
filename should in this case be "This is a complete sentence..xml". Or do
I miss something?
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: exchanged accidentals in MensuralVoice?
On Wed, 28 Feb 2007, Werner LEMBERG wrote: [lilypond 2.11.20] Looking at section 7.7.12, `Mensural contexts', it seems to me that the sharp and flat accidentals are intermixed. The `fis' looks like having a flat accidental, and the bes as if it had a sharp sign. Right, this looks like a very recently introduced bug. Note that in section 7.7.2, where the glyphs are immediately addressed with "\musicglyph", the glyphs are ok. Hence, I suspect there must be something broken in the accidental->glyphname mapping. Greetings, Juergen My knowledge of ancient music is too limited to decide whether this is correct or not. In case it is correct, it would probably deserve a comment somewhere. Werner ___ 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: medieval font design
On Sat, 3 Feb 2007, Till Rettig wrote: Juergen Reuter wrote: 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). Do you mean by using xfig or inkscape or by defining the metafont source directly? Of course, you can use xfig to create some self-contained mf source code (though I never tried). However, note that lilypond glyphs typically refer to predefined values such as notespace or staff_space of stafflinethickness and should call lily-specific macros such as fet_begingroup or set_char_box rather than the corresponding native mf equivalents. That is, you would have to rewrite most parts of the xfig generated mf code anyway. You will get off probably better if you use some existing glyph as a template, duplicate and modify it. 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. Oh, this sounds logicalt, but I think for the ancient notation there is no need to have different lenghts -- well, lets put it that way: in petrucci prints there *is* no different length, and in manuscripts naturally there is one. True, but there is currently no infrastructure for typesetting stem glyphs. So either you would have to provide this infrastructure in lily/stem.cc (could turn out to be tedious). Or, probably much easier, you compute the polygon on the fly (provided that the calculation of the polygon's points is not too complex). But it doesn't seem to differ that much as in modern notation mainly due to the fact that there are no beams. Not only. Stems may also be shortened to avoid colissions; notes on ledger lines may have shorter stems for aesthetical reasons; and I think there are a couple of other reasons. Greetings, Juergen ___ 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 <> ___ 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 "&"). 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: 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: proposal: second style for quartertone accidentals
Hi, all!
Please note that we already have a style property for Accidental grobs.
For example, for yielding ancient notation accidentals, you may say:
\override Accidental #'style = #'vaticana
Hence, the natural way is to introduce another style for
different microtonal glyphs. They are not present in standard western
europe ancient notation and therefore do not collide with ancient
accidental styles. Hence, it is natural to introduce a new Accidental
style, say, for example:
\override Accidental #'style = #'arrowed
or maybe even better
\override Accidental #'style = #'default-arrowed
to indicate that the non-microtonal accidentals are still to be taken
from the default font, i.e. default and default-arrowed only differ in
microtonal glyphs.
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.
The input syntax ("aeh", "aesih", "gisih", etc.) should probably be
independent from the above selection of glyphs, as we usually try to
strictly separate musical content and engraving style. Considering this
principle, maybe the right thing is -- similarly to including proper
internationalized notenames -- the user to \include his/her favourite
naming scheme at the beginning of the user's .ly file.
Greetings,
Juergen
On Sat, 27 Jan 2007, Trevor Ba�~Ma wrote:
On 1/27/07, Orm Finnendahl <[EMAIL PROTECTED]> wrote:
Am 27. Januar 2007, 12:06 Uhr (-0600) schrieb Trevor Bača:
>
> Question: would it be possible to have access to *both* sets of
> glyphs? It seems to me that I've seen both types of glyphs mixed
> together in single scores; usually the existing quartertone glyphs
> show exact quartertone alterations while the arrowed glyphs show
> approximate alterations.
>
Well, my proposal meant to be completely backwards compatible. I
thought about something similar to the "notehead-style" property like
saying
\override #'accidental-style = "arrowed"
for getting the arrowed accidentals and
\revert #'accidental-style
for switching back.
Ah, OK. I very much vote yes. I've wanted the arrowed glyphs for quite
some time and would like to see them as part of the standard
distribution.
___
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=27&p_sidenr=8&p_illnr=0&p_frem=20&p_tilbage=9&p_navtype=rel&p_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 = '\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
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: 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: 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: link to Kievan Notes page
On Tue, 5 Dec 2006, Han-Wen Nienhuys wrote: - the length of 8th note stems varies between 2 and 2.5 staff space. What's the reasoning behind this? As far as I understand, it is the same idea behind it as for custodes and mensural flags: for notes that are on stafflines, you have a different stem/flare length than for notes between stafflines. See, e.g. in custos.cc: ... if (adjust) font_char += (((pos ^ sz) & 0x1) == 0) ? "1" : "0"; ... or in stem.cc: ... /* Mensural notation: For notes on staff lines, use different flags than for notes between staff lines. The idea is that flags are always vertically aligned with the staff lines, regardless if the note head is on a staff line or between two staff lines. In other words, the inner end of a flag always touches a staff line. */ ... I am only wondering why this adjustment for 8th note stems is applied for downward stems only, but not for upward stems. I guess, it should be applied to both. Greetings, Juergen ___ 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 th
Re: Kievan "hatchet" notes for lilypond?
Hello, Panteleimon! I fear the task of fully implementing kievan chant notation is more than just a question of adding thirteen glyphs. In your example, I believe to 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). To me, the notation looks structurally quite similar to gothic (also called "hufnagel") chant notation, though the glyphs are somewhat different. For a full implementation, beyond the glyphs, a proper ligature engraver would have to be implemented. I guess, it's implementation would look quite close to that of gothic notation, which is on my TODO list, but I probably will not be able to start working on it earlier than in late 2008. And the horizontal spacing problems, which vaticana ligatures currently have, will probably also apply to kievan ligatures (but I will definitely work on this problem). Still, adding those glyphs that are not part of ligatures (sole note heads, clefs, custos, accidentals, etc.) would be a good starting point (any volunteers?). Greetings, Juergen On Wed, 29 Nov 2006, Monk Panteleimon wrote: Hello, developers of Lilypond. I submitted to the lilypond-user list a queru regarding the possibilty of adding symbols for kievan chant notation to lilyponds "feta" font. I got no response, but thought I'd try the developers, specifically those involved with older notations. I have counted thirteen symbols that would need adding to lilypond's font (presumably as "noteheads," with their stems included, two "dots" and one "clef") in order to enable lilypond to imitate the Chant-books of the Russian Orthodox Church. I have no idea how to make such characters, or how to fit them into lilypond, so I'm asking this to be added as a sponsored feature. Being a monk I have no personal money, but if the lilypond-developers can give me an estimated cost of sponsorship for the addition of these symbols, then I believe that I may be able find several people interested enough to support the feature, even if they are not already lilypond-users. I am thinking of some Russian Chant enthusiasts and people already developing ways to digitally reproduce Russian Liturgical books. I have attached 2 images, one extracted from a pdf-scan of a Russian Chant book from 1909, another being someone's attempt to reproduce this using a ttf that is typed in to a word-processor. It should be obvious which is which. If you like I can point out the short-comings of the ttf version. I can also tell you what the symbols are and point you to some online explanations of this simple notation, although I would warn you that there are two practices of interpreting the durations of these notes, of which practices the less accurate is the more common. If for some reason you are adverse to adding these symbols to lilypond's vocabulary, please let me know. You can download complete books in kievan notation in .pdf from this page: http://www.seminaria.ru/raritet/quadsborn.htm Thank you for your time. Monk Panteleimon Hermitage of the Holy Cross Wayne, WV USA [EMAIL PROTECTED] http://www.holycross-hermitage.com/ http://www.holycrosskliros.org/ ___ 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: 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: 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: Juergen Reuter escreveu: 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. this is usually done by inspecting whether the 'interfaces property contains 'note-head-interface Ah, ok. This is valuable information to know! Thanks! 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: The formatting backend doesn't use subclassing at all, except for the spanner vs. item distinction. Therefore, subclassing by definition is the wrong approach. How to organize code should be decided by looking which code is shared. This is easiest to find out by first writing the code independently from the existing code, and then collapsing the common parts. 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. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. I don't think so. Most of the code is about matching grobs and moving them from different paper columns into a single one, determining the correct glyph for each notehead by evaluating local and neighbour heads' properties, adding new grobs (such as vertical lines) in the right place, collecting dots from different heads in different paper columns and moving them into a single dot column (I am already using DotColumn!), etc. Moving stuff around between paper columns should not be done in the typography backend. Sorry, I was imprecise. Moving stuff around between paper columns is done in the engravers, of course. 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: Juergen Reuter escreveu: 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 This might have been true when you added this stuff (~ 4 years ago, I think), but nowadays, note-head.cc has 7 routines, of which 3 aren't used anywhere else. For good measure, I just removed Note_head::get_balltype() as well. The other routines have to do with stem attachments, which aren't applicable to ligatures anyway. Ok, I will eventually check. (BTW, I suspect there are a bunches of unused #include's that could be removed...) 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... I think that this is going about the problem in the wrong way. Given how much lily has changed over the years, the proper solution IMO is to redo the ligature stuff completely. Mmmh, but how? Given, that things have changed, as you state, do you think there should be a completely new "ligatureheads.cc"? If so, should I clone the print and internal_print methods or rather try to create a subclass? I think a ligature primitive _is_ a special note head, so modeling it as a subclass does not sound bad, even if stems are not used. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. I don't think so. Most of the code is about matching grobs and moving them from different paper columns into a single one, determining the correct glyph for each notehead by evaluating local and neighbour heads' properties, adding new grobs (such as vertical lines) in the right place, collecting dots from different heads in different paper columns and moving them into a single dot column (I am already using DotColumn!), etc. I do not see any similar code elsewhere, so I am confident that the code would not remarkably collapse. 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 "&" 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 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=lilypond&r1=1.498&r2=1.499 http://cvs.savannah.gnu.org/viewcvs/newweb/site/news.ihtml?cvsroot=lilypond&r1=1.158&r2=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 @@
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
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
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) (... ...))), 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
[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) (... ...))), 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
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
[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: 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
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
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* [# # #]
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 # # ...]
In unknown file:
?: 17* [ly:spacing-spanner::set-springs #]
?: 18* [ly:axis-group-interface::width #]
?: 19* [ly:self-alignment-interface::aligned-on-x-parent #LyricText >]
?: 20* [ly:grob::stencil-width #]
?: 21* [lyric-text::print #]
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" --formats=eps --verbose
-dread-file-list -dpad-eps-boxes -
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
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: [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) (... ...))),
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
[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: 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-&
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: 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:
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
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 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.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 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, 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
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, 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
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
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: 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: 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.
*
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
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: 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: 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: handwritten music font
Hi, how many glyphs are you planning to add? If your project is going to become a font with many dozens of glyphs over time, you could add new .mf files, just as the parmesan font does for ancient notation. If you grep for the string "parmesan" on all files in the mf directory, you will see which files you have to add/modify in order to add a completely new font. For note head selection from evaluating the style property, you have to extend function note-head::calc-glyph-name in file scm/output-lib.scm properly. Similarly, for clefs, you have to extend scm/parser-clef.scm. Selection of glyphs of other grob types (e.g. accidentals) is currently still done directly in the c++ code (e.g. lily/accidental.cc); though, on the long term, this code should probably also be replaced by scheme code. Greetings, Juergen On Fri, 9 Jun 2006, "Johannes Sch�pfer" wrote: hi all, please excuse my lousy english. i would like to design a handwritten music font for lilypond based on "the art of music copying" by clinton roemer. would a modyfied feta-bolletjes.mf make sense to you to have a look at it? regards, johnny ___ 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
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?] 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
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
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
