lilypond-user
[Top][All Lists]
Advanced

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

Re: "Ancient and modern from one source"


From: Michael J. O'Donnell
Subject: Re: "Ancient and modern from one source"
Date: Sat, 09 Jan 2010 12:48:39 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Regarding your question 1, I have been working on pretty much the same problem---to generate mensural and modern notation from one source file. I have made some progress, but I wasn't quite ready to provide something that others can use. If you want to check the progress, and consider joining my approach, you can see a snapshot of the work at

http://66.92.135.14/Clients/ODBOL/LilyPond/Bodleian213/

This is definitely a prototype, showing some of the structure that might be in a good solution, but some aspects of the code are clearly wrong at this stage.

The file, Bodleian213Song1.ly, contains the single source for the notes. I changed the basic notation for durations, using a LilyPond function that adjusts the note. I was able to preserve the LilyPond notation for pitches (although I may be off by an octave in the correspondence between mensural and modern).

This file uses the song in a simulation of the original MS.

http://66.92.135.14/Clients/ODBOL/LilyPond/Bodleian213/Bodleian213OriginalComplete.ly

The ugliness is partly because the manuscript is sloppy and packed too tightly, partly because LilyPond's mensural engravers still don't handle all forms of ligature, and don't support the rather unusual mixed void and solid notation of this MS. But I managed to adjust the LilyPond engravers to deal with a variant use of flags.

This file is in progress toward production of a score in modern notation:

http://66.92.135.14/Clients/ODBOL/LilyPond/Bodleian213/Bodleian213Song1ModernNotation.ly

It has lots of flaws, and I'm still pondering tactics for the next step, but it shows how some of the problems are solved.

I'm ill, and was unable to study your snippet, or Mr. Redchuk's proposal to use \looksFaster, carefully, but I wanted to get some information out to you quickly.

I thought about the sort of solution in \looksFaster, and gave up on it. LilyPond's representation of note durations is a bit peculiar. It gives the notational level of the duration in a noted hierarchy, adds dots (in the modern sense of dots adding duration, not the mensural divisiones, which aren't strictly and directly durational, but have durational implications), then provides for a rational number as a scaling factor to convert from the base 2 modern notational duration to a variant, such as triplets.

Mensural notation's mixed base 2 and 3 comes out wrong (I'm pretty sure that a MIDI performance, for example, will have some wrong durations, but I haven't tried the experiment). Individual mensural notes (I assume Mr. Flothow knows this better than I, but other readers may not) are even ambiguous, and must be studied in context to determine whether they are 3 times the next smaller note ("perfectum") or 2 times the next smaller ("imperfectum").

So, I think that something roughly like my structure, where I enter descriptions of the mensural notation, plus information to resolve notational ambiguity, in the form of some LilyPond music functions, then define those functions differently to produce different sorts of scores.

If the whole thing turns out well, it will eventually be worth writing a variant parser for a "mensural note mode," with some support for provisional automatic inference of perfection vs. imperfection. For now, I postulated some general purpose functions to set appropriate duration log, dots, and scaling values, and provided rather short mnemonic functions for data entry, based on mensural terminology: \ma maxima, \lo longa, \br breve, \sbr semibreve, \mi minima, etc. I add "D" for a dot that appears in the mensural score (I'm thinking of the additive dot, and I'm not sure how to deal with divisiones), or "P" for perfectum (an editorial judgment) as appropriate. When there is no "D" nor "P", imperfect duration is assumed. Aside from the extra space, and the redundant "\", I found that entering abbreviations for the ancient names of durations helped me think about the mensural notation, so I favor a somewhat better condensed notation that is still based on mensural terminology.

WARNING: if you try to use my functions, you have to make sure that each of the durations in LilyPond's scheme is 1 (whole note), so that it will be translated correctly by my functions. Because of the default that makes a note's duration the same as the previous note's, you only have to enter "1" on the first note. But, an accidental omission of the first "1", or an accidental inclusion of any other duration value, e.g. "c4", will cause very confusing problems. I realize that this structure is a kludge for prototyping purposes, and should be fixed for any nice system.

Then, the functions that engrave notes for a mensural score interpret these values one way, while those for a modern score interpret them another way. I have almost reasonable automatic computation of most of the mensural fill in, at least for the notation of the Bodleian 213 MS. For the modern notation, I just wrote out the cases that occur in my particular piece, and I haven't yet tried to write a program that works them out automatically. There should also be provision for editorial selection of different choices of modern note for the mensural tactus. I just used 3/2 for the tempus perfectum prolatio imperfectum in my first song, and 3/4 for the all breve sections. (If I have understood correctly, mensural notation tends to keep the "tactus" at a fairly constant speed, while shifting it to different note values---semibreve vs. breve in the Bodleian MS. Modern notation tends to keep a quarter note at roughly the same speed, allowing the beat/tactus to vary between eighth, quarter, dotted quarter, and half notes. This leads to confusing relations, where a shift of tactus up from semibreve to breve corresponds to a shift of beat down from half note to quarter note. I wish that compound times could be written as such---e.g. 2/(3/8) instead of 6/8.)

There will be an uncommon, but important, case when the mensural notation has both tempus and prolatio perfectum. Certain long notes, written as a single note in mensural notation, will require ties in the modern notation (e.g., 9/8 time with a dotted whole tied to a dotted half note). In principle, the existing LilyPond methods for breaking notes into tied pairs across bar lines should apply, but my first experiment suggested that these methods don't work yet.

So, you are welcome to any use that you can find in my functions and methods. If you, or anyone, would like to collaborate, I can set up a Wiki, or repository with CVS or Git, or anyone's favorite collaboration/versioning tool.

Regarding question 2, I'm still wrestling with modern bar lines myself. I would like to be able to print a first modern version with no bars, and rather arbitrary automatic line breaks, to catch any gross problems in the correspondence between voices. Then, I'd like to gradually introduce bar lines if/when they seem helpful, possibly differently in different voices, possibly in some arbitrary synchronized form just for reference.

I'm also thinking of some tool for placing some sort of tactus marks above the score in the mensural version, as an editing aid, to be removed in a normal final presentation.

Since my first example song from the MS has the same mensurations in the 3 voices, I didn't yet fool with different time signatures in different voices for the modern version. I'm expecting that to be straightforward, by splitting the right engraver between staffs instead of associating it with the score.

I also think that the basic structure of an input form describing the mensural notation, that can be retargeted through some parameters to produce a variety of mensural and modern scores, is the right starting point.

Cheers,

Mike O'Donnell
----------------------------------------------------------------------

Message: 1
Date: Fri, 08 Jan 2010 18:57:29 +0100
From: "C.Flothow" <address@hidden>
Subject: "Ancient and modern from one source"
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Editing ancient music often implies that you have to halve note values 
to make the score readable for modern musicians.
On the other hand it is much easier to correct your score if you can use 
original values (and sometimes you want to use both versions anyway).
I've tried a number of ways to get a reasonable work flow but  I've got 
still two questions concerning the following snippet:


% ----------------------------

1. Is it possible to have ONE source for the three input files? How do 
you do it?
2. In the middle staff a bar line is printed only at every other bar?  
How can I avoid that?
    If I leave the Timing_translator in the score environment every bar 
line is printed but I've found no way to have correct time signatures 
within the staff.
    What have I missed?
Thanks
Chris

------------------------------

Message: 6
Date: Sat, 09 Jan 2010 14:22:27 +0200
From: "Dmytro O. Redchuk" <address@hidden>
Subject: Re: "Ancient and modern from one source"
To: "C.Flothow" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="UTF-8"

У пт, 2010-01-08 у 18:57 +0100, C.Flothow пише:
  
Editing ancient music often implies that you have to halve note values 
to make the score readable for modern musicians.
On the other hand it is much easier to correct your score if you can use 
original values (and sometimes you want to use both versions anyway).
    

Recently i've written this email:
http://www.mail-archive.com/address@hidden/msg53213.html

I used \looksFaster exactly for this need: i've typed and corrected a
score with breves and then asked lilypond to do it twice (and, possibly,
twice again) faster.

\looksFaster { \time 3/2 \sopranoOne }

or even

\looksFaster { \looksFaster { \time 3/4 \sopranoOne } }

  
Thanks
Chris
    

  

reply via email to

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