Re: mensural notation improvements (issue3797046)
hi Carl, thanks for reviewing!
Let me start by saying I know *nothing* about mensural notation.
The code looks good to me.
I found only one real issue:
LilyPond coding standards for C++ say that if there is only one
statement in an if clause, we omit {} around that clause.
that's a pity - I hate adding/removing braces when the number of
statement changes. nevertheless I'll change these instances.
I also had a question (and it probably doesn't matter much). When I've
written font glyphs that are sometimes solid and sometimes hollow, I
always calculate both the inner and outer paths. And then when I create
the glyph I only use the paths that are actually needed. In your code,
you didn't create the path unless it was needed. It probably makes no
difference at all, but I'd like to hear from the font gurus if there is
a preference.
My take was we only make the fonts at install, so the code doesn't need
to be optimized for speed, so I optimized for readability, which in my
mind, meant not putting the inner path inside a conditional.
in this case the shape of the inner path is conditional as well
(and it's truly nasty, I admit).
I'll upload a modified patchset tonight.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
now I see I forgot to answer a question:
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
lily/mensural-ligature-engraver.cc:380: {
Why put the {} in this case?
because variables defined there should not be seen in the default case.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
new patchset up. please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? Ancient music has been abandoned by developers for a number of years. IMO, you may do whatever you think makes the most sense as you try to bring ancient music back into the mainstream of LilyPond development. I thought there might be a general policy about editing files in the regression suite. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On 2011/01/24 21:27:35, benko.pal wrote: new patchset up. please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? Ancient music has been abandoned by developers for a number of years. IMO, you may do whatever you think makes the most sense as you try to bring ancient music back into the mainstream of LilyPond development. Thanks, Carl http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On 1/24/11 3:31 PM, Benkő Pál benko@gmail.com wrote: please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? Ancient music has been abandoned by developers for a number of years. IMO, you may do whatever you think makes the most sense as you try to bring ancient music back into the mainstream of LilyPond development. I thought there might be a general policy about editing files in the regression suite. As far as I know, the only policies we have about writing regression tests are in the Contributors' Guide, section 10.8.2 Writing regression tests. Regression tests should be as brief as possible to demonstrate the functionality of the code. Regression tests should generally cover one issue per test. Several short, single-issue regression tests are preferred to a single, long, multiple-issue regression test. Use existing regression tests as templates to demonstrate the type of header information that should be included in a regression test. Sometimes a regression test is intended to show all possible functionality. In such a case, an existing test should be extended to show the added functionality. But where possible, we try to keep tests to a single issue. Personally, I will trust your judgment in this case. Do what seems best. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
Let me start by saying I know *nothing* about mensural notation.
The code looks good to me.
I found only one real issue:
LilyPond coding standards for C++ say that if there is only one
statement in an if clause, we omit {} around that clause.
I also had a question (and it probably doesn't matter much). When I've
written font glyphs that are sometimes solid and sometimes hollow, I
always calculate both the inner and outer paths. And then when I create
the glyph I only use the paths that are actually needed. In your code,
you didn't create the path unless it was needed. It probably makes no
difference at all, but I'd like to hear from the font gurus if there is
a preference.
My take was we only make the fonts at install, so the code doesn't need
to be optimized for speed, so I optimized for readability, which in my
mind, meant not putting the inner path inside a conditional.
Great work!
Thanks,
Carl
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc
File lily/mensural-ligature-engraver.cc (right):
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode277
lily/mensural-ligature-engraver.cc:277: {
Remove unneeded {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode315
lily/mensural-ligature-engraver.cc:315: prev_primitive-set_property
(add-join, ly_bool2scm (true));
Remove unneeded {} from previous line and next line
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
lily/mensural-ligature-engraver.cc:380: {
Why put the {} in this case?
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode448
lily/mensural-ligature-engraver.cc:448: {
Remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode453
lily/mensural-ligature-engraver.cc:453: {
Remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode455
lily/mensural-ligature-engraver.cc:455: {
Remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode460
lily/mensural-ligature-engraver.cc:460: {
Remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc
File lily/mensural-ligature.cc (right):
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode101
lily/mensural-ligature.cc:101: {
remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode144
lily/mensural-ligature.cc:144: flexa_width = robust_scm2double
(me-get_property (flexa-width), 2.0)
Remove {}
http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature.cc#newcode221
lily/mensural-ligature.cc:221: {
Remove {}
http://codereview.appspot.com/3797046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
if it helps to confirm that you are right, I might add my own experience with mensural sources. Composers/writers seem to literally avoid dotted notes in ligatures except (a) at the end of the ligature, or (b) on top of the first note of an obliqua, or (c) both. (a) and (b) are frequent, and there are numerous examples. There are some for (c), e.g. the Eton Choirbook that Pál quoted, or Apel, page 471. yes; generally there's seldom need to dot a long note, regardless of being in or outside a ligature. Sometimes, (d) a dotted first note of a non-obliqua ligature can be found with the dot on the right of the note. This is usually an ascending ligatura cum opposita proprietate (as in Pál's examples, or Apel, p. 181, or p. 138 for a semi-coloured one). (btw in the Chigi example there's a dotted first breve in the penultimate staff of the right side.) I have never seen this with a descending ligature, and I would be interested if you found an example. seems to be a busy weekend, but I hope I can get to it. I don't know any sources that comply with Apel's dot-above rule, but then again, Apel probably saw more sources than I ever will... or me, too. and I learnt mensural notation solely from Apel. Sometimes I have been confused by a punctus divisionis placed in the middle above a ligature, but of course that's something different. wow, I have never seen such a thing! could you give an example? p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
Am 07.01.2011 10:17, schrieb Benkő Pál: Sometimes I have been confused by a punctus divisionis placed in the middle above a ligature, but of course that's something different. wow, I have never seen such a thing! could you give an example? The only one I could find quickly is from Apel's facsimiles again: p. 192, 5th staff, quaternaria. (And, similarly, the binaria LB at the end of the line) Best regards, Robert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
One thing I forgot to mention: I've also rewritten dot handling within ligatures. The old code - didn't avoid staff lines - didn't conform actual usage: dotting notes above is not a practice, only if they are first within a flexa, see examples in http://anaigeon.free.fr/mes_facs/fsbarb.jpg http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg (actually I know one example when the second flexa note is dotted above, but general usage is like the two above, when such notes are dotted behind.) http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On Thu, 2011-01-06 at 08:44 +, benko@gmail.com wrote: One thing I forgot to mention: I've also rewritten dot handling within ligatures. The old code - didn't avoid staff lines - didn't conform actual usage: dotting notes above is not a practice, only if they are first within a flexa, see examples in http://anaigeon.free.fr/mes_facs/fsbarb.jpg http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg (actually I know one example when the second flexa note is dotted above, but general usage is like the two above, when such notes are dotted behind.) http://codereview.appspot.com/3797046/ According to Apel (1962: 99), the general rule would seem to be that the dot should be on the right if it applies to the final note of the whole ligature, but on top if it is anywhere else (flexa or no flexa). He has one example of a flexa followed by several square notes, with a dot above the following square note (i.e. in a position that happens to be also just to the right of the flexa), but the dot is meant to apply to the square note over which it stands, not the flexa. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
One thing I forgot to mention: I've also rewritten dot handling within ligatures. The old code - didn't avoid staff lines - didn't conform actual usage: dotting notes above is not a practice, only if they are first within a flexa, see examples in http://anaigeon.free.fr/mes_facs/fsbarb.jpg http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg (actually I know one example when the second flexa note is dotted above, but general usage is like the two above, when such notes are dotted behind.) http://codereview.appspot.com/3797046/ According to Apel (1962: 99), the general rule would seem to be that the dot should be on the right if it applies to the final note of the whole ligature, but on top if it is anywhere else (flexa or no flexa). He has one example of a flexa followed by several square notes, with a dot above the following square note (i.e. in a position that happens to be also just to the right of the flexa), but the dot is meant to apply to the square note over which it stands, not the flexa. When I have time to go to the library, I'll look up Apel again, which codex it is, but if you have a handy scan available (even better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. But let me reiterate: I've seen several codices, and only one diverges from the usage I implemented, and even that diverges only in dotting not only the first but the last note of a flexa above as well. I know that ligatures are not too frequent, dotted notes within ligatures are extremely rare, but even the two examples I linked clearly dot notes contrary to the Apel way. I'll try to find an example where a non-final square note is dotted and the following note is below it (in the linked examples the next notes are above, so the dot of the first note appears _below_ the next note). p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On Thu, 2011-01-06 at 10:49 +0100, Benkő Pál wrote: According to Apel (1962: 99), the general rule would seem to be that the dot should be on the right if it applies to the final note of the whole ligature, but on top if it is anywhere else (flexa or no flexa). He has one example of a flexa followed by several square notes, with a dot above the following square note (i.e. in a position that happens to be also just to the right of the flexa), but the dot is meant to apply to the square note over which it stands, not the flexa. When I have time to go to the library, I'll look up Apel again, which codex it is, but if you have a handy scan available (even better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. But let me reiterate: I've seen several codices, and only one diverges from the usage I implemented, and even that diverges only in dotting not only the first but the last note of a flexa above as well. I know that ligatures are not too frequent, dotted notes within ligatures are extremely rare, but even the two examples I linked clearly dot notes contrary to the Apel way. I'll try to find an example where a non-final square note is dotted and the following note is below it (in the linked examples the next notes are above, so the dot of the first note appears _below_ the next note). p Yep, I can see the examples you describe, you are right about them contradicting Apel's rule. Unfortunately, the examples Apel gives are schematic self-drawn ones in the text, thus possibly constructed. I could not quickly find a relevant example in any of the actual facsimiles in the book. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
Am 06.01.2011 10:56, schrieb Lukas Pietsch: On Thu, 2011-01-06 at 10:49 +0100, Benkő Pál wrote: According to Apel (1962: 99), the general rule would seem to be that the dot should be on the right if it applies to the final note of the whole ligature, but on top if it is anywhere else (flexa or no flexa). He has one example of a flexa followed by several square notes, with a dot above the following square note (i.e. in a position that happens to be also just to the right of the flexa), but the dot is meant to apply to the square note over which it stands, not the flexa. When I have time to go to the library, I'll look up Apel again, which codex it is, but if you have a handy scan available (even better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. But let me reiterate: I've seen several codices, and only one diverges from the usage I implemented, and even that diverges only in dotting not only the first but the last note of a flexa above as well. I know that ligatures are not too frequent, dotted notes within ligatures are extremely rare, but even the two examples I linked clearly dot notes contrary to the Apel way. I'll try to find an example where a non-final square note is dotted and the following note is below it (in the linked examples the next notes are above, so the dot of the first note appears _below_ the next note). p Yep, I can see the examples you describe, you are right about them contradicting Apel's rule. Unfortunately, the examples Apel gives are schematic self-drawn ones in the text, thus possibly constructed. I could not quickly find a relevant example in any of the actual facsimiles in the book. Lukas Lukas, Pál, if it helps to confirm that you are right, I might add my own experience with mensural sources. Composers/writers seem to literally avoid dotted notes in ligatures except (a) at the end of the ligature, or (b) on top of the first note of an obliqua, or (c) both. (a) and (b) are frequent, and there are numerous examples. There are some for (c), e.g. the Eton Choirbook that Pál quoted, or Apel, page 471. Sometimes, (d) a dotted first note of a non-obliqua ligature can be found with the dot on the right of the note. This is usually an ascending ligatura cum opposita proprietate (as in Pál's examples, or Apel, p. 181, or p. 138 for a semi-coloured one). I have never seen this with a descending ligature, and I would be interested if you found an example. I don't know any sources that comply with Apel's dot-above rule, but then again, Apel probably saw more sources than I ever will... Sometimes I have been confused by a punctus divisionis placed in the middle above a ligature, but of course that's something different. Best regards, Robert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
On Wed, 4 May 2005, Pal Benko wrote: Hi Jrgen, What I do not understand, if you want neo-mensural noteheads, why not just doing \override Voice.NoteHead #'style = #'neomensural? As far as I can see, the main difference between neomensural and mensural notehead are (besides the different parameters) that mensural noteheads have diamond shape at their centerline, while neomensural heads have it at the outer boundary, and I just need this. Note that with my patch the mensural and neomensural noteheads still look different. My main point is to have bigger noteheads, almost two linespaces high; but it should not be so big that a notehead between two stafflines have those lines visible in the interior hole. p Ah, ok. But I would not like to completely drop the current mensural shapes, since I have seen quite some printed ancient examples (mostly in [1]) with noteheads very similar to the current mensural shapes. But maybe you can convince me that your shapes are the more authentic or the more beautiful ones... So, maybe for the time being, we should just add a new notehead style? Do you have any idea for a naming convention (for the clefs, we e.g. have mensural and petrucci style)? Greetings, Juergen [1] F. Blume (Ed.): Die Musik in Geschichte und Gegenwart (MGG). Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ 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 notation
Ok, then I will apply your noteheads as petrucci style (hopefully, I will be able to spend some time this evening). What about the remaining durations (maxima, ...) for petrucci style? I guess, they should be the same as for mensural style? Anyway, this can easily be changed in the find-notehead-symbol function in scm/output-lib.scm. Greetings, Juergen On Mon, 9 May 2005, Pal Benko wrote: Hi Jrgen, What I do not understand, if you want neo-mensural noteheads, why not just doing \override Voice.NoteHead #'style = #'neomensural? As far as I can see, the main difference between neomensural and mensural notehead are (besides the different parameters) that mensural noteheads have diamond shape at their centerline, while neomensural heads have it at the outer boundary, and I just need this. Note that with my patch the mensural and neomensural noteheads still look different. My main point is to have bigger noteheads, almost two linespaces high; but it should not be so big that a notehead between two stafflines have those lines visible in the interior hole. p Ah, ok. But I would not like to completely drop the current mensural shapes, since I have seen quite some printed ancient examples (mostly in [1]) with noteheads very similar to the current mensural shapes. Let me clarify me a bit: my core problem with the current official ancient noteheads is that they are way smaller than those I've seen in manuscipts and Petrucci prints. First I wanted to have larger mensural noteheads, and then I saw the problem written above, i.e. for a note on a staff-line the line did not cross the left and right corners of the notehead (and if I interpreted the comments correctly, that is a problem for you as well). I've tried to modify the description, but didn't succeed; and then I found out that neomensural heads can be parametrised so that I get what I want. I have seen such tiny noteheads in modern print (Wolf, Crevel's edition of Obrecht's Missa Maria zart), but these are not facsimiles. I'll check MGG. But maybe you can convince me that your shapes are the more authentic or the more beautiful ones... I can make scans of the facsimiles I have. Perhaps it would be good anyway (e.g. Lilypond doesn't have Gamma clef). So, maybe for the time being, we should just add a new notehead style? Do you have any idea for a naming convention (for the clefs, we e.g. have mensural and petrucci style)? My style is quite close (a little bit bigger) to that of Petrucci; if you think it's worth the trouble, I'll scan some Petrucci, magnify it, take exact measurements and then we can call the style in the patch Petrucci-style. Cheers, p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
Hi Jrgen, What I do not understand, if you want neo-mensural noteheads, why not just doing \override Voice.NoteHead #'style = #'neomensural? As far as I can see, the main difference between neomensural and mensural notehead are (besides the different parameters) that mensural noteheads have diamond shape at their centerline, while neomensural heads have it at the outer boundary, and I just need this. Note that with my patch the mensural and neomensural noteheads still look different. My main point is to have bigger noteheads, almost two linespaces high; but it should not be so big that a notehead between two stafflines have those lines visible in the interior hole. p Ah, ok. But I would not like to completely drop the current mensural shapes, since I have seen quite some printed ancient examples (mostly in [1]) with noteheads very similar to the current mensural shapes. Let me clarify me a bit: my core problem with the current official ancient noteheads is that they are way smaller than those I've seen in manuscipts and Petrucci prints. First I wanted to have larger mensural noteheads, and then I saw the problem written above, i.e. for a note on a staff-line the line did not cross the left and right corners of the notehead (and if I interpreted the comments correctly, that is a problem for you as well). I've tried to modify the description, but didn't succeed; and then I found out that neomensural heads can be parametrised so that I get what I want. I have seen such tiny noteheads in modern print (Wolf, Crevel's edition of Obrecht's Missa Maria zart), but these are not facsimiles. I'll check MGG. But maybe you can convince me that your shapes are the more authentic or the more beautiful ones... I can make scans of the facsimiles I have. Perhaps it would be good anyway (e.g. Lilypond doesn't have Gamma clef). So, maybe for the time being, we should just add a new notehead style? Do you have any idea for a naming convention (for the clefs, we e.g. have mensural and petrucci style)? My style is quite close (a little bit bigger) to that of Petrucci; if you think it's worth the trouble, I'll scan some Petrucci, magnify it, take exact measurements and then we can call the style in the patch Petrucci-style. Cheers, p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
What about the remaining durations (maxima, ...) for petrucci style? I guess, they should be the same as for mensural style? Yes. These as well are quite close but not identical to those found in Petrucci prints; they will do. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
Hi Jrgen, What I do not understand, if you want neo-mensural noteheads, why not just doing \override Voice.NoteHead #'style = #'neomensural? As far as I can see, the main difference between neomensural and mensural notehead are (besides the different parameters) that mensural noteheads have diamond shape at their centerline, while neomensural heads have it at the outer boundary, and I just need this. Note that with my patch the mensural and neomensural noteheads still look different. My main point is to have bigger noteheads, almost two linespaces high; but it should not be so big that a notehead between two stafflines have those lines visible in the interior hole. p Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation: patch, question, plan
Hi, Benko! I have finally (sorry for the extremely long delay!) applied your patch, slightly modified, for using a constant thickness of horizontal lines in flexa shapes (rather than using the thickness property). I still feel somewhat uncomfortable with this solution, as the property thickness now applies to the vertical lines only, while the horizontal lines are of hard-wired constant thickness. Though, I realize that there are notational examples where you want to have different thicknesses. Greetings, Juergen On Sun, 27 Feb 2005, Pal Benko wrote: 2005-02-27 Pal Benko [EMAIL PROTECTED] * lily/mensural-ligature.cc (brew_flexa): make flexa parts of ligatures look more similar to square parts * lily/include/mensural-ligature.hh: explanatory comments Hi Jrgen (and all), I've played a bit with flexa shape within a ligature; this is in the attached patch. I began experimenting with punctus divisionis as a new type of barline. My first try was introducing one new type (.), but then I couldn't position it. Is there a way of accessing the previous note in the barline code? Then I'd know where to move the dot. The second try was introducing a default case: the glyph string is interpreted as a number, and the dot is moved accordingly. I have two problems with this: I couldn't hack default-break-barline in output-lib.scm (I know almost nothing of Lisp and nothing else about scheme), so I get a warning for all puncti divisionis, and I have a big space between the previous note and the dot. Can I control that space somehow? I reviewed the facsimiles I have, and found that - a punctus divisionis can be at the end of a line (and then the next line begins as if nothing happened), so it can really be implemented as a new type of barline; - augmenting dots within ligatures are generally placed after the note, except first notes of flexae, which have it above. I'll try to sort out this issue next. Thanks, Pl Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
Hi, Pal!
On Wed, 20 Apr 2005, Pal Benko wrote:
Hi all,
attached is a patch with changed mensural noteheads.
...
fet_beginchar(Mensural open head,s0mensural)
- draw_diamond_head (staff_space#, 0.15, 0.30, 30, true);
+% draw_diamond_head (1.8 staff_space#, 0.15, 0.40, 30, true);
+ draw_neomensural_open_head (staff_space#, 1.8 staff_space#);
fet_endchar;
fet_beginchar(Mensural open head,s1mensural)
- draw_diamond_head (staff_space#, 0.15, 0.30, 30, true);
+% draw_diamond_head (1.8 staff_space#, 0.15, 0.40, 30, true);
+ draw_neomensural_open_head (staff_space#, 1.8 staff_space#);
fet_endchar;
fet_beginchar(Mensural black head,s2mensural)
- draw_diamond_head (staff_space#, 0.15, 0.30, 30, false);
+% draw_diamond_head (1.8 staff_space#, 0.15, 0.40, 30, false);
+ draw_neomensural_black_head (staff_space#, 1.8 staff_space#);
fet_endchar;
What I do not understand, if you want neo-mensural noteheads, why not just
doing \override Voice.NoteHead #'style = #'neomensural?
Some problems:
1. MensuralStaff sort of ceased to work for me - or, rather,
I was using it inaccurately. Roughly I wrote
\score {
\context MensuralStaff {
% notes here
}
}
But since last week this doesn't work.
Ok, I will look into this.
2. I'd like to make punctus divisionis work as a new bar symbol,
\bar .. But for correct positioning I need in
Bar_line::compound_barline the previous and the next note - how
can I get them (if I can at all)?
Maybe in the bar engraver, you can do something similar to what the
ligature engraver does: listening for note heads (but not eating it up
as the ligature engraver does), remembering the pitch of the last seen
one, and when a bar is created, putting the pitch as a grob value into the
bar grob, and doing similar for the pending next note's pitch. You
probably should discuss this with Han-Wen or Jan.
3. I hacked Mensural_ligature a bit so that now I don't have
those spurious warnings for flexa shapes and I have horizontal
positioning of dots all right.
Great to hear!
I want to have correct vertical
positions; in Mensural_ligature I can calculate the correct
position, but I don't know how to propagate this information
(and in fact I don't really know where to propagate it, but I
guess it's Dot_column or Dot_column_engraver).
See Han-Wen's reply.
Greetings,
Jrgen
thanks,
Pal
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a
FreeStarttol.
Probald ki most! http://www.freestart.hu
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation
Op wo, 20-04-2005 te 22:02 +0200, schreef Pal Benko: 2. I'd like to make punctus divisionis work as a new bar symbol, \bar .. But for correct positioning I need in Bar_line::compound_barline the previous and the next note - how can I get them (if I can at all)? Unfortunately, this information is not stored at the moment. 3. I hacked Mensural_ligature a bit so that now I don't have those spurious warnings for flexa shapes and I have horizontal positioning of dots all right. I want to have correct vertical positions; in Mensural_ligature I can calculate the correct position, but I don't know how to propagate this information (and in fact I don't really know where to propagate it, but I guess it's Dot_column or Dot_column_engraver). Normally, Dot_column::add_head() sets a callback function (Dot_column::force_shift_callback()), which does the positioning. I guess you want to write a substitute for that, and have add_head() set that in some way or another. -- Han-Wen Nienhuys - [EMAIL PROTECTED] LilyPond Software Design - http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation: patch, question, plan
Hi Jürgen, Currently, the thickness property of the flexa shape aplies to all segments of the outline. IIUC, you are suggesting to apply the thickness property only to the left and right outline segment of the flexa shape, while hard-wiring the upper and lower segment wrt to the proportions in the .mf code for the brevis note head. I think this is somewhat inconsistent. If we really need different thicknesses for the vertical and horizontal segments, we may want to control this behavior with a separate property. That's fine with me. However, I just looked at a few facsimiles as well as contemporary educational works on mensural ligatures, and my impression is that all line segments roughly have the same thickness (unless the steepness is extremely high, in which case we may want to apply some thickness correction factor to the horizontal segments in order to compensate for optical illusion effects). Do you really think that the horizontal and vertical segments need to be controlled separately? Yes! Do you have facsimiles or contemporary works with noticeable difference between the thickness of the horizontal and vertical outline segments? Yes: I have facsimiles of about twenty masses from Petrucci prints and different codices (e.g. the Chigi codex; I don't know where the other facsimiles come from). There are at least three different scribes (i.e. script styles) I can distinguish. The horizontal lines of flexae are always like that of breves and not like the vertical ones (i.e. distinctly heavier). If you are interested, I'll try to make some scans. Pal Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation: patch, question, plan
On Sun, 27 Feb 2005, Benk Pl wrote: 2005-02-27 Pal Benko [EMAIL PROTECTED] * lily/mensural-ligature.cc (brew_flexa): make flexa parts of ligatures look more similar to square parts Hi, Pl! Currently, the thickness property of the flexa shape aplies to all segments of the outline. IIUC, you are suggesting to apply the thickness property only to the left and right outline segment of the flexa shape, while hard-wiring the upper and lower segment wrt to the proportions in the .mf code for the brevis note head. I think this is somewhat inconsistent. If we really need different thicknesses for the vertical and horizontal segments, we may want to control this behavior with a separate property. However, I just looked at a few facsimiles as well as contemporary educational works on mensural ligatures, and my impression is that all line segments roughly have the same thickness (unless the steepness is extremely high, in which case we may want to apply some thickness correction factor to the horizontal segments in order to compensate for optical illusion effects). Do you really think that the horizontal and vertical segments need to be controlled separately? Do you have facsimiles or contemporary works with noticeable difference between the thickness of the horizontal and vertical outline segments? Greetings, Jrgen___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation: patch, question, plan
Hi, Pl! I am sorry for responding so late: last week not only I was in bad health, but also my (quite old) linux installation, which finally broke down, such that I had to install a new distribution. I am still working on getting things running again, but I am quite confident that I will be able to have a look at your patch within the next few days. Greetings, Jrgen On Sun, 27 Feb 2005, Benk Pl wrote: 2005-02-27 Pal Benko [EMAIL PROTECTED] * lily/mensural-ligature.cc (brew_flexa): make flexa parts of ligatures look more similar to square parts * lily/include/mensural-ligature.hh: explanatory comments Hi Jrgen (and all), I've played a bit with flexa shape within a ligature; this is in the attached patch. I began experimenting with punctus divisionis as a new type of barline. My first try was introducing one new type (.), but then I couldn't position it. Is there a way of accessing the previous note in the barline code? Then I'd know where to move the dot. The second try was introducing a default case: the glyph string is interpreted as a number, and the dot is moved accordingly. I have two problems with this: I couldn't hack default-break-barline in output-lib.scm (I know almost nothing of Lisp and nothing else about scheme), so I get a warning for all puncti divisionis, and I have a big space between the previous note and the dot. Can I control that space somehow? I reviewed the facsimiles I have, and found that - a punctus divisionis can be at the end of a line (and then the next line begins as if nothing happened), so it can really be implemented as a new type of barline; - augmenting dots within ligatures are generally placed after the note, except first notes of flexae, which have it above. I'll try to sort out this issue next. Thanks, Pl Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mensural notation - some questions and a patch
On Tue, 15 Feb 2005, Benkõ Pál wrote:
ChangeLog:
2005-02-15 Pal Benko [EMAIL PROTECTED]
* lily/mensural-ligature-engraver.cc:
* lily/mensural-ligature.cc:
* lily/include/mensural-ligature.hh: new algorithm implemented
* scm/define-grob-properties.scm: join-left killed
(add-join may be used); join-left-amount changed to join-right-amount
--
Hello,
I'm singing renaissance music from mensural notation;
if I can't have a facsimile of an old print/manuscript,
I make the notes for myself.
So long I used pen and paper, but now I thought using lilypond.
Hi Pál,
nice to hear that someone else is interested in pushing lily's mensural
notation implementation!
I have some problems, some of them critical,
but perhaps thay can be overcome easily (the patch is for pr 3)
Critical (I can't choose an alternative notation):
1. punctus divisionis
I need a dot (just like an augmentation dot)
without a notehead or rest, which I can place at any pitch I want.
Is there something like an invisible (zero-duration) notehead with visible
dot?
Hmmh, I haven't thought about this much by now. Maybe, we want to
introduce a new type of breath mark; my main source[1] says, that punctus
divisionis can be thought of something similar like a bar glyph. Of
course, we have to think about the vertical aligning of this glyph (is it
always aligned with the previous pitch or centered between the enclosing
pitches or ...?).
2. coloratio
filled noteheads are needed (longae, breves, semibreves also).
Can I request somehow either fill the head of this note
or from now on fill each notehead and from now on don't fill noteheads?
Currently, the Metafont code is being restructured (due to the new
TeX-less backend, pango, fontforge, ...). We probably should finish the
conversion of the parmesan font before adding new glyphs. After that, it
should be trivial to add black mensural note heads.
Once the note heads would have been added, it would be possible to switch
between filled and unfilled heads by tweaking the style property of the
NoteHead grob. I think that is what you are asking for.
The style property tweaking approach may be acceptable as a temporary
workaround. However, for the long term, I would prefer a solution that
respects the musical meaning of colored notes. Ideally, I would not have
at all to touch the style property, but just say something like \times
2/3 { ... } within a specially prepared \context MensuralVoiceContext to
mark colored sections, and let lily do the rest. Then you would get a
transcription into contemporary notation for free, and MIDI output still
would be ok (with pure style tweaking, MIDI output would be wrong).
Noncritical problems:
2a. a half-note in a coloratio section looks like a quarter-note.
To avoid this, sometimes quarter-notes are written as half-notes with a flag.
Is there a command (bunch of commands)
so that such quarter-notes are used throughout?
Not yet, but given that we can find a reliable way to detect this case, it
should not be too hard to implement.
3. Current ligature handling doesn't conform to medieval-renaissance usage;
I implemented a new algorithm within the old framework.
This is in the attached patch (some comments later).
Yes, I know: the current implementation is quite buggy. I implemented
ligature handling based on a finite state automata maybe two or three
years ago. The crucial thing is that it is rather simple to handle the
ordinary cases, but hard to catch the unordinary cases of more
complicated rythmical patterns. The idea of the automata was to catch
unordinary cases in a table-like approach, thus making it easier to add
new exceptions by just altering some entries in the tables (i.e.
minimizing side effects when fixing an uncaught case).
If your appraoch fixes the problems of my implementation, I will be glad
to throw away my buggy implementation. I will have a look at your
implementation on the weekend (I am still busy co-directing a stage play
until this saturday morning).
4. How can I achieve a text-like output, i.e.
- smallest possible spacing (as between letters)
That's on the TODO list. In the past I had various discussions about this
item with Han-Wen and Jan. Probably, a completely new spacing engine has
to be written to fix this. The current approach of sticking ligature
primitives together already overstresses the capabilities of the current
spacing engine, resulting in various programming error messages about
number infinity problems (which, however, usually can be ignored).
- last line (before a \break) not streching the whole page-width?
Try raggedright = ##t.
Unimportant, but would be pleasant:
5. Can I request all custodes facing up?
Try setting the grob property neutral-position on the custos grob to a
higher
Re: Mensural notation - some questions and a patch
Hi Jürgen,
1. punctus divisionis
Hmmh, I haven't thought about this much by now. Maybe, we want to
introduce a new type of breath mark; my main source[1] says, that punctus
divisionis can be thought of something similar like a bar glyph.
([1] is my main source as well.) The main difference is that there is
never a line break at a punctus divisionis.
Of course, we have to think about the vertical aligning of this
glyph (is it always aligned with the previous pitch or centered
between the enclosing pitches or ...?).
It must be obvious that it is not a punctus additionis. It is
generally a stave further from the note than an augmenting dot. If it
is between minimae, than it's generally halfway between the stems.
2. coloratio
The style property tweaking approach may be acceptable as a temporary
workaround. However, for the long term, I would prefer a solution that
respects the musical meaning of colored notes. Ideally, I would not have
at all to touch the style property, but just say something like \times
2/3 { ... } within a specially prepared \context MensuralVoiceContext to
mark colored sections, and let lily do the rest. Then you would get a
transcription into contemporary notation for free, and MIDI output still
would be ok (with pure style tweaking, MIDI output would be wrong).
This is far more difficult. The length of a notehead depends on
context. A colored note may be of the same lengh as its uncolored
counterpart. (This is true for uncolored notes as well - a brevis may
be shorter than a semibrevis (e.g.
\time 9/2 r\breve c1 d1 r\breve e2 f\breve g2 a1 h2 r\breve
a is 2 minima long,
c is 3,
f is 4,
d is 6;
the keywords are imperfectio a parte post/ante and alteratio).)
2a. a half-note in a coloratio section looks like a quarter-note.
To avoid this, sometimes quarter-notes are written as half-notes
with a flag. Is there a command (bunch of commands) so that such
quarter-notes are used throughout?
Not yet, but given that we can find a reliable way to detect this case, it
should not be too hard to implement.
If such note-glyphs are used, then they are used exclusively during
the whole movement, so I think there is not too much to detect, let
the user ask for it, just like asking mensural or neomensural
note-head style.
3. Current ligature handling doesn't conform to medieval-renaissance usage;
I implemented a new algorithm within the old framework.
This is in the attached patch (some comments later).
Yes, I know: the current implementation is quite buggy. I implemented
ligature handling based on a finite state automata maybe two or three
years ago. The crucial thing is that it is rather simple to handle the
ordinary cases, but hard to catch the unordinary cases of more
complicated rythmical patterns. The idea of the automata was to catch
unordinary cases in a table-like approach, thus making it easier to add
new exceptions by just altering some entries in the tables (i.e.
minimizing side effects when fixing an uncaught case).
If your appraoch fixes the problems of my implementation, I will be glad
to throw away my buggy implementation. I will have a look at your
implementation on the weekend (I am still busy co-directing a stage play
until this saturday morning).
Oh, that sounds interesting!
- last line (before a \break) not streching the whole page-width?
Try raggedright = ##t.
However I want the full lines aligned. And incomplete lines can
appear anywhere, not just at the end of page or end of file, so
raggedlast is not an option.
7. Bigger note heads (in 15th century manuscripts a semibrevis head
is almost two staff-space wide)
We could introduce yet another set (i.e. style) of note head glyphs, but
before doing so, I would like to see some kind of standard or reference
(such as Petrucci's Odhecaton can be considered as a notational standard).
Otherwise, there is the danger of producing inflationary and maybe
incomplete sets of unrelated glyphs.
I've just seen \set fontSize, and will try.
Some notes about the patch:
this is my first submission to free software,
there must be a lot of issues with it.
E.g. I've written a description of the algorithm and a test file
(also attached), but don't know where to place them and how;
That's perfectly fine. What has been really missing since my first
ligature implementation, is a comprehensive test file with many ligatures
for regression purposes. Your test file looks like a good starting point
for such a regression test. Thanks!
If you send me your concerns, I can look up other examples.
Thanks,
Pal
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
