lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: There no ligatures in Kievan notation (was Re: Kievan "hatchet" note


From: Juergen Reuter
Subject: Re: There no ligatures in Kievan notation (was Re: Kievan "hatchet" notes for lilypond?)
Date: Fri, 1 Dec 2006 12:05:20 +0100 (CET)

On Thu, 30 Nov 2006, Monk Panteleimon wrote:

On Thursday 30 November 2006 06:01, you wrote:
Hello, Panteleimon!

Hello, thank you for your response

I fear the task of fully implementing kievan chant notation is more than
just a question of adding thirteen glyphs.
recognize at least pes ligatures (those pairwise stacked rhombic glyphs)
and clivis ligatures (e.g. the third glyph in the last line of the long
example).

Actually, those are not ligatures, and there are no ligatures at all in Kievan
notation. The two stacked diamond-shapes you refer to are simply a half note.
They refer to the space inbetween the two diamonds, in this case "mi" or
b-natural. If the diamonds where in spaces, they would refer to the line
in-between. The "squiggly-with-stem" and "double-diamond-with-stem" notes
that also seem to take up several spaces are not ligatures either, just 16th
notes. (By the way, the durations I cite are doubled by some transcribers in
order to have a whole-note as the longest duration, but this gives an
incorrect impression of the flow of the chant).


Ok, I understand. This, of course, simplifies things a lot. Then the main task really should be to incorporate these glyphs into lily. Though I unfortunately have to confess that I currently have no time at all to care for it (I am currently working hard on a thesis, and my remaining time is running out soon). Maybe Han-Wen/Jan would do it as a sponsored feature?

I am not sure what is the latest state of incorporating new glyphs into lily; so far, we used to have to design glyphs by manually writing Metafont code, which may result in high-quality glyphs, but is also an extremely time-consuming process. But nowadays, lily supports a couple of font formats. Maybe there is a simpler way of getting font characters into lily, e.g. by scanning + tracing them?

Han-Wen, Werner, what do you think?

In any case, I guess you would at least need to have high-resolution scans of hand-writings or printings (which should be sufficiently old in order to not violate copyright laws).

To me, the notation looks structurally quite similar to gothic
(also called "hufnagel") chant notation, though the glyphs are somewhat
different.

I would be interested to know what notation looked like in Poland in the
1600's, to see if it has  a parent for this style


Unfortunately, I am not familiar with Polish ancient notation. Still, since (at least the northern and western part of) Poland is mostly Catholic rather than Orthodox, I strongly guess that they used gothic and Roman (i.e. square) neumes, as well as mensural notation. I suspect, however, that it may be different for those parts of Poland near to the Ukrainian or Russsian border.

As I understand it, the only things necessary *besides* adding the glyphs
would be:

1. Spacing according text syllable. This is the only way notes are spaced in
this chant, as you can see. There is a small &  even block of space between
each textual syllable, all the notes whereof are equidistant and very close.
%%%(This is part of what makes this notation better for Znamenny Chant, being
closer in this regard to the neumatic origins and taking up less space for
long, involved melismata. It looks ugly if you try to do it with round
notes.)%%%
My hope is that this can be accomplished simply making slurs invisible in the
kievan-init.ly file |  Slur #'transparent = ##t  |
and then convincing lilypond to put an appropriate block of space between
syllables. At first I thought that this could be done with LyricSpace
#'minimum-distance , but that would only work for short syllables.


Right. There are a tricks that will force lily to typeset notes rather densely, thus resulting in almost what you probably would like to get. Still, I do not know how you could achieve strictly equidistantly and densely spaced noteheads within melismas.

2. Right now we can set shaped noteheads in LP like this:
\set shapeNoteStyles = ##(fa # la fa # la mi)
(or something like that).  We'd have to do something similar but different in
the init.ly for kievan, since several symbols (the quarter and the eight)
have slightly different forms for lines and spaces. These differences are
very important to the overall look of the music. Note that they differ  not
to according scale-position (like shapenotes) but according to whether they
are on a line or space. That means that g,8 looks different from g8

There is currently support for line/space glyph distinction for custodes and mensural flags in the c++ backend. It should not be too hard to also add it for noteheads, but I guess Han-Wen will not be too happy to add new program logic to the c++ backend. Hence I guess, for the long term, this cries for migrating the whole logic to scheme.

Furthermore, the eigth note (block with long tail) has not two but *four*
slightly different forms: two for stem-up and two for stem-down.


Just like with the custos glyphs, I guess.

I think that rest could be done just by thickening lines and such, except
perhaps that the beams on the 16th notes (single beams) extend beyond the
note-stems and half sort of blunt edges, but I'm sure that can be done
without designing anything new, right?


I am not sure; but before implementing something completely new, one definitely should first try, if the targeted result can be achieved by tweaking existing functionality.

Greetings,
Juergen

Thanks again for your response.
I look forward to doing whatever I can to implement this feature.

Sincerely,
Monk Panteleimon
Hermitage of the Holy Cross
Wayne, WV USA
address@hidden
http://www.holycross-hermitage.com/
http://www.holycrosskliros.org/

PS. I have an adaption of a long chant like this example in which the sequence
of notes is almost exactly as in the Slavonic original. I can post both if
you like, so you how can see how simple it really is.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]