2.1. Kircher’s Data Structures: Syntagmata, Pinakes, Musarithms

Examining Kircher’s data structures more closely will show the ways in which he has encoded musical data in order to make it possible for a human operator to manipulate musical materials in a mechanical way. Inside the actual arca or box there are three groups (the syntagmata) of long, solid slats (the pinakes). The choice of syntagma is determined by the style of text-setting: respectively, simple homophony, florid counterpoint, or mixed. (This software fully implements only the completely specified syntagma I and II, and it is not clear if syntagma III could be fully automated based only on Kircher’s specification.) Within each syntagma the choice of pinax is a function of the poetic meter of the input text.

The design of the pinakes recall Napier’s bones and similar calculating devices. The user removes the needed pinakes from the box and arranges them on a work surface to extract data from them. Figure 2 shows the slat used to set the hymn Ave maris stella in simple style, syntagma I, pinax 4; while figure 3 shows the one used to set the same hymn in florid style: syntagama II, pinax II. Each pinax has two components: lists of integers one through eight and lists of note symbols. Kircher uses the term musarithmos (musical numbers) primarily to refer to the tables of numbers; for greater precision I call the pitch numbers vperms (voice permutations) and the durations rperms (rhythm permutations).

2.2. Encoding Pitches and Rhythms

The vperms and rperms are arranged differently in each syntagma. In Syntagma I, all the voices use the same rhythm, so Kircher writes separate tables of vperms and rperms: the user pairs a four-voice vperm from the top of the pinax with an rperm on the bottom that is a single list of durations. Since the music in this syntagma is syllabic, the columns correspond to successive syllables in the input text. In Syntagma II, by contrast, Kircher enables complex counterpoint by pairing four-voice vperms with four-voice rperms, so that each voice has its own rhythm. Here the music is melismatic, and there can be a different number of notes in each voice. Since Kircher never provides precise rules for how to underlay the lyrical text in syntagma II, it would be more accurate to think of these vperm rows as lists of notes rather than as table columns, which is how they are implemented in the software. In most pinakes of both syntagmata, the user is supposed to choose from a different column based on the order of poetic lines in the input text. Kircher calls these strophae, which despite the cognate means lines not stanzas.

Kircher does not encode pitch directly in the vperm tables; instead, the integers are actually lookup keys for the mensa tonographica or tone table, where letters A through G plus sharp or flat symbols represent the pitch classes. In modern terms the numerals represent scale degrees relative to the modal final of a particular tone, so that in tone I, with its final on D, ˆ5 is A. Kircher uses both 1 and 8 to refer to the final, often to express stepwise motion between ˆ7 and ˆ8. Each pinax includes specifications of which tones are acceptable, sometimes in a box to the side, other times at the top of each column, and some in the introductory text. At this stage the numbers only correspond to note names and also to potential accidentals; the octave and duration are still unspecified.

To encode rhythms, Kircher uses note symbols for the different rhythmic values: breve (𝅜), semibreve (𝅝), minim (𝅗𝅥), semiminim (𝅘𝅥), and fusa (𝅘𝅥𝅮), along with the corresponding rest symbols. The rperms in syntagma I are divided into three sections by meter: for duple meter, triple major, and triple minor. In his notated realizations Kircher uses the mensuration sign 𝄵 for duple meter, which would normally indicate a metrical pattern in groups of two breves, each divided into two semibreves—i.e., imperfect tempus, alla breve. In practice, though, about half of his rhythm permutations suggest 𝄴, with groups of two semibreves. The system does not distinguish between these forms of duple meter, probably out of Kircher’s stated desire to maximize the variety of the ark’s output. This would not be a problem for someone choosing the permutations intelligently, but since Kircher does not provide a way to distinguish automatically, this implementation of the ark can produce absurd results in duple meter when the implied subdivision shifts abruptly.

In Syntagma I, based on the prior choice of musical meter, the user is supposed to choose one of the three meter categories, and then select one of the rperms from the same column as the chosen vperm. In many pinakes of syntagma I, though, there is actually only set of rperms, which is repeated at the bottom of each column. The triple-meter rperms are divided into two sections, one for a ternary proportion of 𝄵 and the other for a proportion of 𝄴. Kircher writes these interchangeably as 𝄵32 and 𝄵3 for Tripla maior, and as 𝄴32 and 𝄴3 for Tripla minor. The tactus or metrical unit in 𝄵3 falls on groups of three imperfect semibreves, in a 3:2 proportion to the groups of two semibreves in 𝄵. In 𝄴3 there are groups of three minims, in the same proportion to the binary groups of minims in 𝄴. In syntagma II all the permutations are in duple meter and the vperms and rperms are paired.

With this separate encoding of pitch and rhythm, Kircher has discovered a compact way of representing fairly complex polyphonic music. As Chierotti notes, musicians already used numbers to represent pitches in figured-bass notation, where the numbers stood for intervals above the bass note (Chierotti 1994). Kircher’s rhythm notation also drew on existing practices like the German keyboard tablature of contemporary organists like Matthias Weckmann, who wrote down letter names in one row with matching duration symbols above (Weckmann 1980). The Arca user does not need to decode either numbers or duration symbols mentally, because the numbers are lookup keys for the tone table, and the durations need only to be copied directly onto the music paper. For the rhythm, Kircher might also have used integers keyed to a lookup table (as in the software implementation), but his use of duration symbols is more logical and efficient for a human operator.

2.3. Optimized for Automatic Human Operation

For a programmer, Kircher’s use of graphical symbols for rhythm seems a hindrance because a digital computer cannnot understand them until they are converted into numbers. For this reason the software implementation uses enumeration labels for durations: it is more convenient for the human programmer to write Sb for a semibreve while the compiler converts this to an integer internally. But Kircher designed his system for an amusical human operator, for whom no thought at all would be required to simply copy the symbols from the rperm table onto the music paper. In that way Kircher’s original graphical encoding is actually more automatic and requires less computation than the software implementation.

Kircher’s use of mensural notation further illustrates his human-oriented design. For a computer, symbols must be unambiguous, so the contextual system of mensural notation in ternary meter poses an obstacle. In 𝄴3 (rendered in modern notation as 32), for example, the mensural figure 𝅝𝅝 is equivalent to the modern 𝅝𝅭 𝅝𝅭 , while the mensural figure 𝅝𝅝𝅗𝅥 is equivalent to the modern 𝅝𝅭 𝅝𝅗𝅥. In the software implementation it was simpler just to convert the ternary rperms to their modern equivalent, which in most cases simply required adding a dot to the final duration. But in the original system, no conversion or calculation was required at all: an amusical user could simply copy the durations and let the performers figure out the contextual notation.

For a human user of the physical Arca, once the input parameters are known, all of these data for composing the music can be accessed quite readily by a simple scan of the box and its contents. The human user must know the poetic meter of the text and parse the text into phrases and syllables, and then must choose the intended style, mood, and musical meter. The style tells the user which area of the box to search (which syntagma), and the user then matches the text meter to the label at the top of the appropriate pinax. The user removes the needed pinakes, lays them out in order, and moves them up and down to choose the needed vperm and rperm columns; there is left only to read across the tables and copy down the symbols. In most cases the in-order position of the poetic line determines the choice of column within a pinax. Then for vperms, the selection of a row is a free choice. For rperms in syntagma I, the choice of musical meter determines which subtable of rperms to select and the particular rperm selection is a free choice. In syntagma II, all the rperms are in duple meter and they are already matched to the vperms, so only one choice is needed. Kircher’s design of the pinax limits its useability, because the user must select different rows from a single pinax; they would be easier to use if they were built like slide rules with moveable columns.

Once the numbers are copied or noted mentally, the user can turn to the tone table, where the choice of mood determines the tone, and the tone combined with the vperm integer are the keys for looking up pitch names in the table. The tone table is least optimized part of the system for any operator (aside from the musical problems with Kircher’s whole concept of toni, to be discussed below). Although the user must look information up in the table based on the two inputs of tone number and pitch number, the table is keyed by tone number and pitch name. Instead of a simple array lookup, then, one has to scan each column to find the pitch number and then look over to the axis to obtain the pitch letter. Because the table also includes potential ficta accidentals, it would make more sense, even with a human user in mind, to put the pitch numbers on the axis and store the pitch letters with their accidentals in the table cells. In terms of computational complexity, Kircher’s table requires O(n) time, versus O(1) for a table indexed by tone and pitch numbers (Knuth 1997, 107–111).

To make matters worse, Kircher actually provides two conflicting tone tables, and in contrast to the one shown in the engraving (figure 1), the one given in the text is actually unusable for computation (Kircher 1650, II: facing 185, II: 51). The other table groups the tones out of numerical order to demonstrate patterns; it includes two conflicting entries for tone 8; and among other differences, this table lists a tone 4 with an E final and ♯ˆ3 and ♭ˆ5, while in the engraved table, tone 4 has an A final with ♯ˆ3 (Bohnert 2010, 65–77). The software implementation is based on the engraved table.

Kircher never actually specifies a rule for choosing a particular vperm or rperm within a column. In some places he implies that a random choice would increase variety, while elsewhere he suggests that the user discriminate based on musical considerations. Kircher seems ambivalent about creating a fully automated system, perhaps motivated by theological anxieties about superseding human free will and intelligence, or about chance operations. At the same time, there are numerous ways a human user can simply pick any row and achieve semi-random results. The digital automaton can only simulate a free choice by using a pseudo-random number generator, though in this implementation it would still be possible for a superstitious user to supply their own list of permutation choices.

Regardless of the inconsistencies, Kircher’s encoding system should be recognized as a symbolic representation of music intended to allow a mathematical approach. Kircher compares his system to the working-out of an algebra problem, in which simply by applying a series of rule-based transformations to a set of symbols, one can achieve previously unexpected results (Kircher 1650, II: 2). Kircher’s effort moved in the same direction as contemporary mathematicians Fermat, who shared Kircher’s interest in combinatorics, and Leibniz, with whom Kircher corresponded: his encoding system lifted music into a more abstract realm in which the sonic materials could be manipulated symbolically (Chierotti 1994, 389; Ifrah 2001, 70, 77–80, 88–92). Like Kircher, those mathematicians did not fully succeed in finding unambiguous symbolic represenations or state their proofs according to the same laws of rigor practiced today. Even today the closest we come to a symbolic language for manipulating music abstractly may be MEI-XML; but that system still lacks full support for notating music of Kircher’s era, and is designed for machines to use rather than humans (Music Encoding Initiative 2022).

3.1. The Ark in Haskell Data Types: Syntagmata, Pinakes, Perms

The Arca data type contains the same information as the physical ark though slightly rearranged:

-- | A vector of 'Syntagma' instances plus the other elements of the physical
-- device (tone table, vocal ranges, information matching tones to pinakes)
-- makes up the full 'Arca'.
data Arca = Arca {
    perms      :: Vector (Syntagma),
    tones      :: ToneList,
    systems    :: ToneSystem,
    pinaxTones :: PinaxToneList,
    ranges     :: VoiceRanges
}
    

The perms member of the Arca structure holds the pitch numbers and rhythmic durations from the pinakes. This member stores the contents of the ark box—the syntagmata and pinakes—as a set of nested vectors. Each column is a data type with two members: one vector of vperms and one of rperms. The rperms are further subdivided by meter. At the bottom level, the pitch numbers are stored in lists of Int types, while the durations are members of a custom Dur enumerator type. The following excerpts show how the Haskell data structures for rhythm permutations fit within the hierarchy of data types:

type Syntagma   = Vector (Pinax)
type Pinax      = Vector (Column)
data Column     = Column {
    colVpermTable :: VpermTable, 
    colRpermTable :: RpermTable
}
type RpermTable = Vector (RpermMeter)

-- | An 'RpermMeter' includes a vector of 'RpermChoir's all in one meter (see
-- the 'MusicMeter' data type above) and the length of that vector, since
-- Kircher has a variable number of 'Rperm's in the different meters in each
-- column.
data RpermMeter = RpermMeter {
    rpermMax :: Int,            -- ^ length of 'rperms'
    rperms :: Vector (RpermChoir)
}

-- | In Syntagma I, there is only one set of rhythmic permutation that we
-- apply to all four voices of the 'VpermChoir'. But in Syntagma II, there are
-- groups of four 'Rperm's that match up with the four voices. 
-- So we make a "choir" as a vector of 'Rperm's, though in Syntagma I this
-- will always just have a single member.
type RpermChoir = Vector (Rperm)

-- | The bottom part of the "rods" contain tables of rhythmic values written
-- with musical notes. We implement this using our 'Dur' data type for the
-- rhythmic values. An 'Rperm' is a list of 'Dur' values.
type Rperm      = [Dur]

-- | Duration values: We use the mensural names; first the base values, then
-- dotted variants, then a series marked as rest values.
data Dur = 
      DurNil -- ^ unset
    | Lg     -- ^ longa
    | Br     -- ^ breve
    | Sb     -- ^ semibreve 
    | Mn     -- ^ minim
    | Sm     -- ^ semiminim
    | Fs     -- ^ fusa
    -- ...
    deriving (Enum, Eq, Ord, Show)
    

Using these data types, then, it is possible to build to ark using the data directly from Kircher’s tables. The similarity between Kircher’s original encoding and that used in the program is clear in this excerpt of the code for the first column of syntagma 1, pinax 4 (shown in figure 2), from the submodule Arca_musarithmica.Syntagma1.Pinax04:

c0 = (c0v, c0r)
c0v = [
        [ -- 0
            [5, 5, 3, 2, 3, 3],
            [8, 7, 5, 7, 7, 7],
            [3, 2, 3, 4, 5, 5],
            [8, 5, 8, 7, 3, 3]
        ],
        [ -- 1
            [5, 5, 5, 5, 5, 5],
            [8, 8, 8, 7, 8, 8],
            [3, 3, 3, 2, 3, 3],
            [1, 1, 1, 5, 1, 1]
        ],
        -- ...
        [ -- 9
            [3, 4, 5, 4, 2, 3],
            [8, 7, 7, 6, 5, 5],
            [5, 4, 3, 8, 7, 8],
            [1, 2, 3, 4, 5, 1]
        ]
    ]
c0r = [
        [ -- Duple
            [[SbD, Mn, Mn, Mn, Sb, Sb]],
            [[MnD, Sm, Mn, Mn, Sb, Sb]],
            [[Mn, Mn, Mn, Mn, Sb, Sb]],
            -- ...
        ],
        [ -- TripleMajor
            [[Br, Sb, Br, Sb, BrD, BrD]], 
            [[SbR, Sb, Sb, Br, Sb, BrD, BrD]],
            [[Sb, Sb, Sb, Sb, Br, BrD]]
        ],
        [ -- TripleMinor
            [[Sb, Mn, Sb, Mn, SbD, SbD]], 
            [[Mn, Mn, Mn, Mn, Sb, SbD]],
            [[MnR, Mn, Mn, Sb, Mn, SbD, SbD]]
        ]
    ]
    

The ark is built by converting these nested lists to the appropriate data types and storing them in a single variable, arca, which is imported into the main program environment. To go in the other direction and access the vperm and rperm data, the program establishes various forms of lookup functions to map the input parameters (style, text meter, music meter, tone) to the relevant data. For example, to select the proper pinax the computer looks up the text meter to find a pinax label and then looks up the pinax label to find the vector index of that pinax in its syntagma. A number of inconsistencies in Kircher’s own structuring of the data and rules for its access—for one, Syntagma I, Pinax 3 actually includes data for two different textual meters—require explicit lookups rather than a simple mapping of enumeration tags to vector indices.

3.2. Reading the Input Text

Before the digital Arca can use these data and algorithms to compose music, it must read the input text prepared with all the information Kircher says is required. The Haskell program accepts input files in a custom XML format, using certain elements of the Text Encoding Initiative vocabulary (Text Encoding Initiative 2022). The file must have a head element with the title and author of the words, followed by a text element that includes the words to be set to music, in which the words are divided by syllable with long (or accented) syllables marked. Here is an abridged input text for Ave maris stella, showing the possibility of changing style, meter, and tone in different sections:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE arkText SYSTEM "arkText.dtd">
<arkText>
  <head>
    <title>Ave maris stella</title>
    <wordsAuthor>Liber Hymnarius</wordsAuthor>
  </head>
  <text>
    <section textMeter="IambicumEuripidaeum" style="Simple" 
             musicMeter="TripleMajor" tone="Tone3">
      <lg>
        <l>`A-ve, `ma-ris `stel-la,</l>
        <l>`De-i `ma-ter `al-ma,</l>
        <l>`at-que `sem-per `vi-rgo,</l>
        <l>`fe-lix `coe-li `por-ta.</l>
      </lg>
      <lg>
        <l>`Su-mens `il-lud A-ve</l>
        <l>Gab-ri-`el-is `o-re,</l>
        <l>`fun-da nos in `pa-ce,</l>
        <l>`mu-tans `E-vae `no-men.</l>
      </lg>
      <!-- ... -->
    </section>
    <!-- ... -->
    <section textMeter="IambicumEuripidaeum" style="Florid" 
             musicMeter="Duple" tone="Tone9">
      <lg>
        <l>Sit laus `De-o `Pat-ri,</l>
        <l>`sum-mo `Chris-to `de-cus,</l>
        <l>Spi-`ri-tu-i `Sanc-to</l>
        <l>`tri-bus `ho-nor `u-nus.</l>
      </lg>
    </section>
    <section textMeter="Prose" style="Simple" 
             musicMeter="TripleMajor" tone="Tone9">
      <lg><l>A-`men.</l></lg>
    </section>
    </text>
  </arkText>

The text should be divided into one or more sections, and subsequently into one or more line groups (lg elements for stanzas or paragraphs) and lines (l elements). The following attributes are required at the start of each section, and set the main parameters needed to run the ark:

style:

Either Simple or Florid

tone:

One of the twelve tones (toni) as Tone1, Tone2, ... Tone12

musicMeter:

Duple, TripleMajor, or TripleMinor

textMeter:

One of the following values:

Value	Syllables	Pattern
Prose	2–6	Free or irregular
Adonium	5	´´ ´˘˘´˘ ´´
Dactylicum	6	´´ ´˘˘ ´˘˘´˘˘ ´´
IambicumEuripidaeum	6	´´ ´˘´˘´˘ ´´
Anacreonticum	7	Penultimate long
IambicumArchilochicum	8	Penultimate short
IambicumEnneasyllabicum	9	Penultimate long
Enneasyllabicum	9	Generic
Decasyllabicum	10	Penultimate short
PhaleuciumHendecasyllabicum	11	Generic
Hendecasyllabicum	11	Generic
Sapphicum	11 and 5	Quatrains, 11.11.11.5
Dodecasyllabicum	12	Penultimate short

The Lectio module provides the functions needed to parse this text and store it in internal data structures for further processing. These structures (including Verbum for a single word and LyricPhrase for a group of Verbum) store the text grouped in syllables and words, along with information about the poetic length of each syllable and the penultimate length in each phrase. The list of parsed phrase information is then passed on to the Cogito module for setting to music.

The arca program, like Kircher’s original specification, assumes that its user is capable of preparing the text as required and making the simple decisions about style, mood, and musical meter. The program does go one step further than Kircher does to automate the composition of prose texts, though: where Kircher expects the human user to segment the text by hand into chunks of two to six syllables, the program does this automatically for input marked with textMeter="Prose". A smarter algorithm could certainly be designed, but this one groups the text into the largest chunks possible and puts the longest groups toward the end; this avoids too many choppy phrases and increases coherence.

3.3. Setting a Phrase to Music

The Cogito module provides the functions to extract and transform data from the arca and match it up with the processed input text. This is the function to compose the music for single phrase of text:

-- | Compose the music for a whole 'LyricPhrase' with one permutation from the
-- ark, and package it into a 'MusicPhrase'. Note that this is for a single
-- voice only, not the four SATB voices. 
-- Line up pitches and syllables, skipping rests. In Syntagma I, line up text
-- and notes syllabically (one syllable per note); in syntagma II (florid),
-- lump the text into a single syllable and put it as an incipit text at the
-- beginning of the phrase.
makeMusicPhrase :: Arca 
                    -> ArkConfig 
                    -> VoiceName
                    -> LyricPhrase 
                    -> Perm 
                    -> MusicPhrase
makeMusicPhrase arca config voiceID phrase perm = MusicPhrase {
        phraseVoiceID = voiceID,
        notes = theseNotes
    } where

        -- Match up pitches and syllables, skipping rests
        theseNotes = map (\(pitch, syllable) -> Note pitch syllable)
            $ zipFill (music voice) syllables isPitchRest blankSyllable

        voice       = stepwiseVoiceInRange (ranges arca) voiceRaw :: Voice
        voiceRaw    = ark2voice arca config penult sylCount 
                          lineCount voiceID perm

        range       = ranges arca
        penult      = phrasePenultLength phrase
        sylCount    = phraseSylCount phrase
        lineCount   = phrasePosition phrase
        words       = phraseText phrase

        -- In Syntagma II, put the whole phrase of lyrics as a single
        -- syllable under the first note
        syllables = case arkStyle config of
            Simple -> concat $ map makeSyllables words
            Florid -> [Syllable {
                        sylText = unwords $ map verbumText $ phraseText phrase,
                        sylPosition = Only }]
    

Within makeMusicPhrase, the function ark2voice does the work of accessing the musarithm data for a specific voice (e.g., tenor) and transforming it into pitch classes and durations in the appropriate tone. The function stepwiseVoiceInRange sets the octaves for the pitch classes in order to produce an optimal voice leading without illicit leaps. These transformation steps involve the most challenging programming in the project and reveal some of the difficulties inherent in Kircher’s specification.

3.4. Setting the Octaves for Optimal Voice Leading

In the original system, before notating a pitch a user needed to know its letter name, duration, and accidental; then the user had to choose the appropriate octave for the pitch based on the range of a particular voice. In the software these data make up the elements of the Pitch data type:

-- | A 'Pitch' stores the essential information for notating a single note.
data Pitch = Pitch {
    pnum  :: Pnum,          -- ^ Enum for diatonic pitch number
    oct   :: Int,           -- ^ Helmholtz system, middle C = 4
    dur   :: Dur,           -- ^ Duration, one of @Dur@ enum
    accid :: Accid,         -- ^ Accidental
    accidType :: AccidType  -- ^ Type of accidental for display
                            --   ('Written', 'Implicit', or 'Suggested')
} deriving (Show, Eq, Ord)
    

Everything but the octave is pulled directly from the pinax and the tone table. Setting the octave, however, requires more computing than it might seem, and in fact more than Kircher specifies.

Once again, we see a marked difference between computation devices designed for human operators as opposed to what a digital machine requires. Kircher’s original palimpsest phonotacticum is effectively a graphical computing device for setting the octave of pitches. Before matching a pitch name and rhythm, Kircher tells the user to write a temporary dot on the appropriate staff line as shown on the illustration affixed to the front of the ark. Having located the right series of rhythmic durations, the user is to copy the symbol onto the staff in place of the dot. Kircher does not provide rules for choosing between multiple valid pitch-classes within range; he only says that the user should find the next closest pitch that is on the staff. The ark’s chart of staves with clefs, signatures for cantus durus or mollis, and pitch names written on the lines establishes the possible range and gamut of pitches for a particular voice. A cantus part with a C1 clef, might range from C₃ to F₅ if limited to notes actually on the staff. With a cantus mollis (one flat) signature all the Bs in that range are flat. To set the octave for a pitch, then—to know which line to place the dot on—one simply selects from any of that pitch class within range. To find the next pitch, one calculates geometrically the shortest distance on the staff-line graph from the previous pitch to the new pitch, provided that the new pitch is still in range.

Kircher does not give a precise definition of the ranges, but in practice he will extend up to a single ledger line above or below the staves. That would give the voices the following ranges, which are used in the software (in the _vocalRanges member of the arca structure):

Even for a human operator, though, this simple algorithm is not sufficient to establish optimal voice leading within the range. In Kircher’s written-out realizations of the musarithms, he does not in fact always choose the smaller interval. Especially in the bass, he sometimes opts for an ascending fifth (especially moving to the final) rather than a descending fourth. Posing more of a problem are those permutations in which there is a long sequence of stepwise movements in one direction (as in example 2), because if the tone transposes this sequence to a position that overlaps the range boundary, it is impossible to realize it without either going out of range or turning a second into a seventh. Kircher warns against intervals that are too large but does not define them precisely. Human users would have need at least a little musical knowledge to resolve these situations on paper.

Kircher’s specifications were not sufficient to translate them into a computer program. Instead the Cogito.Musarithmetic module provides the function stepwiseVoiceInRange, which attempts to capture in programming logic the intuitive steps a human user would follow to evaluate the different possible realizations of a vperm in a given range.

-- | Find a melody for a voice with an optimal blend of avoiding bad leaps and
-- staying within range. This is the main function used in @Cogito@.
stepwiseVoiceInRange :: VoiceRanges -> Voice -> Voice
stepwiseVoiceInRange ranges v = Voice {
    voiceID = voiceID v,
    music   = adjust
}
    where
        pitches     = music v
        range       = getRange (voiceID v) ranges
        candidates  = pitchCandidates range pitches
        options     = stepwiseTree candidates
        adjust      = bestPath range pitches $ paths [] options
    

We begin with a set of Pitch objects with the octave still unset (taken from the pinax tables), and make a nested list containing all the possible octave values for each pitch. Because we know that we might need to go out of range in the end, we first expand the permissible range by a third in each direction. From these permutations we construct a tree (implemented as a left-child/right-sibling binary tree) of every possible permutation of pitches, ending a branch if the interval between parent and child is illegal. We define a legal leap as any interval less than a seventh, or an octave. Traversing the resulting tree produces a list of the possible paths.

To simulate the human user’s cultural-stylistic discretion in evaluating the possibilities, we assign each path a badness score based on three factors:

1. its ambitus, the total spread from lowest to highest pitch;
2. the sum of all intervals larger than a fourth;
3. for all the pitches that exceed the range, the sum of the interval by which they exceed the range boundary:

-- | Calculate weighted "badness" score for a list of pitches. 
badness :: VoiceRange -> [Pitch] -> Int
badness range ps = sum [ ambitus ps,
                         sumBigIntervals ps * 2,
                         sumBeyondRange range ps * 10 ]
    

These scores are weighted and combined, and then the path with the lowest score is chosen (or the first path in order with the lowest score, in case of a tie).

This algorithm yields melodies that fit reasonably within range and avoid awkward leaps. The function does what Kircher says it should do, just in a different way. Kircher’s graphical system would need to be adapted to a numeric one in any case; but the program required more specific rules than he provided to evaluate the possibilities. It obviates the need for some of the makeshift remedies that Kircher provides in place of a rigorous algorithm, which include swapping voices.

3.5. Accidentals and Church Keys

The other area in which the software must fill in an incomplete specification is the problem of setting the accidental for each pitch. Kircher’s tone table only provides potential accidentals, to be applied according to musica ficta conventions in each tonus. In practice, the problem of accidentals is a major detriment to making the ark fully automatic, regardless of whether the operator is electronic or human. From Kircher’s table of twelve toni ecclesiastici, accidentals are derived from the designation of each tone as being in cantus durus or mollis, and from the accidentals included with the pitch numbers. Cantus durus meant there were no accidentals in the signature and the tones were untransposed (tones I on D); cantus mollis meant there was one B flat in the signature and the tones were transposed down a fifth (mode I on G). Kircher does provide some rules for when to apply his suggested accidentals, but he also gives examples where additional accidentals must be added, and his own notated examples contradict his specifications.

The accidental problem arises not just because of Kircher’s incomplete instructions, but because of the structure of the tone table itself. Kircher’s table and his rules for using it represent an underappreciated attempt to theorize the rapidly changing, chaotic state of modal and harmonic practice in the seventeenth century. Previous scholars have seen Kircher’s tones too simply in terms of modes or keys (Chierotti 1994; Bumgardner 2009; Bohnert 2010). Kircher actually blurs the distinction between the twelve modes defined by Glarean and Zarlino, and the new system of toni ecclesiastici or church keys (Barnett 2002). The latter developed in part from keyboardists’ practices of playing polyphonic intonations for the eight traditional psalm tones of Gregorian chant, but more and more musicians were coming to think of tone as something like a key. Meanwhile there was a separate way of understanding mode in polyphonic composition, based primarily on the final in the lowest voice and the ambitus of the tenor voice (plagal or authentic). But there also was a growing tendency in the seventeenth century to speak prescriptively of mode as dictating not just the final but also patterns of internal cadences as well as character and affect. Performers using musica ficta practices tended to raise leading tones at cadences and sharp thirds at the ends of phrases, and with these adjustments along with greater emphasis on bass-line movements by fifth and other elements of tonality, the toni increasingly came to resemble either major or minor keys.

Most of the other seventeenth-century classification systems that Barnett describes feature eight church keys instead of Kircher’s twelve. Perhaps Kircher was trying to combine the concepts of mode, tone, and church key, or perhaps he did not understand the difference; either way, as Barnett notes, he was hardly alone in his confusion. Practice was changing rapidly and no one had yet provided a consistent theory. The way Kircher codifies the tone system in the Arca should be understood as his contribution to harmonic theory, imperfect as it is.

The tone table is typical of Kircher’s paradoxes: he maintains that there are twelve tones out of faithfulness to tradition, but he also recognizes that the traditional approach does not fully address modern practice. As in other parts of the book his attempt to synthesize old and new results in something that neither ancients or moderns would recognize. Although composers of the time wrote differently in each mode or tone, Kircher’s system simply transposes the same voice-leading patterns. Had he used full key signatures instead of suggested accidentals, Kircher would have produced something close to the modern system of transposable major and minor keys. As it is, Kircher must limit the selection of tones that can be used with certain pinakes, because not every voice-leading pattern works in every tone, given the different pattern of intervals in each. Kircher saw a variety of toni as necessary for conveying distinct affective influences to listeners, and a system with only major or minor keys would have broken consistency with centuries-old traditions of modal affect associations. Kircher’s system actually highlights the affective impact of distinct toni, because the same musarithm pattern can produce markedly different effects depending on the interval and accidental pattern of the chosen tone.

Moreover, the user is also supposed to add other accidentals as needed in order to avoid illicit melodic intervals in the bass, and thereby to avoid bad harmonic intervals above the bass. The basic rules according to Kircher are these: make all Bs flat if the tone is in cantus mollis; before adjusting the other voices one must first adjust the bass voice according to a table he provides to avoid illicit intervals (changing B–F to B♭–F, for example). Then in the upper voice apply the accidentals by rule: ♭ˆ6; in the table is always flat, but Kircher says that where there is a ♯ˆ7 in the tone table, the user should only apply the sharp when the voice is ascending to ˆ8. In his realizations, though, he goes beyond these rules: sometimes he raises a ♭ˆ6, often he writes a ♯ˆ3 at cadences, and there are numerous other exceptions. Many corner cases are unclear, such as the common idiom in the florid syntagma II of ˆ7–ˆ6–ˆ8 in tones with ♯ˆ7 and ♭ˆ6. What if one voice has ˆ6–ˆ7–ˆ8 while another voice (in a voice-exchange pattern) has ˆ8–ˆ7–ˆ6? The top voice would have ♯ˆ7 according to Kircher’s simple rule, but the lower voice would have ♮ˆ7 at the same time, making an unacceptable cross relation. It would not be hard for a competent musician of the time to resolve such cases, but Kircher does not provide enough information for a true Tyro to complete this complex task mechanically. The software implementation uses the rules Kircher does provide but expands them, using a multiple pass system to adjust the accidentals in layers. We first adjust the bass line (including fixing tritones, avoiding ♯ˆ7 when it is not moving to ˆ8), then adjust the upper voices based on their own internal patterns (raising ˆ7 when ascending).

Then we adjust the upper voices relative to the bass, and finally adjust the upper voices relative to each other. The adjustments fix cross relations and impossible intervals like an augmented fifth between bass and upper voice.

The automatic setting of O ter quaterque felix cicada (example 3) demonstrates a successful output in tone 1 with florid counterpoint. The small accidentals above the staff are the result of ficta adjustments: sharps and flats show where the program has applied Kircher’s suggested accidentals; naturals show where it has canceled them. The current algorithm does not handle every case appropriately, but does avoid the most egregious problems. It still remains unclear whether with enough rules the program could automatically produce stylistically appropriate music, or whether some features of Kircher’s tone system and musarithm patterns make that impossible.

3.6. Encoding the Music Output

In Kircher’s final stage, the user simply copied the music symbols onto staff-ruled paper, but the computer implementation encodes the musical output so that other programs may render it visible and audible. This project uses the XML format of the Music Encoding Initiative, which may easily be converted to other formats like MusicXML and Lilypond or imported into notation software (Music Encoding Initiative 2022). The software system, then, translates two sources of encoded data—the input text encoded in XML, and the ark data encoded in Kircher’s vperm and rperm tables—into a third encoding system. The example shows a portion of the automatically generated setting of Ave maris stella in simple style as rendered by Verovio. This example represents the music for the first line of text in the Soprano part:

<staff n="1" corresp="Cantus">
  <layer n="1">
    <note pname="c" oct="4" dur="breve">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="i">A</syl></verse>
    </note>
    <note pname="b" oct="3" dur="1">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="t">ve,</syl></verse>
    </note> 
    <note pname="c" oct="4" dur="breve">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="i">ma</syl></verse>
    </note> 
    <note pname="d" oct="4" dur="1">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="t">ris</syl></verse>
    </note> 
    <note pname="e" oct="4" dur="breve" dots="1">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="i">stel</syl></verse>
    </note> 
    <note pname="e" oct="4" dur="breve" dots="1">
      <accid accid.ges="n"></accid>
      <verse><syl con="d" wordpos="t">la,</syl></verse>
    </note>
    <barLine></barLine> 
    <!-- ... -->
  </layer>
</staff>

The program’s Note data type was designed to map easily onto the MEI note element, which combines pitch information with a syllable text. The members of the Pitch structure translate directly to the XML attributes or subelements of the MEI note To render the whole Phrase (one line of input text, set to music by the ark) into MEI, we map note2mei over the phrase and add barlines at the section divisions marked in the input text. The program takes advantage of MEI’s alternative mensural mode, in which music may be structured one voice (MEI layer) at a time rather than being organized by measure. The web application uses Verovio to render the MEI to graphical notation (SVG) and sound (via MIDI).

Putting all these elements together, the application’s main function builds the ark, reads and parses the input text, and generates a list of random numbers to select permutations for each phrase. The function makeMusicScore generates the music and score2mei to converts the internal data structures to MEI output. This is the central portion of the application:

main :: IO ()
main = do
-- ...
let 
    input       = readInput rawInput
    sections    = prepareInput input 
    lengths     = inputPhraseLengths sections
    metadata    = arkMetadata input

perms <- inputPerms lengths

let 
    score = makeMusicScore arca sections perms 
    mei   = score2mei arca metadata score
-- ...
writeFile outfile mei
    

4.1. The Ark as Encapsulation of Compositional Knowledge

If music can be composed mechanically using the Arca, then, what does this tell us about how Kircher and his contemporaries understood composition? When Kircher says his goal is to create a system for artificial (artificiosus) composition, he is using the word in an early modern sense where art more readily connotes a practice or technique. The seventeenth-century European or colonial composer was, in modern terms, more an artisan than an artist. An artificial system would be one built on artifice, one created by tools and ingenuity rather than a natural part of the created world. The point of artifice was to imitate the natural world, to draw out its latent patterns and order.

The basic principle of the ark is to arrange pre-formulated patterns into a new combination, and as Chierotti argues, this practice is none other than the rhetorician’s art of dispositio (Chierotti 1994, 407–409). In the Classical practice of preparing a speech (derived from authorities like Quintillian and Cicero) that stage of arranging an argument was preceded by inventio, coming up with an idea. It may seem that the ark eliminates this first step by providing a set of musical ideas which only need to be combined, obviating any expressive or communicative role of the human creator, but such a view would stem from a modern concept of invention as original creation. In Kircher’s day, invention meant as much discovery as creativity. One had to find the ideas, and the artisan’s craft was displayed in how the craftsman manipulated existing materials. A carpenter needed a pattern, tools, and lumber to begin, but his reputation depended on his ability to turn the raw materials into a finished product according to the plans.

Recent research has shown that European musicians of the seventeenth and eighteenth centuries, as late as J. S. Bach and Mozart, constructed their music from pre-existing patterns, according to well-known, standard techniques (Dreyfus 1996; Gjerdingen 2007). Gjerdingen has shown that composers trained in eighteenth-century Neapolitan conservatories were taught to build up a repertoire of conventional voice-leading patterns and to assemble these, with elaboration, into full compositions. Using such practical methods did not inhibit composers from conveying sophisticated poetic concepts and creating dramatic effects; instead, they actually enabled that communication by appealing to common tropes familiar to a community of listeners (Cashner 2022a). Completely apart from its status as a computational system, Kircher’s Arca merits study as a repository of conventional mid-seventeenth century voice-leading patterns.

In this light, then, Kircher’s device fits well within an early modern concept of musical craft. As a human-operated system, preserving the user’s ability to choose permutations intelligently and adjust them with discretion, the ark merely codifies and reduces the set of combinations available to the user and makes it easier for the human composer to find them. By ensuring that each individual combination is already a coherent and rule-compliant musical idea (inventio), and by providing an algorithm for arranging the ideas (dispositio), the ark eases the burden of a human operator, who no longer has to check each bar for such errors as parallel fifths or octaves. (This would be even more effective if Kircher himself had successfully avoided such errors in the ark.) In that way the ark fulfills the same purpose as other computing devices, from multiplication tables through Napier’s bones and slide rules, which is to reduce the number of calculations required by storing pre-calculated results.

Kircher’s procedure of finding appropriate music for one phrase of text at a time does correspond to the text-setting practice of many composers of his age. On the other hand, the lack of any motivic connection between the permutations contradicts a core principle of rhetoric, that an oration should focus on one central theme. For master musicians of Kircher’s time, applying that principle to music meant carrying a single idea (invention) or motive throughout a work (Jacobson 1982). This discrepancy between Kircher’s stated rhetorical ideal and actual contemporary musical-rhetorical practice reflects a tension throughout the Musurgia between the idea of music as an orderly, rule-based system, and the idea of music as a form of rhetoric and an expression of human passions.

If Kircher’s system reflects widespread attitudes about composition, therefore, it also reflects widespread misunderstandings. The fact that composers communicated with existing conventions does not mean that their work was purely mechanical. The task of creating music could not be reduced to numerical calculation, and Kircher’s system does not in fact succeed in doing so. The machine does something with music that is analogous to mathematical calculation, but it also demonstrates the limits of trying to reduce music to pure number.

The gap between theory and practice also shows when trying to take up Kircher on his promise that the Arca may be used to set texts in any language. Kircher hoped that his fellow Jesuit priests in overseas missions could use the Arca to generate music in local languages (Kircher 1650, II: 126–141). The arca program does show that this is technically possible. The Shakespeare text If Music Be the Food of Love, Play On (from The Tempest) included on the website demonstrates the ark’s ability to set non-Latin texts with reasonably good results. Though finding or creating non-Latin texts that fit one of Kircher’s Classical meters is a major impediment, if the textMeter is set to Prose, the program will automatically set any kind of text. As a manual system, though, Kircher’s Arca cannot have proved very useful to the pragmatic needs of missionary priests in Goa or Nagasaki.

Kircher was never strong on practicalities, in any case, and I would argue that his real goal for the Arca was to encapsulate universal musical knowledge in one device. This idea of epitomizing all knowledge of a domain through describing an imaginary computing device is echoed in many respects by Donald Knuth’s invention of the MIX computer in The Art of Computer Programming, especially given that Knuth’s first major application of the device is to permutations (Knuth 1997, 124–144, 164–175). The Arca epitomizes the overall theological argument of the Musurgia that music embodies the order of God’s creation and reflects the perfection of God’s nature, while it also has a powerful effect on the human body and soul, and serves as a form of communication and expresssion.

Like many of his seventeenth-century contemporaries, Kircher understood music as sounding number, an embodiment of the mathematical order inherent in God’s created universe, and a reflection of the perfection of God himself. The Puebla copy of the Arca musarithmica is preserved in a manuscript miscellany of notes on mathematical subjects, including geometry (with attempts to solve the impossible problems of squaring the circle and trisecting the angle), astrology, chronology, and tax accounting (Cashner 2022b). All of those forms of speculation and inquiry involved number in the attempt to trace hidden patterns of connection, and this is what Sor Juana termed Kircherizing. Out of the infinite variety of possible combinations of notes and rhythms, the user of the ark selects a specific set of permutations and thus imitates God in his original act of creation.

In this digital implementation, the Arca musarithmica not only enables someone with no knowledge of music to compose, as Kircher intended; it also brings to life a forgotten body of musical knowledge. The ark encodes pre-calculated knowledge of seventeenth-century music, a library of musical invention, that generates output that one of Kircher’s Roman contemporaries like Carissimi would probably have recognized as music, even if somewhat monotonous and with occasional quirks and errors. There are manifold possibilities for extending Kircher’s design, including using machine-learning techniques to improve the permutation data or the composition process, and even replacing the pinax tables with music in other styles or metrical patterns better suited to other languages. The machine-readable MEI output of the Arca program could be analyzed by computer and compared to other digitized corpora, which might even reveal the sources for Kircher’s permutations. With a digital implementation accessible to anyone on the Internet, musical Tyros and experts alike can do what Kircher hoped, and with no more work or knowledge than the click of a few buttons, they can generate and hear limitless permutations of never-before-heard, newly composed seventeenth-century music.