➡ We are looking for a suitable platform to compile standalone versions of Bol Processor BP3.
Currently, Bol Processor BP3 is the association of a console (written in C language) and a set of PHP/HTML/CSS/Javascript files working as its interface. A console version of Csound may also be attached. Check page Bol Processor ‘BP3’ and its PHP interface for installation details.
This all works beautifully in a design compatible with several 64-bit systems: MacOS, Linux and Windows. However it requires the installation of an Apache+PHP package to run the interface. (We are currently using the free-of-charge version of MAMP on Mac computers to develop BP3’s interface.)
The next step is to create a standalone application replacing the web browser and its PHP/HTML/CSS files. The application will have Linux, MacOS and Windows implementations.
A number of platforms have been developed during the past two decades for building desktop applications emulating the behaviour of a web browser. Most of these seem to be abandoned, or at least not updated for years, but we have a strong confidence that PHP Desktop will be eligible for this process.
We urgently need to assess the ability of PHP Desktop (in its current Linux implementation) to compile a standalone version of Bol Processor’s interface. We wish to hire a programmer for this particular task. Please contact us to discuss terms of collaboration.
Below is a list of requirements for a compilation of the PHP/HTML/CSS/Javascript interface. Please provide links to alternate solutions in comments at the bottom of this page, or privately via the Contact page.
Requirements
Display a HTML/PHP page using links to its CSS file(s)
Support the “require_once()” procedure to bind several PHP pages together
Support all types of HTML “<input>” instructions: fields, buttons, checkboxes etc.
Support “$_GET” and “$_POST” to handle forms
Support PHP “open()” instruction to create/update text files
Support PHP “exec()” instruction to send commands to the console
Support multi-tag or multi-window work space
Support Javascript “window.open()” to create pop-up windows
Note that neither databases nor SESSION variables are used in the interface. Temporary data is preserved in files automatically trashed once obsolete.
A global variable “$which_system” may be set at the begin of the code to compile desktop applications running under different systems. Minimum system versions could be: MacOS 10.14 (Mojave), Windows 10, and Linux ≥ January 2019.
A contribution to The Ratio Symposium, 14-16 Dec. 1992, Den Haag (The Netherlands). Published in Barlow, Clarence (ed.) The Ratio Book. Den Haag: Royal Conservatory - Institute of Sonology. 2001: 86-101. This paper is referenced on HAL ⟨hal-00134179⟩ and quoted in Polymetric structures.
Abstract
This paper deals with various problems in quantifying musical time encountered both in the analysis of traditional drumming and in computer-generated musical pieces based on “sound-objects”, hereby meaning code sequences controlling a real-time sound processor.
In section 1 it is suggested that syntactic approaches may be closer to the intuitions of musicians and musicologists than commonly advocated numeric approaches. Further, symbolic-numeric approaches lead to efficient and elegant solutions of constraint-satisfaction problems relative to symbolic and physical durations, as illustrated in sections 2 and 3 respectively.
Polymetric expressions are the basic representation model of musical data in Bol Processor. The word is a mix of polyphony and polyrhythm, the former evoking superposed streams of musical events, and the latter a metric adjustment of their durations.
This page illustrates the syntax of simple expressions and their interpretation by the polymetric expansion algorithm exposed in paper Two algorithms for the instanciation of structures of musical objects (Bel 1992). This process may get extremely complex since a whole musical work — e.g. Beethoven’s Fugue in B flat major — is handled by Bol Processor as a single polymetric structure.
In this tutorial, simple notes (“C4″, “D4″ etc.) are used following the “English” convention. All time-setting processes could be illustrated with sound-objects or simple notes in alternate conventions: “Italian/Spanish/French” or “Indian”.
Symbolic versus physical duration
Music notation systems (for humans) make use of symbolic rather than physical durations. Their units are beats rather than (milli)seconds.
Three quarternotes on a score in Western conventional music notation
For instance, if the time signature is 3/4, we will have 3 quarter-notes (crotchets) in a bar (see picture). A half-note (minim) lasts twice longer than a quarter-note in the same context. Other relative durations are expressed in the same manner.
To get the physical duration of a note we need an additional piece of information: the metronome value, for instance “mm = 100″ meaning 100 beats (quarter-notes) per minute.
A metronome value (by default 60 bpm) is declared in the settings file of a Grammar or Data page. With this setting, note “E4″ on a Bol Processor score represents a “E” of the 4th octave played in 1 beat with physical duration 1 second.
This convention extends to sound-objects labelled with arbitrary names whose default durations are set by the streams of MIDI events or sequences of Csound instructions they are made of. Mapping symbolic to physical time for the performance of structures of sound-objects (with their metric and topologic properties) is a sophisticated process accomplished by a time-setting algorithm. A practical example is discussed on page Interactive improvisation with sound-objects.
Polymetric expression
Typical forms of polymetric expressions are:
field 1, field2 or {field 1, field2} indicating that field1 and field2 should be superposed and the total symbolic duration should be adjusted to that of field1;
field1 • field2 or {field1 • field2} indicating that field1 and field2 should be in sequence and the symbolic duration of each field should be adjusted to that of field1;
{expression} is equivalent to expression.
Curled brackets ‘{‘ and ’}’ are required to produce multilevel expressions.
➡ Periods notated as bullets ‘•’ on Data and Grammar windows are converted to plain periods before sending to the console, due to its rejection of some Unicode signs.
For instance, {{C4 D4, E4 F4 G4}, E5} yields the following time structure with a metronome set to 60 beats per minute:
Item {{C4 D4, E4 F4 G4}, E5} on a sound-object graph Duration is 2 beats as set by the first field “C4 D4″
The use of the first field to set the total duration is highlighted by the following examples in which fields appear in a reverse order:
{C4 D4 E4, F4 G4} Duration 3 beats
{F4 G4, C4 D4 E4} Duration 2 beats
Rests (silences) may be notated “-” for single-unit rests, or with integer numbers and ratios. The following shows a single-unit rest and a more complex one lasting 2.5 beats:
The same rules of time-setting apply to sequences in which commas are replaced with periods. For instance:
Sequence F4 2 1/2 G4 • C4 D4 or {F4 2 1/2 G4 • C4 D4} Duration is set by that of the first field “F4 2 1/2 G4″ = 4.5 beats applied to the second field
Superpositions and sequences can be combined (even in multilevel expressions) such as:
Undetermined rests are a powerful feature of polymetric expressions used to avoid uneasy calculations. The polymetric expansion algorithm calculates (symbolic) durations producing the least complex expression.
They may be notated “…” or “_rest” in Data or Grammars.
➡ Since the console does not recognize this Unicode symbol, it is rewritten as “_rest” by the PHP interface.
Let us start with a trivial example. In {C4 D4 E4, … F4 G4}, undetermined rest “…” will be replaced by a single-unit rest:
{C4 D4 E4, … F4 G4} = {C4 D4 E4, _rest F4 G4}
This solution produces the simplest polymetric expression. The same simple case is that of {… C4 D4 E4, F4 G4}:
{… C4 D4 E4, F4 G4} ={_rest C4 D4 E4, F4 G4}
If a field of the polymetric expression contains several undetermined rests, these are assigned equal durations — in such a way that the complexity of the structure remains minimal. Consider for instance {… C4 D4 … E4, A4 F4 G4}:
An undetermined rest may even be assigned duration 0 in case this yields a simpler expression. For instance, in {… C4 D4 … E4, F4 G4} duration 0 yields a “three in two” polyrhythm whereas duration 1 would yield “five in two”. The criterion for evaluating complexity is getting the lowest common multiple (LCM) of the numbers of units in each field, in effect 6 against 10. Therefore the solution is:
{… C4 D4 … E4, A4 F4 G4}
Every field of a polymetric expression may contain undetermined rests. Consider for instance {… C4 D4 E4, A4 B4 F4 … G4}. Here, again, assigning duration zero to each undetermined rest yields the simplest structure since “four in three” (LCM = 12) is a better trade-off than “five in four” (LCM = 20).
{… C4 D4 E4, A4 B4 F4 … G4}
A more complex structure is assigned to {C4 D4 E4, A4 B4 F4 … G4 A4, C5 … D5} with rests of 1 unit in the second and third fields. The LCM of 3 and 6 is 6, which is the lowest value achievable for this structure.
{C4 D4 E4, A4 B4 F4 … G4 A4, C5 … D5}
Note that there is an equivalent solution in terms of complexity: assigning duration 0 to the rest in the third field. When several solutions are valid, the algorithm selects in priority the one containing the fewest null-duration rests.
A similar case is {C4 D4 E4, A4 B4 F4 … G4 A4, C5 … D5 E5}:
{C4 D4 E4, A4 B4 F4 … G4 A4, C5 … D5 E5}
Here, the first rest has been assigned 1 unit and the second one 3 units. This yields the LCM of 3 and 6 = 6. Another optimal (equivalent) solution would be to assign 0 to the second rest, but it has been discarded due to the heuristics of avoiding null-duration rests.
Replacing commas with periods yields the same structure in a sequential form:
“C4 D4 E4 • A4 B4 F4 … G4 A4 • C5 … D5 E5″ = {C4 D4 E4 • A4 B4 F4 … G4 A4 • C5 … D5 E5} Duration of the first field “C4 D4 E4″ is applied to the 2nd and 3d ones which makes a final count of 3 x 3 = 9 beats
Tied notes or sound-objects
Sound-objects or simple notes can be concatenated (“tied”). Consider for instance:
“C4 D4 C4 E4 C4 F4 E4″
and its variation with ties notated “&”:
“C4& D4 &C4& E4&&C4 F4 &E4″
The time interval of a tied note/sound-object may cross the limits of (tree-shaped) polymetric structures. For instance:
{C4 D4}{E4{2,E4,C4,G4}}
{C4& D4}{E4 {2,E4,&C4,G4}}
The challenge of handling tied events is discussed on page Tied notes.
Real music is “polymetric”
Rules and heuristics associated with polymetric expressions make sense when dealing with real musical items. Notably, they made it possible to import MusicXML scores and interpret them as Bol Processor data (read page).
This page is for developers of Bol Processor BP3 (read installation). It is not a formal description of algorithms carried by the console’s C code, but rather an illustration of their management of musical processes that may be helpful for checking or extending algorithms.
All examples are contained in the “ctests” folder of the distribution.
Example of tied notes
Let us look as measures #18 to #22 of Listz’s 14th Hungarian Rhapsody imported from a MusicXML file — read Importing MusicXML scores. The printed score of measures #19 to #21 is the following:
Measures #19 to #21 of Listz’s 14th Hungarian Rhapsody Source: ManWithNoName in the MuseScore community
Tied notes are visible on this score. Slurs connecting notes at different pitches are ignored by the Bol Processor. These could be interpreted via the _legato(x) performance control, but setting a suitable value for ‘x’ would require a careful analysis of the context. Ties link the same pitch such as “Ab1″ (A flat in octave 1) at the bottom of the score lines. There are 3 occurrences of tied “Ab1″ in this section, the first one starting at the end of measure #18 and the third one ending in measure #21.
In Bol Processor notation, this fragment yields a sequence of polymetric structures. For the sake of clarity each measure has been set to a separate paragraph:
The 3 occurrences of tied “Ab1″ and “B1″ are shown in colors. “Ab1&” is the beginning of a tie and “&Ab1″ the end (of the same color). Longer ties would occasionally require sequences such as “Ab1&” + “&Ab1&”+ “&Ab1″.
These ties merge the (symbolic) time intervals of the beginning and ending occurrence. For instance, score “C4& &C4″ could be replaced with “C4 _ ” or equivalently “{2, C4}”. The merging of time intervals takes place in procedure FillPhaseDiagram() of file “FillPhaseDiagram.c”.
While parsing the compact polymetric structure for building the phase table — read Complex ratios in polymetric expressions — the algorithm calls GetSymbolicDuration() (in “SetObjectFeatures.c”) to calculate the symbolic duration of a sound-object or simple note. By default, this is easy to compute. Flag ignoreconcat is set to true if the sound-object or note is not followed with a ‘&’. The duration is set by prodtempo = Prod / tempo.
If ignoreconcat is false, GetSymbolicDuration() looks for the next acceptable occurrence of the note or sound object preceded by a ‘&’. Acceptability implies the following conditions:
The note or sound-object should be under the same MIDI channel or the same Csound instrument;
The date of the next occurrence should be greater than the on-setting date.
These conditions are easy to trace in the example. For instance, “A1b&” cannot be paired with “&A1b” because the latter occurs at an earlier date. The next valid occurrence is “&A1b”. The same holds for pairs shown in other colors. Each color indicates a matching pair.
Once the duration has been set, the algorithm calls PutZeros() to fill as many columns as required for setting the total duration of the pair of tied notes — read Complex ratios in polymetric expressions.
In addition, when “&A1b” is parsed later, it should be ignored because the time span of the note has already been set by calling GetSymbolicDuration() and PutZeros() at the time of parsing “A1b&”. Skipping these procedures is ensured by flag foundendconcatenation.
Graphic display
The following is a sound-object graph of measures #20 to #21 on which the borders of intervals in tied notes are marked with dashed lines. The borders of “Ab1& … &AB1″ (red color) are self-explanatory when compared with the musical score displayed above: each occurrence is an instance of “{1/8, Ab1&} &Ab1″.
Symbolic durations can be checked on physical time: since the tempo is 13/10, the first part has a physical duration 1/8 x 10 / 13 = 0.09 second and the second part 10/13 = 0.77 s.
Measures #20-21 of Listz’s 14th Hungarian Rhapsody on a sound-object graph
At the end of measure #21 is the beginning of note “B1&” tied to its occurrence “&B1″ in measure #22. The border is marked by a blue dashed line. The piano roll of measures #21-22 displays this binding of “B1″:
Measures #21-22 of Listz’s 14th Hungarian Rhapsody on a piano roll
Liszt’s 14th Hungarian Rhapsody interpreted by the Bol Processor on a Pianoteq physical-model synthesizer Source: ManWithNoName in the MuseScore community
Arpeggios
Arpeggio on chord ”{Db, Gb, Bbb, Eb}” “Bbb” is interpreted as “A”.
Borders marked as green dashed lines belong to polymetric expression {1/4,Db4& Gb4& A4& Eb5&}{7/2,&Db4,&Gb4,&A4,&Eb5}, the interpretation of an arpeggio on the chord at the beginning of measure #20. This interpretation is constructed while importing MusicXML files — read the PHP code in file “_musicxml.php”.
A brief sequence “Db4 Gb4 A4 Eb5″ (duration 1/4 beat) is played before the chord “{Db4, Gb4, A4, Eb5}” whose duration is set to 7/2 beats. Each note in the sequence is tied to its occurrence in the chord.
A clear illustration of the usage of tied notes and undetermined rests is a short musical phrase borrowed from a tutorial by Charles Ames, a pioneering designer of composition algorithms. The phrase is supplied as a musical score but its interpretation requires a careful analysis of the musical structure, yielding the following Bol Processor score:
To make things clear we need to look at the score in common music notation, divide it to blocks associated with variables, and ultimately write a grammar “-gr.Ames” for building the structure. Below are details of the analytical process and resulting graphs of sound-objects and piano roll:
In this grammar, undetermined rests have been notated “…”. In its current version, the Bol Processor console no longer recognizes the Unicode symbol for ellipsis “…”. Therefore, it is automatically converted it to “_rest” by the PHP interface.
Undetermined rests are a powerful feature of polymetric expressions used to avoid uneasy calculations. The polymetric expansion algorithm calculates (symbolic) durations producing the least complex expression. Read more on tutorial Polymetric structures.
Tied notes are precisely the ones denoted by links on the musical score. The sound rendering is:
Rendering of “-gr.Ames” with metronome mm = 60
Error tracing
The construction of suitable time intervals for tied notes depends on the completion of pairs — e.g. “A4&” followed by “&A4″ — in the Bol Processor score. Some pairs may remain incomplete for either reason:
The musical item has been sliced to chunks, using the PLAY safe (instead of PLAY) option to speed up computation, and the two parts belong to separate chunks;
An error in the imported MusicXML score;
An error of the algorithm — more and more rarely.
Unbound tie(s) signaled in a chunk
Case (1) is limited by the method for chunking items: each chunk is designed to contain the same number of starting and ending ties. Nonetheless this is not warranted because chunks are limited in size.
Failure to balance ties is indicated below the PLAY safe button (see picture).
Errors are listed in color on the trace of the play process. These may not induce noticeable changes in the performance. Nonetheless, we recommend to submit faulty data to designers.
Below is an example of error in a MusicXML score of Beethoven’s Fugue in B flat major. A tie starts at note “Db5″ (MIDI key #73) in the beginning of measure #573 (part 2) but it ends nowhere:
Measures #573 to 575 (part 2) of Beethoven’s Fugue in B flat major, with an unending tie starting at “Db5″
Read the fragment of the MusicXML score to check this inconsistency. There are more inconsistencies in this score, for instance a slur starting on note “C4″ of measure #646 (part 3) which does not end. This makes it difficult to interpret slurs as legato.
This page is for developers of Bol Processor BP3 (read installation). It is not a formal description of algorithms carried by the console’s C code, but rather an illustration of their management of musical processes that may be helpful for checking or extending algorithms.
All examples are contained in file “-da.checkPoly” of the “ctests” folder in the distribution.
Syntax of silences
In Bol Processor data/grammar syntax, silences (rests in conventional music terminology) are represented either with an hyphen ‘-’ for one-unit duration, or integer ratios to specify a more complex duration:
“4″ is a rest of 4-unit duration
“5/3″ is a rest of (approximately) 1.666-unit duration
“3 1/2″ is a rest of 3.5-unit duration
For instance, “C4 C5 3/2 D5 E5″ yields the following piano roll with a rest of 3/2 (1.5) units starting on beat 2 and ending on beat 3.5:
Piano roll of item “C4 C5 3/2 D5 E5”
In this tutorial we use the default metronome value = 60 beats per minute.
Another simple example is {3 1/2, C3 D3 B2} which is the sequence of notes “C3 D3 B2″ constrained to total duration 3 1/2 (3.5) beats. This silence is the first field of the polymetric expression (explained below). This yields the following piano roll:
or equivalently the sound-object graph:
Syntax of tempo
Any sequence of symbols compliant with Bol Processor syntax is processed as a polymetric expression. Typical forms are:
field 1, field2 indicating that field1 and field2 should be superposed and the total duration should be that of field1;
field1.field2 indicating that field1 and field2 should be in sequence where the duration of each field should be that of field1;
{expression} is equivalent to expression.
Brackets ‘{‘ and ’}’ are used to produce multilevel expressions.
A set of examples of polymetric expressions may be found on tutorial Polymetric structures.
For instance, {{C4 D4, E4 F4 G4}, E5} yields the following structure:
Item {{C4 D4, E4 F4 G4}, E5} on a sound-object graph
To interpret this structure, the Bol Processor needs to insert explicit tempo values into the expression. Precisely, in this case, the most compact representation with explicit tempo values would be:
*1/1 {{C4 D4,*2/3 E4 F4 G4} ‚*2/1 E5}
Expressions such as “*2/3″ indicate that the duration of each note (or sound-object) should be multiplied by 2/3 irrespective of preceding statements. This means that the durations of notes “E4”, “F4” and “G4” should be 2/3 seconds as shown on the graph.
Creating the compact representation with its explicit tempo markers may require recursive calls of a sophisticated procedure named PolyExpand() in file “Polymetric.c”.
At this stage it is important not to confuse notations:
“2/3″ is a silence of duration 2/3 beats;
“_tempo(2/3)” multiplies the current tempo by 2/3. This is a relative tempo marker;
“*2/3″ sets the current durations of units to 2/3 of the metronome period. This is an absolute tempo marker. Equivalently, “*4″ multiplies durations by 4, and “*1/5″ or “/5″ divides them by 5 — whereas “1/5″ is a silence lasting 1/5 beat.
The third syntax is the one used by Bol Processor’s time-setting algorithms. Despite its syntactically validity, we do not recommend using it in grammars and data because it may create conflicting durations in polymetric structures. For example, {*2/1 A4 B4, *3/1 A5 B5} does not make sense because it attempts to force the first field to duration 2 x 2 = 4 beats and the second field to 3 x 2 = 6 beats. The proper (never conflicting) manner of changing a tempo in data or grammars is the “_tempo(x)” performance tool.
Expanding a polymetric expression
In the preceding paragraph, we saw {{C4 D4, E4 F4 G4}, E5} represented internally as *1/1 {{C4 D4,*2/3 E4 F4 G4} ‚*2/1 E5}. This internal representation is the most compact one containing explicit tempo markers. Therefore it the one maintained along all steps of time-setting.
Humans may prefer to see a more comprehensive representation called the expanded polymetric expression:
/3 {{C4_ _ D4_ _, E4_ F4_ G4_} , E5_ _ _ _ _}
This is obtained clicking the EXPAND button on a Data page. Underline symbols ‘_’ represent extensions of the duration of the preceding unit. These should not be confused with ‘-’ (silences). To make things clear, let us replace a ‘_’ with ‘-’:
/3 {{C4_ _ D4_ _, E4_ F4 - G4_}, E5_ _ _ _ _}
This yields the following structure in which “F4” is not extended:
The expanded polymetric expression may grow larger than comprehensive to a human observer. In this case, only the compact version is returned.
In Bol Processor console’s code, sound-objects (of all kinds) are identified by numbers. The variable used to designate them in algorithms is always ‘k’ or ‘kobj’. There is an option to display object identifiers on a graph which is set by constant SHOWEVERYTHING. If set to true, the preceding sound-object graph would be:
Notes “C4”, “D4” etc. bear identifiers kobj = 2, 3 etc. Identifier “0” is reserved for extensions ‘_’ and “1” for silences “-”, none of which is shown on the graph. An exception is object #8 labelled «-» which is an out-time (null-duration) “silence” marking the end of the structure to facilitate its synchronization with the next item.
The phase diagram
Given a compact polymetric structure, time-setting algorithms require a table in which every column is assigned a date (in physical time). Cells of this phase diagram contain the identifiers of sound-objects, including “0” and “1”. It is created by procedure FillPhaseDiagram() in file “FillPhaseDiagram.c”.
It is easy to guess that the table would grow very large if compression procedures were not applied. For instance, Listz’s 14th Rhapsody would require no less than 9 x 1021 cells! The reason is that Bol Processor computes symbolic durations as integer ratios. A symbolic duration of 5/3 will never be replaced with “1.666” for two reasons: (1) roundings would cumulate as noticeable errors, and (2) we don’t know in advance how many decimals need to be kept. The physical duration of 5/3 beats depends on the metronome and the succession of “_tempo(x)” controls modifying the tempo.
Let us first examine a non-problematic case. The polymetric expression /3 {{C4_ _ D4_ _, E4_ F4 - G4_}, E5_ _ _ _ _} creates the following phase diagram:
In this example, if the metronome is set to 60 beats per minute the physical duration assigned to each column is 1/3 second = 333 ms. When the diagram grows larger, this physical duration may decrease beyond limit. This is where quantization is invoked. It is set to 10 milliseconds by default, which means that two events occurring within than 10 ms may be written into the same column. To this effect, the compact polymetric structure is rewritten using a compression rate (Kpress) that makes it fit a phase diagram of suitable size.
If the musical piece lasts for 10 minutes we’ll still get 10 x 60000 / 10 = 60000 columns in the table. Filling the phase diagram requires a very high compression rate, for instance more than 5 x 1012 for Beethoven’s Fugue in B-flat major.
Adding to the difficulty, the algorithm must take care of sequences of events falling into the same column. This situation is signaled by variable toofast obtained by comparing the current tempo with the maximum tempo accepted in the structure. In the toofast case, each event is written on a new line of the table in such a way that the sequential order of the stream will be respected.
Thus, we end up with 12132 lines for the phase table of Beethoven’s Fugue, in which the longest toofast stream contains 625 events — notes or sound-objects. These 625 events performed within a single frame of 10 ms actually include events ‘_’, namely extensions of notes belonging to the stream.
Dealing with complex ratios
In Bol Processor terminology, an integer ratio p/q is “complex” when either ‘p’ or ‘q’ goes beyond a limit which depends on the source code. The limit is ULONG_MAX, the maximum value of an unsigned long type, currently 18446744073709551616.
In Bol Processor’s console code, ‘p’ and ‘q’ are actually encoded as double floating-point numbers whose mantissa may contain as many digits as unsigned long integers. Arithmetic operations are performed on fractions. Each resulting fraction is checked for complexity by a procedure named Simplify() in file “Arithmetic.c”:
While ‘p’ or ‘q’ is greater than ULONG_MAX, divide ‘p’ and ‘q’ by 10;
Divide ‘p’ and ‘q’ by their greatest common divider (GCD).
Part (1) of the Simplify() procedure generates rounding errors, yet these represent a few units of very large numbers. In this way, the accuracy of symbolic durations is maintained throughout the computation of complicated polymetric structures.
Complex ratios in silences
Let us check the effect on quantization by playing:
C4 C5 36001/24000 D5 E5
Ratio 36001/24000 cannot be simplified. Nonetheless, 1/24000 beat would last 0.04 ms which is much less than the 10 ms quantization. Therefore, the ratio can be approximated to 36000/24000 and simplified to 3/2. The final result is therefore “C4 C5 3/2 D5 E5″:
Let us now consider “C4 C5 35542/24783 D5 E5″ which looks similar given that 35542/24783 (1.43) is close to 1.5. However, the computation is more complex… Using the 10 ms quantization, the ratio is reduced to 143/100 and the compact polymetric expression is:
The 143/100 silence is now represented as a unique ‘-’ (kobj = 1) followed by 142 ‘_’ (kobj = 0). This sequence is toofast because tempomax, the maximum tempo accepted here, would be ‘50’ instead of ‘100’. The compression rate is Kpress = 2. A complete explanation requires the polymetric algorithm exposed here.
The process of filling the phase table is found in “FillPhaseDiagram.c”. We call ‘ip’ the index of the column into which the next event will be plotted. In the most common situation, for instance writing “C4 _ _” (object #2), two procedures are invoked:
Plot() writes ‘2’ (kobj) into column ip
PutZeros() writes two zeros into columns ip + 1 and ip +2.
Thus “C4 _ _” will have a symbolic duration of 3 units, as expected.
The case is different with a silence lasting 143/100 because the toofast situation imposes that less than 142 ‘_’ should be inserted after ‘-’. To this effect, a (floating-point) variable part_of_ip is initialized to 0 and gets incremented by a certain value until it reaches beyond Kpress. Then Plot() and PutZeros() are called, part_of_ip is reset and a new cycle starts… until all 142 ‘_’ of the compact polymetric expression have been read.
The increment of part_of_ip in each cycle is:
part_of_ip += Kpress * tempomax / tempo;
In this simple example, tempo = 100, tempomax = 50 and Kpress =2. Therefore the increment is 1 and part_of_ip will reach the value of Kpress after 2 cycles. This amounts to saying that one in two ‘_’ will be skipped.
Incrementing ip requires a more complicated process. The algorithm keeps track of column numbers in the table as it would be created with Kpress = 1. These numbers are generally much larger than the ones of the actual phase diagram. The large number i is mapped to ip via the Class() function:
unsigned long Class(double i) { unsigned long result; if(Kpress < 2.) return((unsigned long)i); result = 1L + ((unsigned long)(floor(i) / Kpress)); return(result); }
Thus, each cycle of reading ‘_’ in the toofast situation ends up incrementing i and then updating ip via the Class(i) function. The increment of i is:
prodtempo - 1
in which:
prodtempo = Prod / tempo
Variables Prod and Kpress are calculated after creating the compact polymetric expression. Prod is the lowest common multiple (LCM) of all values of tempo, i.e. ‘100’ in this example.
Let us use integers Pclock and Qclock to define the metronome value as Qclock * 60 / Pclock. If the metronome is set to its default value of 60 bpm, then Pclock = Qclock = 1.
The following (simplified) code calculates Kpress and updates Prod accordingly:
_tempo(80/39){F1,C2}_tempo(80/39){2,F2}667/480 {53/480,G1,G2}{1/2,Ab1,Ab2}{1/2,B1,B2} Metronome is set to 60 beats per minute.
Let us calculate the duration of the silence between “F2” and “G1” in two ways:
In the source polymetric expression, this silence is notated 667/480. Since the tempo is 80/39, its duration should be 667/480 * 39/80 = 0.67 beats (confirmed by the graph).
In the compact polymetric expression, we find one ‘-’ object followed by 666 ‘_’ prolongations at speed *13/12800. The duration is therefore 667 * 13/12800 = 0.67 beats.
Following the algorithm step by step would be tricky because Prod = 2496100 , Kpress = 24961 and tempomax = Prod / Kpress = 100. Within the silence, tempo = 985 and the increment of part_of_ip is 24961 * 100 / 985 = 2 534.11167… The number of cycles before part_of_ip reaches the value of Kpress is ceil(9.85) = 10. This means that 9 in 10 objects ‘_’ have been skipped.
Conclusion
These examples and explanations provide insights for an easier comprehension of code in file “FillPhaseDiagram.c” of the console’s code. We hope that it will serve for future development or migration of algorithms.
This is also a demo of the complexity of time calculations when dealing with polymetric structures able to carry all details of real musical works — read Importing MusicXML scores for “real life” examples.
Images of tempered scales created by the Bol Processor
The following are Bol Processor + Csound interpretations of J.-S. Bach’s Prelude 1 in C major (1722) and François Couperin’s Les Ombres Errantes (1730) — both near the end of the Baroque period — using scales constructed with temperaments (Asselin 2000). The names and tuning procedures follow Asselin’s instructions (p. 67-126). Images of the scales have been created by the Bol Processor.
The construction of these scales with the Bol Processor is explained in detail on page Microtonality. The complete set of scale images is available on this page.
➡ We hope to publish better sound demos after receiving a set of well-designed Csound instruments (“orc” files). Apologies to harpsichord players, tuners and designers!
Let us start listening to the piece in equal temperament, the popular tuning of instruments in electronic times. Uneducated musicians believe that “well-tempered” equates “equal-tempered”…
➡ Don’t hesitate to click “Image” links to display circular graphic representations of scale intervals highlighting consonance and dissonance.
The following are traditional temperaments, each of which has been designed at a particular time to meet the specificities of musical repertoires en vogue (Asselin 2000 p. 139-180).
H.A. Kellner’s BACH in 1975 (p. 101) ➡ ImageBarca in 1786 (p. 106) ➡ ImageBethisy in 1764 (p. 121) ➡ ImageChaumont in 1696 (p. 109) ➡ ImageCorrette in 1753 (p. 111) ➡ ImageD’Alambert-Rousseau 1752-1767 (p. 119) ➡ ImageKirnberger II in 1771 (p. 90) ➡ ImageKirnberger III in 1779 (p. 93) ➡ ImageMarpurg in 1756 (p. 117) ➡ ImagePure minor thirds in 16th century (p. 82) ➡ ImageRameau en do in 1726 (p. 113) ➡ ImageRameau en sib in 1726 (p. 115) ➡ ImageSauveur in 1701 (p. 80) ➡ ImageTartini-Vallotti in mid. 18th century (p. 104) ➡ ImageWerckmeister III in 1691 (p. 194) ➡ ImageWerckmeister IV in 1691 (p. 96) ➡ ImageWerckmeister V in 1691 (p. 199) ➡ ImageZarlino in 1558 (p. 85) ➡ Image
The preceding example was Zarlino’s temperament which should not be confused with the popular Zarlino’s “natural scale”, an instance of just intonation:
J.S. Bach’s disciple Johann Kirnberg (1721-1783) - (source)
J.S. Bach’s Well-Tempered Clavier (BWV 846–893) is a collection of two sets of preludes and fugues in all 24 major and minor keys, dated 1722. To assess the validity of a tuning scheme it would be necessary to listen to all pieces. Readers impatient to know more may be interested in a “computational” approach of this subject, read Bach well-tempered tonal analysis and listen to results on page The Well-tempered Clavier.
Fortunately, there are historical clues to optimal choices: Friedrich Wilhelm Marpurg received information from Bach’s sons and pupils and Johann Kirnberger, one of these pupils, designed tunings which he claimed to represent his master’s idea of “well-tempered”.
On page Tonal analysis of musical items we show that the analysis of tonal intervals tends to suggest the choice of Kirnberger III rather than Kirnberger II. However, the temperament designed in 1701 by French physician Joseph Sauveur also seemed to be a better fit in terms on melodic intervals — and indeed it sounds beautfiful… This may in turn be challenged by the systematic matching of all works in books I and II against tuning schemes implemented on the Bol Processor — read page Bach well-tempered tonal analysis.
François Couperin’s Les Ombres Errantes (1730)
Again, apologies to harpsichord players, tuners and manufacturers!
This piece is part of François Couperin’s Quatrième livre published in 1730 ➡ read the full score (Creative Commons licence CC0 1.0 Universal). We used it to illustrate the interpretation of mordents when importing MusicXML files.
Since a few of the following temperaments have been designed (or described?) after 1730, these were unlikely to be used by the composer. Let us try them all anyway, and find the winner!
Equal temperament ➡ ImageH.A. Kellner’s BACH (p. 101) ➡ ImageBarca in 1786 (p. 106) ➡ ImageBethisy in 1764 (p. 121) ➡ ImageChaumont in 1696 (p. 109) ➡ ImageCorrette in 1753 (p. 111) ➡ ImageD’Alambert-Rousseau 1752-1767 (p. 119) ➡ ImageKirnberger II in 1771 (p. 90) ➡ ImageKirnberger III in 1779 (p. 93) ➡ ImageMarpurg in 1756 (p. 117) ➡ ImagePure minor thirds in 16th century (p. 82) ➡ ImageRameau en do in 1726 (p. 113) ➡ ImageRameau en sib in 1726 (p. 115) ➡ ImageSauveur in 1701 (p. 80) ➡ ImageTartini-Vallotti in mid. 18th century (p. 104) ➡ ImageWerckmeister III in 1691 (p. 194) ➡ ImageWerckmeister IV in 1691 (p. 96) ➡ ImageWerckmeister V in 1691 (p. 199) ➡ ImageZarlino in 1558 (p. 85) ➡ ImageZarlino’s “natural scale” ➡ Image
Matching harmonic intervals of “Le Petit Rien” with “Rameau en do” temperament
The best temperament for this piece might be Rameau en sib designed by Couperin’s contemporary Jean-Philippe Rameau for musical works with flats in their key signature (Asselin, 2000 p. 149) — such as the present one. Read page Tonal analysis of musical items for the description of a systematic (automated) analysis confirming this choice.
We may end up listening to François Couperin’s Le Petit Rien (Ordre 14e de clavecin in D major, 1722) with two sharps in the key signature suggesting the use of a Rameau en do temperament.
François Couperin’s “Le Petit Rien” (1722), mm = 80, with a “Rameau en do” temperament ➡ Image Source: MusicXML score by Yvan43
Work in progress
Chapter VIII of Pierre-Yves Asselin’s book (2000 p. 139-180) contains examples of musical works highlighting the relevance of specific temperaments. Given that the scores of many Baroque and classical masterpieces are available in digital format MusicXML, we hope to use Bol Processor’s Importing MusicXML scores to transcode them and play these fragments with the suggested temperaments.
Despite the limitation of comparing temperaments on only two musical examples, the aim of this page is to illustrate the notion of “perfection” in sets of tonal intervals — and music at large. Read the discussion: Just intonation: a general framework. At least, we hope to convince readers that equal-temperament is not the “perfect” solution!
Musicians interested in continuing this research and related development may use Bol Processor BP3’s beta version to process musical works and create new tuning procedures. Follow instructions on page Bol Processor ‘BP3’ and its PHP interface to install BP3 and learn its basic operation. Download and install Csound from its distribution page.
References
Asselin, P.-Y. Musique et tempérament. Paris, 1985, republished in 2000: Jobert. Soon available in English.
MusicXML is a very popular XML-based file format for representing Western musical notation. It is designed for the interchange of scores between scorewriters and other musical devices.
Inside a MusicXML file…
A MusicXML file contains all the information required to display a musical score in Western music notation. It also contains data which can be processed by a sound device to “play” the musical score. The basic rendering may sound mechanical if it misses control over volume, velocities, tempo etc. which are not accurately displayed on printed scores. As such, it may be used as a tool for checking the representation of a musical work, or as a teaching assistant for deciphering scores.
Beyond their use as an exchange format between score editors, many MusicXML files are reworked by groups of musicians — such as the MuseScore community — for the imbedding of intensity and tempo statements. Sound examples are shown below.
Importing musical scores from musical archives to Bol Processor makes it possible to use them (or fragments of them) in grammars producing variations, for example Mozart’s musical dice game. Owing to the Csound interface, these musical works may even be played back with specific tunings as explained on page Microtonality. The latter was an incentive for implementing MusicXML conversion, making it possible to check works of the Baroque and classical repertoires against the diversity of meantone temperaments documented by historians.
The MusicXML to Bol Processor converter is fully operational on the PHP interface of BP3. Follow instructions on page Bol Processor ‘BP3’ and its PHP interface to install BP3 and learn its basic operation. Download and install Csound from its distribution page.
Bol Processor’s data format
The Bol Processor has its own data format for representing musical items aimed at producing sound via its MIDI or Csound interface. This format is displayed and saved as pure text.
The syntax of Bol Processor data is based on polymetric structures — read tutorial on Polymetric structures. A few elementary examples will clarify this term:
{A4 B4 C5} is a sequence of three notes “A4”, “B4”, “C5” played at the metronomic tempo
{A4, C5, E5, A5} is a A minor chord
{la3, do4, mi4, la4} is the same chord in Italian/Spanish/French notation
{dha4, sa5, ga5, dha5} is the same chord in Indian notation
{C4 G4 E4, F3 C4} is a two-level structure calling for the juxtaposition and time alignment of sequences “C4 G4 E4” and “F3 C4”, which yields a polyrhythmic structure that may be expanded to {C4_ G4_ E4_, F3__ C4__} in which ‘_’ are prolongations of the preceding notes.
{5, A4 Bb4 C5} is sequence “A4 Bb4 C5”, 3 note played over 5 beats. Their durations are therefore multiplied by 5/3.
{7/16, F#3 G3} is sequence “F#3 G3” played over 7/16 beats. The duration of each note is multiplied by (7/16) / 2 = 7/32.
Unlike conventional Western musical scores, polymetric structures may be recursively imbedded with no limit in their complexity (except the machine). A few complex structures are discussed on page Harm Visser’s examples. All calculations of timings are performed on integer ratios, thereby achieving the best accuracy compatible with the system.
Why do we need to import scores?
Bol Processor’s data format is altogether compact, computational and comprehensible by humans. However its compactness makes it uneasy to edit complex polymetric structures. Practically, these are produced by generative grammars…
A grammar producing pieces of tonal music may require “building blocks” extracted from existing musical works. Till now (in Bol Processor BP1 and BP2) it was possible to map the computer keyboard to arbitrary signs representing drum strokes (see the initial project) or capture notes in common music notation (three different conventions). Sound-objects can also contain Csound scores and/or sequences of instructions imported from MIDI files.
Things get complex when dealing with polyphonic tonal music. Since this material exists on scores in Western music notation, and these scores have been digitised to interchange formats such as MusicXML, an import procedure capturing the whole complexity of the score is a great asset. Mozart’s Musical dice game is a good example of this necessity.
In practice you can pick up and rework fragments of the very large musical repertoire shared in MusicXML format, or create your own building blocks with a score editor such as Werner Schweer’s MuseScore — a public-domain program working with Linux, Mac and Windows. MuseScore recognises many input/output formats and it is able to capture music via MIDI or Open Sound Control.
Importing and converting a MusicXML score
A few public-domain MusicXML scores are found in the “xmlsamples” of the sample set bp3-ctests-main.zip shared on GitHub. Most of them are fragments used for illustrating the format. We start with a very short fragment of “MozartPianoSonata.musicxml” for which the graphic score is also available:
Mozart’s piano sonata, an excerpt in common Western music notation
First create a Data file named for instance “-da.musicXML”. Default settings will be sufficient for this example, but a “-se.musicXML” file may be declared on the data window, with the result that you will be prompted to create it. Keep default settings as they include graphic display.
To import the MusicXML file, click the Choose File button on top of the editing form, select the file and click IMPORT.
The machine will display the list of “parts” contained in the score. Each part may be assigned to an instrument, including human voices. This score contains a unique part to be played on an Acoustic Grand Piano which would be rendered by channel 1 of a MIDI device. This MIDI channel information appears in the Bol Processor score and may be later mapped to a Csound instrument.
Clicking CONVERT THEM (or it) is the only things that remains to be done!
This will create the following Bol Processor data:
// MusicXML file ‘MozartPianoSonata.musicxml’ converted // Score part ‘P1’: instrument = Acoustic Grand Piano — MIDI channel 1
Imported scores can be played, expanded, exploded and imploded
Indeed this looks uneasy to read, but remember that a lay person would not even make sense of scores in Western music notation! Fortunately, a PLAY button is now available to listen to the piece. By default, it is also saved as a MIDI file which can be interpreted by a MIDI soft synthesizer such as PianoTeq:
Excerpt of Mozart’s piano sonata, an excerpt played by Bol Processor with PianoTeq
The same process can be invoked in the Csound environment. If Csound is installed and responsive, selecting the Csound output format will produce a Csound score immediately converted to an AIFF sound file displayed on the process window:
Playing the same piece via Csound. Note that the duration is 12 seconds (instead of 10) because a silence of 2 seconds (by default) is appended at the end of the track.
Understanding the conversion process
Let us compare the score in common Western notation with its conversion to Bol Processor data. This may be helpful for knowing the features and limitations of MusicXML files. Remember that this format is a full description of a graphic representation of the musical work. It is up to the musician to add implicit information necessary for a proper (and artistic) rendering of the piece…
Musical scores of classical works are segmented in measures marked by vertical lines. This score contains 5 measures of equal durations. The MusicXML file contains data telling that the duration of each measure is 2 beats, meaning 2 seconds if the metronome is beating at 60 beats per minute. However, instruction _tempo(2) doubles the speed, which results in measures lasting for 1 second. The third measure contains a chord {2, F#5, A5, D6} of half notes (minims) lasting 2 beats.
The Bol Processor score also displays the five measures, each of which is interpreted as a polymetric structure. A MIDI channel instruction has been automatically inserted in the beginning of each measure, indicating which part it belongs to.
Let us read the first measure and compare it with its conversion on the score:
The ‘2’ (green colour) is the total duration of the polymetric expression (i.e. the measure). On the first two lines is the upper score (in G key on the graphic score) whereas the third line (in F key on the image) is the lower score. On top of the upper score is a half note C#6 interpreted as {2, C#6}. A comma (in red colour) indicates a new field of the polymetric structure that needs to be superposed to the first field. It contains a chord {C#5, E5, A5} of quarter notes (crotchets) lasting 1 beat followed by a rest of 1 beat notated “-”.
➡ The printed score indicates an arpeggio on the chord which is ignored at the moment to facilitate explanations. Arpeggios will be considered below.
In order to complete the field we need a rest of 1 beat that is not indicated on the graphic score, although the corresponding gap is mentioned in the MusicXML file. In Bol Processor notation, rests can be notated ‘-’ or as integer numbers/ratios. For instance, a 3-beat rest could be notated “---” or {3, -} or {3}, whereas a rest of 3/4 beat should be notated {3/4, -} or {3/4}.
The lower score contains a sequence that is troublesome for a machine: three grace notes “A2 C#3 E3″. Grace notes are not assigned any duration in MusicXML files, so we follow the practice of granting this sequence with a duration of half of the following principal note, here the first occurrence of “A3″ declared as eight notes lasting 1/2 beat. Consequently, the stream of grace notes has a total duration of 1/4 beat and is notated {1/4, A2 C#3 E3}. It is followed by A3 whose length is reduced by one half, therefore {1/4, A3}. The following 3 occurrences of A3 have a total duration of 3/2 beats, hence {3/2, A3 A3 A3}.
The structure of this first measure is made clear on the graphic display. Note that, unlike the piano roll display, this object representation does not position sound-objects vertically according to pitch values:
The first measure of the Mozart sonata’s sample
The rest of the score can be deciphered and explained in the same manner. Bol Processor notation is based on very simple (and multicultural) principles yet difficult to create by hand… Therefore it is most conveniently produced by grammars or extracted from MusicXML scores.
Note that it is easy to modify the tempo of this piece. For instance, to slow it down, insert instruction _tempo(1/2) at the beginning:
Exploding scores
Clicking the EXPLODE button segments the musical work as separate measures which make it easier to analyse the conversion or reuse fragments:
The five measures of Mozart’s sonata exploded on the Data window
Each measure can be played (or expanded) separately. Segments are labelled [item 1], [item 2] etc. for an easier identification.
Button IMPLODE reconstructs the original work from its fragments.
A more complex example
Let us try DichterLiebe (op. 48) Im wunderschönen Monat Mai by Robert Schumann. The MusicXML score is in the “xmlsamples” folder distributed in the sample set “bp3-ctests-main.zip” shared on GitHub, along with its graphic score (read the PDF file).
The Bol Processor score is more complex:
“Im wunderschönen Monat Mai” (Robert Schumann)
Im wunderschönen Monat Mai (Robert Schumann) interpreted by the Bol Processor on a PianoTeq vibrophone
The correcting rendering of this piece on Bol Processor is obtained with its (default) setting of quantization to 10 milliseconds. Quantization is a process merging the time-settings of events when these are proximate by less than a certain value: a human would not notice an error of 10 milliseconds in timing, but merging “time streaks” is an efficient way of saving memory space when building a phase diagram of events. In this particular piece, setting the quantization to 30 ms already would create a noticeable default of synchronisation. This gives an idea of the accuracy expected from human performers, which their trained auditive and motional systems handle without difficulty.
Note that this MusicXML score comprises 2 parts, one for voice and the second one for piano. These are sent to MIDI channels 1 and 2 respectively. These channels should in turn activate different Csound instruments. When several instruments are not available it is possible to listen to their parts separately by importing selected parts of the score.
Since the first measure is incomplete (1/4 beat), the piano roll is not aligned on the background streaks (numbered 0, 1, 2…):
This problem can be solved by inserting a silence of duration 3/4 in front of the score:
3/4 {_chan(1){1/4,{{1/4,-}}},_chan(2){1/4,{{1/4,C#5},{1/4,-}}}} … etc.
which yields:
Piano roll aligned to the time streaks
The musical work may be interpreted at different speeds after inserting a “_tempo()” instruction in the beginning. For instance, given that the metronome is set to 60 beats per minute, inserting _tempo(3/4) would set the tempo to 60 * 3 / 4 = 45 beats per minute. To produce a sound rendering of this particular piece we inserted a performance control _legato(25) extending by 25% the durations of all notes without modifying the score. We also set up a bit of reverberation on the PianoTeq vibrophone. The resulting piano roll was:
Same piece with _legato(25) extending note durations by 25%
Time-reversed Bach?
The _retro tool also generates bizarre transformations, most of which would sound “unmusical”. Indeed, a few of them are interesting. For instance, consider Bach’s Goldberg VariationNr. 5 played on Bol Processor + Csound with (Bach’s presumably favourite) Kirnberger II temperament — read page Comparing temperaments:
Bach’s Goldberg VariationNr. 5 (Kirnberger II temperament) — MuseScore transcription by crashbangzoom808
Listen to the same piece after applying the _retro tool:
Time-reversed version of Bach’s Goldberg Variation Nr. 5— Kirnberger II temperament
In Bol Processor scores produced by the import of MusicXML files, many (musically meaningful) modifications can be achieved, such as inserting variables and sending the data to a grammar that will produce entirely different pieces. To achieve this, the grammar — for instance “-gr.myTransformations” — needs to be declared on top of the Data window.
The claim in favour of “well-tempered tuning” for interpreting Baroque music can be further assessed by comparing the following versions of J.-S. Bach’s Brandenburg Concerto Nr 2 in F major (BWV1047) part 3:
J.-S. Bach’s Brandenburg Concerto Nr 2 in F major (BWV1047) part 3 — Kirnberger II temperamentJ.-S. Bach’s Brandenburg Concerto Nr 2 in F major (BWV1047) part 3 — Equal-tempered tuning
Complex structures
As per this writing, BP3 has been able to import and convert all MusicXML files contained in the “xmlsamples” folder. However, pieces rated “too complex” might not be played nor expanded because of overflow . Given that it is possible to isolate measures after clicking the EXPLODE button, a PLAY safe button was created to pick up chunks and play them in a reconstructed sequence. The only drawback is that graphics are deactivated, which is of lesser importance given the complexity of the work.
Listen for instance to Lee Actor’s Prelude to a Tragedy (2003), a musical work made of 22 parts assigned to various instruments via the 16 MIDI channels — read the graphic score.
Lee Actor’s “Prelude to a Tragedy” (2003) with incorrect assignment of some instruments, played by the Bol Processor using its Javascript MIDIjs player
The mapping of instruments is faulty because most channels are played as piano instead of flute, oboe, English horn, trumpet, viola etc. Parts mapped to channels 10 and 16 are fed with drum sounds. All these instruments have been synthesised by the Javascript MIDIjs player installed on BP3’s interface. A better solution would be to feed the “prelude-to-a-tragedy.mid” MIDI file to a synthesiser able to imitate the whole set of instruments, for instance MuseScore.
Score part ‘P1’: instrument = Picc. (V2k) — MIDI channel 1 Score part ‘P2’: instrument = Fl. (V2k) — MIDI channel 2 Score part ‘P3’: instrument = Ob. (V2k) — MIDI channel 3 Score part ‘P4’: instrument = E.H. (V2k) — MIDI channel 4 Score part ‘P5’: instrument = Clar. (V2k) — MIDI channel 5 Score part ‘P6’: instrument = B. Cl. (V2k) — MIDI channel 5 Score part ‘P7’: instrument = Bsn. (V2k) — MIDI channel 7 Score part ‘P8’: instrument = Hn. (V2k) — MIDI channel 8 Score part ‘P9’: instrument = Hn. 2 (V2k) — MIDI channel 8 Score part ‘P10’: instrument = Tpt. (V2k) — MIDI channel 9 Score part ‘P11’: instrument = Trb. (V2k) — MIDI channel 11 Score part ‘P12’: instrument = B Trb. (V2k) — MIDI channel 11 Score part ‘P13’: instrument = Tuba (V2k) — MIDI channel 12 Score part ‘P14’: instrument = Timp. (V2k) — MIDI channel 13 Score part ‘P15’: instrument = Splash Cymbal — MIDI channel 10 Score part ‘P16’: instrument = Bass Drum — MIDI channel 10 Score part ‘P17’: instrument = Harp (V2k) — MIDI channel 6 Score part ‘P18’: instrument = Vln. (V2k) — MIDI channel 14 Score part ‘P19’: instrument = Vln. 2 (V2k) — MIDI channel 15 Score part ‘P20’: instrument = Va. (V2k) — MIDI channel 16 Score part ‘P21’: instrument = Vc. (V2k) — MIDI channel 16 Score part ‘P22’: instrument = Cb. (V2k) — MIDI channel 16
Lee Actor’s “Prelude to a Tragedy” (2003) interpreted by MuseScore
Remember, though, that these meant to be raw interpretations of musical scores based on a few quantified parameters. To achieve a better rendering, performance parameters should be inserted in the Bol Processor score for controlling volume, panoramic etc. on a MIDI device, or an unlimited number of parameters with Csound.
Stylistic limitations are evident in transcriptions of jazz music, in contrast with musical works initially composed in writing. A transcription of improvisational material is merely a fixed picture of one of its innumerable variations. Therefore, its score may convey an educational, rather than artistic, vision of the piece. The following is a transcription of Oscar Peterson’s Watch What Happens from a MusicXML score:
Oscar Peterson’s “Watch What Happens” interpreted by Bol Processor on PianoTeq, mm = 136 bpm Source: MusicXML score by jonasgssin the MuseScore community
The Bol Processor score of this transcription is as follows. The metronome has been raised to 136 beats per minute — notated _tempo(136/60) — to match an estimated performance speed. This is easy with a machine! Below are an excerpt of the piano roll display and the complete Bol Processor score:
Excerpt of piano roll for Oscar Peterson’s “Watch What Happens”
In a very different style, Tchaikovsky’s famous June Barcarole in G minor (1875):
Tchaikovsky’s “June Barcarole” in G minor interpreted by the Bol Processor with the Pianoteq physical-model synthesizer
Another complex example is Beethoven’s Fugue in B flat major (opus 133). Since we could not get the piano four-hands transcription, we used the string quartet version. Played as a single item it takes no less than 372 seconds to compute, whereas PLAY safe delivers the same in 33 seconds.
Again, in this piece, the Javascript MIDIjs player cannot synthesize the two violins, viola and cello tracks (MIDI channels 1 to 4). Therefore the MIDI file was sent to PianoTeq for a fair piano rendering of mixed channels.
Beethoven’s Fugue in B flat major — a piano version interpreted by the Bol Processor with the Pianoteq physical-model synthesizer
Another emblematic example of complex structure is La Campanella, originally composed by Paganini for the violin and transposed to the piano by Franz Listz :
La Campanella — Liszt’s piano version interpreted by the Bol Processor with the Pianoteq physical-model synthesizer Source: MusicXML score by Heavilon in the MuseScore community
The Bol Processor score of this piece (a single polymetric expression) is made of only 37268 bytes. Dynamics are interpreted as velocities :
In this Bol Processor score, pedal start/end commands are translated to _switchon(64,1) and _switchoff(64,1), and a randomization of dates by 20 milliseconds is applied as per instruction _rndtime(20) — read below Pedals and Randomisation.
According to Wikipedia : “La Campanella” (Italian for “The little bell”) is the nickname given to the third of Franz Liszt’s six Grandes études de Paganini, S. 141 (1851). Its melody comes from the final movement of Niccolò Paganini’s Violin Concerto No. 2 in B minor, where the tune was reinforced metaphorically by a ‘little handbell’. After listening to Liszt’s piano version interpreted by the Bol Processor — and its human performance by Romuald Greiss on the Wikipedia page — I recommend watching the outstanding violin performance of Paganini’s original work, in 2008, by maestro Salvatore Accardo (video).
Measure #96 of Liszt’s “La Campanella”
Measure #96 of Liszt’s “La Campanella” Bol Processor score (top left), MuseScore display, piano roll (bottom left) and sound-objects
In measure #96 (image above), the locations of vertical blue lines are irrelevant because of the varying tempi listed below (green arrows). Note that these are metronome values specified for the performance (tags sound tempo), slightly different from the ones displayed on the printed score (tags per-minute). Nonetheless, if the MusicXML score is well-designed, there is no significant difference between importing only performance metronome values and including printed score values ; this point is discussed below, read Tempo interpretation: prescriptive versus descriptive.
Ahead with grammars
Before looking in greater detail at material imported from MusicXML files, let us address the issue of using fragments of this material to create music in the Bol Processor task environment.
After importing/converting a MusicXML score, clicking EXPLODE will break it to separate items, one per measure as per the MusicXML structure:
The EXPLODE button on the Data page.
The data has been chunked to units item 1, item 2 etc. Note that it is possible to play each measure separately and display its sound-objects or its piano roll.
The CREATE GRAMMAR button will now launch the conversion of this data to a grammar:
The CREATE GRAMMAR button
The new grammar is displayed in a popup window and can be copied to a Grammar page:
The new grammar has been created
This is a basic transformation. Playing this grammar would simply reconstruct the musical work as it was imported. However, since each measure is now labeled as a variable M001, M002 etc., these variables can be used as the “building bricks” of a new compositional work.
Performance controls
MusicXML files contain descriptive information for use by mechanical playback machines but not displayed on the graphic score. For instance, wherever the score displays “Allegretto” the file contains a quantitative instruction such as “tempo = 132”.
Trills in measure 10 of Beethoven’s Fugue in B flat major
Trills as encoded in the MusicXML file
Another noticeable case is the representation of trills (see picture above). In some (but not all) MusicXML scores, they appear explicitly as sequences of fast notes. Consequently, they are accurately rendered by the interpreter of the MusicXML file. In other cases they need to be constructed — read below in Ornamentation.
In the same measure #10, a fermata appears on top of the crotchet rest. Its duration is not specified because it is up to the discretion of the performer or conductor, but the Bol Processor follows a common practice of making it 2 times the duration of the tagged rest.
MusicXML files contain indications of sound dynamics which the Bol Processor may interpret either as _volume(x) or _vel(x) commands. The latter (velocity) is proper to instruments such as piano, harpsichord etc.
Graphic indications of the dynamics (signs ffff to pppp) are used in case a numeric value is missing. This value is estimated as per the MakeMusic Finale dynamics convention.
Options for importing a MusicXML file
Some prescriptive information appearing on the graphic score is not interpreted. The first reason is that it would be difficult to translate to Bol Processor performance controls — for instance stepwise/continuous volume control, acceleration etc. The second reason is that the aim of this exercise is not to produce the “best interpretation” of a musical score. Score editing programs perform better! Our sole intention is to capture musical fragments and rework them with grammars or scripts.
It would be difficult to reuse a musical fragment packed with strings of performance controls relevant to its particular context in the musical work. To this effect, the user is offered options to ignore volume controls, tempo and channel assignments in every imported MusicXML score. These can later be deleted or remapped in single clicks (see below).
Remapping channels and instruments
MusicXML digital scores contain MIDI channel specifications to separate parts/instruments. These are visible in the Bol Processor score after the conversion. In general, they need to be remapped for the sound output device. MIDI channels would be modified to match instruments available on a MIDI synthesizer, and _ins() instructions may be needed to call instruments available in the Csound orchestra.
This remapping car easily be operated at the bottom of Data or Grammar pages:
The note convention when importing MusicXML scores is English (“C”, “D”, “E”…) by default. This form allows its conversion in a single click to Italian/Spanish/French (“do”, “re”, “mi”…) or Indian (“sa”, “re”, “ga”…) conventions.
Clicking the MANAGE _chan() AND _ins() button displays a form listing all occurrences of MIDI channels and Csound instruments. Here, for instance, we are planning to keep MIDI channels and insert _ins() commands to call Csound instruments described in a “-cs” Csound resource file:
Error corrections
MuseScore’s correction of the defective sequence (top score)
MuseScore signaled an error in measure 142 of the MusicXML score for Beethoven’s Fugue: the total timing of notes in part 1 (the uppermost score) is 3754 units which amounts to 3.66 beats (instead of 4) on a division of 1024 units per quarter note. MuseScore fixed this mistake by stretching this sequence to 4 beats with the marking of a defective silence at the end.
The Bol Processor behaves differently. Its notion of “measure” as a polymetric structure is not based on counting beats. It takes the structure’s top line as reference for timing so that “measures” may be of variable durations. Its interpretation of this measure is the following: ratio 3755/1024 denotes exactly the (presumably defective) duration of this measure according to the MusicXML score:
The graphic rendering of this measure indicates that the four sequences are perfectly synchronized.
To fix the error it is sufficient to replace “3755/1024” with “4”.
Error notification while converting Beethoven’s Fugue
As per this writing, the Bol Processor has been able to import most MusicXML scores and play them correctly. Errors may still occur with very complicated files, notably due to inconsistencies (or rounding errors) in the MusicXML code. For instance, the numbering of measures looks confusing in Liszt’s 14th Hungarian Rhapsody (due to implicit measures) and a few values of <backward> are incorrect. These details are detected and errors fixed while converting the file.
Tempo interpretation: prescriptive versus descriptive
MusicXML scores contain tempo statements of two kinds: (1) metronome prescriptive indications available on conventional printed scores and (2) their descriptive modifications for a proper rending of the mechanical interpretation.
In the prescriptive setting, tempo controls (sound tempo tags) type inside measures are discarded. Only per-minute tags are interpreted. This leads to a “robotic” rendering: acceleration/deceleration miss the ardor and delicacy of human interpretations. However, since the transcription reflects the plain printed score, its fragments are more eligible for a reuse. Assuming that it is exactly the version published by the composer (which is indeed arguable) we may take the following interpretation as reflecting the music that Liszt “had in mind” irrespective of the performer’s interpretation.
Liszt’s 14th Hungarian Rhapsody imported by the Bol Processor and played on PianoTeq with only “prescriptive” tempo controls. Source: ManWithNoName in the MuseScore community
In a detailed interpretation, all tempo statements are converted, including the “non-printing” ones (sound tempo tags) which we call descriptive. The global rendering is more pleasant if these indications make sense musically. For instance, this is Liszt’s 14th Hungarian Rhapsody with all tempo controls. Note that the total duration has increased by 15 seconds:
Liszt’s 14th Hungarian Rhapsody with all “descriptive” tempo controls. Source: ManWithNoName in the MuseScore community
Options to rely on exclusively prescriptive, or exclusively descriptive, tempo statements should be considered when there is an inconsistency between the printed score (per-minute tags) and performance details (sound tempo tags). The former are meant to be used by a human interpreter whereas the latter are designed for machines…
Several versions of the same musical work may be found in shared repositories. Below is an interpretation of the same 14th Hungarian Rhapsody based on the MusicXML score customized by OguzSirin:
Liszt’s 14th Hungarian Rhapsody imported by the Bol Processor and played on PianoTeqwith all “descriptive” tempo controls. Source: OguzSirinin the MuseScore community
Excerpts of piano roll for Liszt’s 14th Hungarian Rhapsody transcribed by OguzSirin
The entire work is contained in a single polymetric expression (see code below) which needs to be “expanded” to fill a “phase diagram” of sound-objects. Its complete expansion would create no less than 7 x 1023 symbols… outnumbering the estimated 400 billion (4 x 1011) stars in the Milky Way! Fortunately, polymetric representations can be compressed in a comprehensive format (see code below) and processed to create the expected sequence of sound objects. The compression rate for this item is greater than 5 x 1022, yielding a Bol Processor score without any loss of data.
Despite restrictions (and potential errors), the detailed virtuosity engraved in Liszt’s score comes in support to Alfred Brendel’s idea of interpreting a musical work:
If I belong to a tradition, it is a tradition that makes the masterpiece tell the performer what to do, and not the performer telling the piece what it should be like, or the composer what he ought to have composed.
Focus on tempo and fermata
This section is for readers conversant with common Western music notation. We illustrate the interpretation of (non-printed) metronome annotations inside measures and fermata (unmeasured prolongations) in a typical example: measure #6 of Liszt’s 14th Hungarian Rhapsody. The source material is the MusicXML code of this measure on which tempo annotations are highlighted in red and fermata in green colour.
This measure is displayed as follows on the printed score. Invisible tempo annotations have been added in red at the exact locations set by the MusicXML score. Three fermata are printed above/below the note or silence they are applied to.
Measure 6 of Liszt’s 14th Hungarian Rhapsody
The symbolic duration of this measure is 6 beats. Due to rounding errors it is displayed by the Bol Processor as 1441/240 = 6.004 beats. This tiny mismatch is caused by a rounding of the durations of 14 notes Ab2 C3 F3 Ab3 C4 F4 Ab4 C5 F5 Ab5 C6 F6 Ab6 C7, a sequence which should last exactly 3/8 beats. Each beat is divided in 480 parts — the division specification at the beginning of the score. Therefore the sequence should last 480 x 3/8 = 180 units and each note should last 180/14 = 12.85 units. Since durations are represented as integers in a MusicXML score, this value has been rounded to 13. This explains the small difference visible in the Bol Processor score, yet unnoticeable to human ears.
The following is the complete Bol Processor transcription of this measure. First, the graphic representation of sound-objects labeled as simple notes:
Measure 6 of Liszt’s 14th Hungarian Rhapsody interpreted as sound-objects by the Bol Processor
Note that all sound-objects in the first 2.5 seconds are duplicated. The MusicXML score is redundant, fortunately with no inconsistency between duplicate occurrences, which explains why they are not visible on the printed score.
The same polymetric expression is available in piano roll format:
Measure 6 of Liszt’s 14th Hungarian Rhapsody displayed as piano roll by the Bol Processor
We will further explain how this transcription has been obtained.
On the Data window the 6th measure is represented as a polymetric structure: {duration, field 1, field2, field 3, field4}. After importing the MusicXML score, click button EXPLODE on the right side to show measures as separate items. Since measure numbering starts with 0 on this score, measure #6 is rendered as item #7.
To facilitate reading, each field is on a separate line:
Integers and integer ratios represent rests. For instance, 667/480 in the third field is a rest of 667/480 = 1.38958 beat duration. Dates and durations are handled by the Bol Processor as integer ratios, thereby allowing perfect time accuracy. Ratio 1/2 in the first field may be equivalently interpreted as a 1/2 beat rest or the symbolic duration of expression {1/2,F7}.
Redundancy of the MusicXML score is visible as expressions such as {Ab2,C3}{2,F3} and {F1,C2}{2,F2} appear in two fields (at the same date and speed).
Tempo instructions in red color reflect annotations of the MusicXML score. Each field begins at metronome 80 bpm (beats per minute). Instruction _tempo(13/20) in front of the polymetric structure sets the metronome to 60 x 13/20 = 39 bpm. In the beginning of each field, it is multiplied by 80/39, therefore yielding 60 x 13/20 x 80/39 = 80 bpm as expected. The following statements produce 16 bpm and 52 bpm at their respective locations.
This translation of the MusicXML score as a polymetric structure is not easy to accomplish with respect to metronome annotations. The main problem is that these annotations appear only on the upper line of the score (i.e. the first field of the structure) and should be inserted at the same dates in other fields. For instance, _tempo(4/3) is located at the 4.5th beat, before {1/2,F7} in the first field, consequently before {1/2,Ab6} in the second field. This is easy to compute.
Rest 481/240 (circa 2 beats) appearing in green on the Bol Processor score has been appended after the second field to calibrate its duration to the duration of the measure. This calibration is not mandatory on printed scores nor in MusicXML files: where no note is shown, musicians understand there is an implicit rest which they spontaneously insert to anticipate the synchronization of forthcoming notes in the next measure. Yet a machine should be instructed to do so.
However, _tempo(16/39) located before the Ab2 C3 F3… sequence in the first field falls inside a rest of 1/2 beat duration in the second field. In fact, this rest is coded as a forward instruction because it does not appear on the printed score. To synchronize tempo changes, the _tempo(16/39) statement must be located at the first quarter of this rest. The result is:
1/8 _tempo(16/39) 3/8
Similarly, a forward of 2.5 beats in the fourth field needs to be broken to insert the _tempo(8/27) and _tempo(26/27) statements, which would yield:
1/8 _tempo(16/39) 91/240 _tempo(4/3) 480/240
However, the calibration of the duration of this fourth field demands an additional rest of 1/2 beat, suggesting that 480/240 be replaced with 600/240. An additional gap of 1/240 is required to compensate rounding errors. This yields:
Another issue of measure #6 in Liszt’s 14th Hungarian Rhapsody is the occurrence of three fermata (see printed score). In the same way as metronome markings, fermata are not repeated on each line of the score as they apply to all parts (voices) simultaneously. Therefore durations must be adjusted accordingly to maintain the synchronization in a machine interpretation.
The first fermata (colored in green on the MusicXML score) is on note “F3″ of the first field. Therefore its duration is 2 beats instead of 1. This extension is propagated to subsequent fields at the same date, namely “F3″, “F2″, “F2″.
The second fermata is placed on an eight (quaver) rest appearing on the printed score, whose duration is extended by 1/2 beat. This ends up extending by 1/2 beat rests occurring at the same date in subsequent fields.
To facilitate similar analyses, an option is offered to trace transformations when importing/converting MusicXML scores. The part relevant to measure #6 (item #7) reads as follows:
• Measure #6 part [P1] starts with current period = 0.75s, current tempo = 4/3, default tempo = 4/3 (metronome = 80) mm Measure #6 part P1 field #1 metronome set to 80 at date 0 beat(s) f+ Measure #6 part P1 field #1 note ‘F3’ at date 1 increased by 1 beat(s) as per fermata #1 mm Measure #6 part P1 field #1 metronome set to 16 at date 3 beat(s) mm Measure #6 part P1 field #1 metronome set to 16 at date 25/8 beat(s) mm Measure #6 part P1 field #1 metronome set to 52 at date 1513/480 beat(s) mm Measure #6 part P1 field #1 metronome set to 52 at date 841/240 beat(s) f+ Measure #6 part P1 field #1 note ‘-’ at date 961/240 increased by 1/2 beat(s) as per fermata #2 + measure #6 field #1 : physical time = 7.98s • Rounding part P1 measure 6 field #2, neglecting ‘backup’ rest = 1/240 mm Measure #6 part P1 field #2 metronome set to 80 at date 0 beat(s) f+ Measure #6 part P1 field #2 note ‘F3’ at date 1 increased by 1 beat(s) to insert fermata #1 mm Measure #6 part P1 field #2 metronome set to 80 at date 1 beat(s) mm Measure #6 part P1 field #2 metronome set to 16 during rest starting date 3 beat(s) mm Measure #6 part P1 field #2 metronome set to 52 at date 7/2 beat(s) + measure #6 field #2 : physical time = 5.08s ➡ Error in measure 6 part P1 field #3, ‘backup’ rest = -1/2 beat(s) (fixed) mm Measure #6 part P1 field #3 metronome set to 80 at date 0 beat(s) f+ Measure #6 part P1 field #3 note ‘F2’ at date 1 increased by 1 beat(s) to insert fermata #1 mm Measure #6 part P1 field #3 metronome set to 80 at date 1 beat(s) mm Measure #6 part P1 field #3 metronome set to 16 at date 25/8 beat(s) mm Measure #6 part P1 field #3 metronome set to 16 at date 1513/480 beat(s) f+ Measure #6 part P1 field #3 silence at date 961/240 increased by 1/2 to insert fermata #2 mm Measure #6 part P1 field #3 metronome set to 52 during rest starting date 841/240 beat(s) + measure #6 field #3 : physical time = 9.28s • Rounding part P1 measure 6 field #4, neglecting ‘backup’ rest = 1/240 mm Measure #6 part P1 field #4 metronome set to 80 at date 0 beat(s) f+ Measure #6 part P1 field #4 note ‘F2’ at date 1 increased by 1 beat(s) to insert fermata #1 f+ Measure #6 part P1 field #4 silence at date 961/240 increased by 1/2 to insert fermata #2 mm Measure #6 part P1 field #4 metronome set to 16 during rest starting date 3 beat(s) mm Measure #6 part P1 field #4 metronome set to 52 during rest starting date 3 beat(s) +rest Measure #6 part P1 field #2 added rest = 481/240 beat(s) +rest Measure #6 part P1 field #4 added rest = 1/240 beat(s) + measure #6 field #4 : physical time = 7.77s ➡ Measure #6 part [P1] physical time = 9.28s, average metronome = 49, final metronome = 39
Changing tempo
There are several methods for changing the tempo of imported MusicXML scores. After the conversion it is obviously possible to edit _tempo(x) instructions individually. Clicking the EXPLODE button makes it possible to modify, and check visually/auditively each measure separately.
Inserting a _tempo(x) instruction in front of the musical work changes the average metronome value. The effect is identical to changing the metronome in the settings file (which we did for Oscar Peterson’s work). For instance, the following Bol Processor score would perform Liszt’s 14th Hungarian Rhapsody at half speed:
// MusicXML file ‘Hungarian_Rhapsody_No._14.musicxml’ converted // Score part ‘P1’: instrument = Piano — MIDI channel 1 -se.Hungarian_Rhapsody
Beginning of Liszt’s 14th Hungarian Rhapsody at half speed
Despite Bol Processor’s systematic treatment of symbolic time as integer ratios, a floating-point argument x is acceptable in a _tempo(x) instruction. For instance, _tempo(1.68) will automatically be converted to _tempo(168/100) and simplified to _tempo(42/25).
A sophisticated adjustment of tempo is possible at the time of importing the MusicXML score.
Current average, minimum and maximum values of metronome are displayed. Boxes in yellow color contain the replacement values, e.g. set average to 60 bpm, minimum to 10 bpm and maximum to 180 bpm.
All metronome values are changed using a quadratic regression of the mapping of values. A linear regression may be used in replacement of the polynomial form in case it is not monotonous. For this example (14th Hungarian Rhapsody) the new average would be 63 bpm instead of the expected 60 bpm. The mismatch depends on the statistical distribution of values.
Changing volume or velocity
An option is given at the time of converting a MusicXML score to interpret sound dynamics as volume or velocity controls. The latter may be preferable for sound synthesis imitating plucked or struck stringed instruments.
Regardless of the choice, volume and velocity controls can later be adjusted for the entire musical work. Click for instance Modify _vel() at the bottom of the Data page.
This will display a form indicating current average, minimum and maximum values of _vel(x) statements in the score. Enter the desired values in yellow boxes and click APPLY.
The mapping uses a quadratic regression (if monotonous) as explained with respect to tempo (see above). For the same reason, reached averages are generally not exactly the desired ones.
Ornamentation
Western musical scores may contain many sorts of ornaments with names and interpretation styles depending on historical periods. The MusicXML format enlists a few of them which may create sound effects similar to the ones of human interprets.
The following ones are transcribed to Bol Processor scores when importing MusicXML files. The accuracy of these interpretations is not a big deal because the main object is to import musical fragments that will be transformed and reused in different contexts. Still, it is fun to design a good interpretation… Before importing a MusicXML, options are given to discard any of the following types of ornaments. The option is displayed only if at least one occurrence has been found in the file.
Mordents
There is a wide variety of mordents with meanings that have changed over the years. The interpretation in Bol Processor is close to musical practice in the 19th century, nonetheless acceptable for the interpretation of Baroque works.
The MusicXML tags for mordents are mordent and inverted-mordent which correspond to the more comprehensible terms of lower mordent and upper mordent respectively. We will illustrate their use in François Couperin’s work Les Ombres Errantes (1730), using a MusicXML file arranged by Vinckenbosch from the MuseScore community. Let us look and listen to the first three measures:
Beginning of François Couperin’s Les Ombres Errantes (MuseScore) ➡ read full score (Creative Commons licence CC0 1.0 Universal)
Beginning of François Couperin’s “Les Ombres Errantes” interpreted by Bol Processor + Csound with a “Rameau en sib” temperament
Eight mordents are found in the first three measures of Les Ombres Errantes. The ones numbered 1, 2, 3, 7 and 8 are of the upper type. Mordents #4, #5 and #6 are of the lower type. In addition, the signs of all upper mordents are longer than standard, which makes them long. Their MusicXML tag is therefore <inverted-mordent long=“yes”/>.
Every mordent is interpreted as a string of notes on a rhythmic pattern that may be short or long. For instance, note B4 (the first long upper mordent) is interpreted as:
{1/4,C5 B4 C5}{3/4,B4}
which indicates that it has been embellished by a short step down from the next upper note C5. The fourth mordent is of the short lower type on note C5, which yields:
{1/8,C5 B4}{7/8,C5}
The full list of mordents in these three measures is:
{1/4,C5 B4 C5}{3/4,B4}
{1/4,Eb5 D5 Eb5}{3/4,D5}
{1/4,C5 B4 C5}{3/4,B4}
{1/8,C5 B4}{7/8,C5}
{1/8,Eb4 D4}{7/8,Eb4}
{1/8,Eb4 D4}{7/8,Eb4}
{1/4,C4 B3 C4}{3/4,B3}
{1/4,C4 B3 C4}{3/4,B3}
While creating rhythmic patterns of mordents is quite easy, a difficulty lies in choosing the note above or below at a tonal distance of 1 or 2 semitones to the final note. By default, the choice is a note that belongs to the diatonic scale which may be modified by alterations earlier in the measure. An option of interpreting mordents, turns and trills as “chromatic” is offered, see below.
With two flats in the key signature, i.e. Bb and Eb, the global diatonic scale of this piece reads as B flat major (or G minor) scale = “C D Eb F G D Bb”. However, in the second measure, Bb is altered to B by a natural sign. Therefore, in the following mordent #4, note B4 must be used in replacement of Bb4 as the lower note leading to C5.
Mordents sound acceptable in this interpretation, as may be checked in the full recording:
François Couperin’s “Les Ombres Errantes” (1730) interpreted by Bol Processor and Csound with “Rameau en sib” meantone temperament (1726). ➡ More tunings on page Comparing temperaments
Turns
A turn is similar to a mordent except that it picks up both the next upper and lower notes in the scale. If associated with a mordent, it can borrow its attributes (see above): upper/lower and long/short. If the turn is not associated with a mordent, the machine will use the long + upper attributes. (This is a design option that may be revised or rendered optional.)
A specific attribute of turns is beats, akin to trill-beats (see below). These are defined (read source) as “The number of distinct notes during playback, counting the starting note but not the two-note turn. It is 4 if not specified.”
Examples of turns are found in François Couperin’s Les Ombres Errantes. They are all four–beat long and imbedded in long/upper mordents, yielding for instance for note Ab3 in measure #12:
{1, Ab3 {2, A3 Ab3 G3} Ab3}
The complete measure #12 (with the turn highlighted) is:
Note that the result would be unchanged with turns interpreted as “chromatic” in this piece: this option picks up the next upper and lower notes in the chromatic scale underlying the tuning of the piece — see image of the Rameau en sib meantone temperament.
Turns not associated with mordents are found in François Couperin’s Le Petit Rien:
François Couperin’s “Le Petit Rien” (1722) with a “Rameau en do” temperament Source: MusicXML score by Yvan43
Trills
Trills are marked with the trill-mark tag. There is an option to ignore it when the detailed sequences of notes are already encoded in the MusicXML file. (This is not easy to guess!) Let us see the construction of trills when the option is not checked.
The treatment of trills is similar to that of mordents (see above). There are many ways of interpreting a trill, depending on style and personal choice of the interpreter. By default, in Bol Processor trills start with the reference note and end up with the altered note which is one step higher in the scale. However, if the start note has a tie, the sequence of notes is reversed so that the stream ends up with the tied note.
Among available options of the trill-mark tag, we pick up trill-beats (read documentation) the value of which is “3” by default. Its definition is a bit obscure: “The number of distinct notes during playback, counting the starting note but not the two-note turn. It is 3 if not specified.” Our temporary interpretation is that the total number of jumps is trill-beats + 1.
Examples of the two types in Listz’s 14th Hungarian Rhapsody:
Arpeggios are also converted to polymetric structures. The following is a chord {F1,C2,F3} of duration 1/2 beat followed by its interpretation as an arpeggio:
The piano roll of this sequence makes it clear. The chord has been broken into two parts. The duration of the first part is determined by a minimum value of the delay between each arpeggio note and the following one, here set to 1/20 beat. The total duration is not allowed to exceed half of the duration of the chord.
Notes are tied (symbol ‘&’) so that their durations are merged, as expected, between the arpeggio part and the pure chord part: for instance, “F1&” is tied to “&F1″ — read page Tied notes for details.
Slurs
Slurs are translated as _legato(x) statements on the Bol Processor score, in which “x” is the percentage by which note durations are increased. This option is set by default with x = 20% and can be unset before importing the MusicXML file.
Slurs on the first notes of François Couperin’s “Les Ombres Errantes”
Notes elicit for elongations are the ones linked with slurs on the score: C5 , Eb5 and C5. Other notes, even the sequence {1/2,Eb4}{5/2,G4 D4 F4 C4 Eb4},Eb4 D4 C4}}, are not modified because they do not appear at the same level of the polymetric structure.
With staccato or spiccato, the duration is reduced by half. For instance, C4 is replaced with {1, C3 -}.
With staccatissimo, the duration is reduced by three quarters. For instance, C4 is replaced with {1, C3 ---}.
Pedals
Pedal commands are captured from the MusicXML file and may be interpreted as MIDI controller commands. (These will be ignored when producing a Csound output.)
A setting of the controller is suggested for each part of the score in which a pedal command has been found. By default, controller #64 is used along with the MIDI channel assigned to the part. Performance controls _switchon() and _switchoff() are used as per Bol Processor syntax.
Below are the setting for pedals, trills etc. and the extra duration of the last measure for a piece with pedals in a single part:
For instance, the first three measures of Listz’s La Campanella are interpreted as follows:
Breath of 1/4 quarter note in measure #3 of “Les Ombres Errantes”
Breath marks are “grace rests” analogous to the commas in written languages. On the Bol Processor they are optionally interpreted as short silences, the duration of which is a fraction of a quarter note.
Look at measure #3 of François Couperin’s Les Ombres Errantes (see conventional score above). The image shows the effect of breaths set up at 1/4 quarter note — i.e. one eighteenth.
Breaths can be tagged in the Bol Processor score with an arbitrary sequence of symbols. For instance, in measure #3 of Les Ombres Errantes”, breaths are tagged by [🌱] which actually contains a Unicode character 🌱 compatible with BP syntax. Note that the breaths after D4 and B3 are 1/4 beat because these beats are quarters, whereas the one after F4 is 1/2 beat because every beat is an eighth.
When importing this piece, we set up silences of 1/6 quarter note as these sounded more acceptable. In addition, a randomisation of timings by 20 ms was applied (read below).
Previewing the ornamentation and setting up options
Previewing the ornamentation and setting up options before importing a MusicXML file
Before importing a MusicXML file, options are displayed to select or ignore ornaments which have been detected in the file. Here, for instance, mordents and turns. Selecting an option implies that it has only be described as a graphic sign on the printed score; therefore, we expect the algorithm to construct the sequences of notes as per rules shown above. If the ornament has been imbedded as a sequence of notes in the file, it is necessary to ignore its statement.
This decision may be difficult to take as it requires analysing the MusicXML code. To this effect, buttons open windows that display exclusively the measures in which the selected ornament occurs. The code of the ornament is displayed in green colour and preceded with a red arrow.
Mordents, turns and trills also have the option of being interpreted as chromatic. See their check boxes on the picture.
Another button (on top of the window) displays the entire MusicXML code on a pop-up window with coloured lines for measures and notes.
Several “trace” options are available. With a long file it may not be easy to trace the entire process. Therefore it is possible to focus on a range of measures. Other restricted options are the management of tempo and of ornamentation.
Measure numbers
An option (see above picture) allows to display measure numbers on the imported score as shown below:
These become more visible after clicking the EXPLODE button fragmenting the score to one item per measure. Measure numbers (appearing on the printed score) do not always match item numbers on the exploded view.
If the score contains several parts, their labels are also optionally displayed in the resulting score, as this facilitates matching BP score with the printed one. For instance:
Many performance controls can be applied to the imported score to change its global tempo, dynamics etc. Among these are the “random” operators “_rndvel(x)” and “_rndtime(x)”.
The first one modifies velocities by a random value between 0 and x, with x < 64. It may be placed at the beginning of a sequence of notes and followed with “_rdnvel(0)” once this randomisation is no longer wanted. If it is placed before a polymetric structure it will apply to all notes in the structure.
Performance control “_rndtime(x)” obeys to the same syntax. Its effect is a random displacement of each note by ± x milliseconds.
Randomisation is not meant to be used for “humanizing” digital music, but rather to compensate unwanted effects when several digitally synthesized sounds are superposed. This is the case, for instance, with attacks of notes in an synthesizer imitating plucked-string instruments. The simultaneous attack of several notes (in a chord) may sound very harsh. Generally, putting a “_rndtime(20)” instruction in the beginning of the piece will solve the problem. However, the musical score may be made of several parts involving instruments that benefit from different randomisations; therefore, several instructions need to be placed in from of each part (one per measure). To avoid this editorial work, an option is given to insert “_rndtime(x)” with the proper values of x on each part/instrument.
Compare the beginning of Les Ombres Errantes without, then with, a time randomisation of 20 milliseconds — i. e. much less than what would be perceived as a “wrong timing”. To reach the proper effect, the time resolution of Bol Processor must be significantly less than 20 ms. Here it is set to 1 ms, which means that timing offsets may randomly pick up 40 distinct values within the ± 20 ms interval.
Non-randomized beginning of “Les Ombres Errantes”20 millisecond randomized beginning of “Les Ombres Errantes”
Let us compare the sizes of files able to deliver the same interpretation of 14th Hungarian Rhapsody:
Sound file in AIFF 16-bit 48 Khz produced by PianoTeq = 200 MB
MusicXML file = 3.9 MB
Graphic + audio score produced by MuseScore = 141 KB
Graphic score exported as PDF by MuseScore = 895 KB
Csound score produced by Bol Processor = 582 KB
MIDI file produced by Bol Processor = 75 KB
Bol Processor data = 64 KB
This comparison supports the idea that Bol Processor data is arguably the most compact and altogether comprehensive (text) format for representing digital music. Below is the full data of this musical work (with measure numbers):
// MusicXML file ‘Hungarian_Rhapsody_No._14.musicxml’ converted // Reading metronome markers // Including slurs = _legato(20) // Including trills // Including fermata // Including mordents // Including arpeggios
Velocities have been remapped to average 78 and maximum 110.
Take-away
The interpretation of complex musical works packaged in digitised musical scores highlights important features of the Bol Processor model:
Every musical work eligible for digitisation can be accurately described as a single polymetric expression;
The timings of polymetric expressions are symbolic, here meaning human-comprehensible integers (or integer ratios) counting beats rather than milliseconds;
The simple syntax of polymetric expressions make them amenable to reuse and transformations by human editors (or formal grammars);
Limits of this modelling are merely “physical”: memory size and computation time;
Time accuracy (typically 10 ms) is not affected by the size of data.
Return to humanity
Examples will hopefully convince readers that the Bol Processor format is able to emulate scores in common Western music notation, and even fix some irregularities in their timings… Let us admit a long way from its initial dedication to the beautiful poetry created by drum players in India!
These are indeed interpretations of musical scores. In order to remember the additional value created by human artists playing real instruments, we may end up listening to the same Beethoven’s Fugue played by Alban Berg Quartett:
A framework for tuning just-intonation scales via two series of fifths
For more than twenty centuries, musicians, instrument makers and musicologists figured out scale models and tuning procedures for the creation of tonal music embodying the concept of “consonance”.
This does not mean that every style of tonal music aims at achieving consonance. This concept is mainly explicit in the design and performance of North Indian raga and Western harmonic music.
There was a shared notion of the octave and the major fifth (interval “C” to “G”) being the building blocks of these models, and the harmonic major third (interval “C” to “E”) lately played a significant role in European music.
Computer-controlled electronic instruments open new avenues for the implementation of microtonality including just intonation frameworks dividing the octave in more than 12 grades — read page Microtonality. Throughout centuries, Indian art music claimed its adherence to a division of 22 intervals (the ṣruti-swara system) theorized in the Nāṭyaśāstra, a Sanskrit treatise dating back between 400 BCE and 200 CE. Since consonance (saṃvādī) is the basis of both ancient Indian and European tonal systems, we felt the urge for a theoretical framework encompassing both models.
Unfortunately, the topic of “just intonation” is exposed in an altogether confusing and reductive manner (read Wikipedia) due to musicologists focusing on integer ratios reflecting the distribution of higher partials in periodical sounds. While these speculative models of intonation may substantiate beliefs in the magical properties of natural numbers — as claimed by Pythagoreanists — they have rarely been checked against non-directed musical practice. Instrument tuners rely on their own auditory perception of intervals rather than resorting to numbers, despite the availability of “electronic tuners”…
Earlier interpretations of this model, mimicking the Western habit of dealing with intervals as frequency ratios, failed to explain the intervalic structure of ragas in Hindustani classical music. In reality, the implicit model of Nāṭyaśāstra is a “flexible” one because the size of the major third (or equivalently the pramāņa ṣruti) is not stated in advance. Read page Raga intonation and listen to examples to grasp the articulation between the theory and practice of intonation in this context.
In Europe, the harmonic major third was finally accepted as a “celestial interval” after the Council of Trent (1545-1563), thereby putting an end to the banishment of polyphonic singing in religious gatherings. Major chords — such as {C, E, G} — are vital elements of Western harmony, and playing a major chord without unwanted beats requires the simplest frequency ratio (5/4) for the harmonic major third {C, E}.
A 19-key per octave (from “A” to “a”) keyboard designed by Gioseffo Zarlino (1517-1590) (source)
Along with the development of fixed-pitch keyboard instruments, the search for consonant intervals gave way to the elaboration of theoretical models (and tuning procedures) attempting to perform this interval in “pure intonation”. In theory, this is not feasible on a chromatic (12-grade) scale, but it can be figured out and applied to Western harmony if more grades (29 to 41) are permitted. Still, choosing enharmonic positions suitable for a harmonic context remains an uncertain venture.
Once again, the Indian model comes to the rescue because it can be extended to produce a consistent series of twelve “optimally consonant” chromatic scales in compliance with chord intervals in Western harmony. Each scale contains 12 grades, which is more than the notes of chords it is applicable for. Sound examples are provided to illustrate this process — read page Just intonation: a general framework.
Tuning mechanical keyboard instruments (church organ, harpsichord, pianoforte) for 12-grade scales made it necessary to distribute unwanted dissonance (the syntonic comma) in an acceptable manner over series of fifths and fourths. Many tempered tuning procedures were designed, during the 16th to 19th centuries, with emphasis on either “perfect fifths” or “pure major thirds”, in response to the constraints of specific musical repertoires.
These techniques have been documented in detail by organ player and instrument designer Pierre-Yves Asselin, along with methods for achieving the tuning on a mechanical instrument such as the harpsichord. His book Musique et tempérament (Paris: Jobert, 2000, forthcoming in English) served as a guideline for implementing a similar approach in the Bol Processor — read pages Microtonality, Creation of just-intonation scales and Comparing temperaments. This framework should make it possible to listen to Baroque and classical works, using Csound instruments, with the tunings their composers had in mind — according to historical sources.
From left to right: 1st-order descending-third series, “Pythagorean” series and 1st-order ascending-third series (Asselin 2000 p. 61)
As indicated on page Just intonation: a general framework, just-intonation chromatic scales can be derived from a basic framework made of two cycles of perfect fifths (frequency ratio 3/2).
These produce the 22-shruti framework of Indian musicologists (read Raga intonation) or the series named “Pythagorean” and “1st-order ascending-third” (“LA-1”, “MI-1” etc.) in the approach of Western musicologists (see picture on the side).
We found that the “1st-order descending-third cycle” (“LAb+1”, “MIb+1” etc.) in which all notes are higher by a syntonic comma may not be required for the creation of just-intonation chords.
These cycles of fifths are represented graphically (scale “2_cycles_of_fifths” in Csound resource “-cs.tryTunings”):
There are a few differences between this 29-grade division of the octave and the Indian framework, notably the creation of “DO-1” and “FA-1”, two positions lower by one syntonic comma than “DO” (“C” = “Sa” in the Indian convention) and “FA” (“F” = “Ma”). Interestingly, these positions appear in ancient texts under the names “cyuta Sa” and “cyuta Ma”. Other additional positions are “REb-1”, “MIb-1”, “SOLb-1”, “LAb-1” and “SIb-1”.
The rule we follow when producing chromatic scales via transpositions of Ma-grama is that only positions displayed on this graph should be considered valid. When exporting a minor or major chromatic scale from a transposition of Ma-grama, it may occur that a note position is not part of this framework. In all cases of this procedure, the invalid position is one syntonic comma too low. Therefore the exported scale will be “aligned” raising all its positions by one comma.
The term “Pythagorean series” is confusing because any cycle of perfect fifths is Pythagorean by definition. Whether a position in a scale “is” or “is not” Pythagorean depends on the starting note of the series that was announced as “Pythagorean”. In Asselin’s work the starting point of the series in the central column is “FA”. In the Indian system, basic frameworks (Ma-grama and Sa-grama) start from “Sa” (“C” or “do”) and the Pythagorean/harmonic status of a position is determined by factors of its frequency ratio with respect to “Sa”. If a factor “5” is found in the numerator or the denominator, the position is harmonic, or Pythagorean in the reverse case.
Thus, for instance, “DO#” in Asselin’s “Pythagorean” series (two perfect fifths above “SI”) is evaluated as a harmonic position (marked in green) on the Bol Processor graphic and its ratio is 16/15. In reality, “DO#” in Asselin’s series has a frequency ratio 243/128 * 9/16 = 2187/1024 = 1.068 which is very close to 16/15 = 1.067. “DO#-1” in Asselin’s series is two perfect fifths above “SI-1” which yields a frequency ratio 15/8 * 9/16 = 135/128 = 1.054 which is close to 256/243 = 1.053 and marked “Pythagorean” on the Indian scheme. Thus, “DO#” and “DO#-1” have exchanged their properties because each of them is the superposition of two very close positions belonging to different series.
Ignoring schisma differences to take the simplest ratios create this confusion. Therefore, we keep preferring comma indications — e.g. “FA” and “FA-1” — to identify positions, in which the first instance belongs to the series termed “Pythagorean” in Asselin’s work.
Transposition table
This table summarizes a quick procedure for creating all murcchana-s of the Ma-grama chromatic scale and export minor and major chromatic scales therefrom.
Open the “Ma_grama” scale in the “-cs.12_scales” Csound resource and select the Murcchana procedure. To create “Ma01″, move note “F” to note “C” and click TRANSPOSITION.
F moved to
Murcchana
Minor scale
Raise
Major scale
Identical scale
Adjust
C
Ma01
Amin
D
Cmaj
=
Emin
1/1
F
Ma02
Dmin
G
Fmaj
=
Amin
1/1
Bb
Ma03
Gmin
C
Bbmaj
=
Dmin
1/1
Eb
Ma04
Cmin
F
Ebmaj
=
Gmin
1/1
Ab
Ma05
Fmin
Bb
Abmaj
=
Cmin
1/1
Db
Ma06
Bbmin
Eb
Dbmaj
=
Fmin
1/1
F#
Ma07
Ebmin
Ab
F#maj
=
Bbmin
1/1
B
Ma08
Abmin
Db
Bmaj
=
Ebmin
1/1
E
Ma09
Dbmin
F#
Emaj
=
Abmin
1/1
A
Ma10
F#min
B
Amaj
=
Dbmin
81/80
R3
Ma11
Bmin
E
Dmaj
=
F#min
81/80
G3
Ma12
Emin
A
Gmaj
=
Bmin
81/80
For example, this is the “Ma04″ murcchana obtained by placing “F” (M1 on the Indian scale model) of the moveable wheel on “Eb” (G1 of the outer crown):
The resulting scale “Ma04″ is:
The “Ma04” scale produced as a transposition of the “Ma-grama” chromatic scale
Scale adjustment
In the last column of the table, “Adjust” indicates the fraction by which the ratios of notes may need to be multiplied so that no position is created outside the Pythagorean and harmonic cycles of fifths according to the Indian system. Practically this is the case when the frequency ratio contains a multiple of 25 in either its numerator or denominator, as this indicates that the position has been constructed by at least two successive major thirds (up or down).
A warning is displayed when this is the case, and a sinple click on ADJUST SCALE fixes positions:
In this example, the warning signals an out-of-range position of “B” (50/27) on the “Ma10″ scale. Also note that “F#” has a multiple of 25 in its numerator.
After clicking ADJUST SCALE, the “Ma10″ scale is finalized with “B” at position 15/8. This has been done by raising all notes by a syntonic comma (81/80) :
This procedure is mentioned in Indian musicology under the name of sadja-sadharana telling that all notes of the scale are raised by one shruti — here, a syntonic comma (Shringy & Sharma 1978). In this model, it is also invoked for scales “Ma11″ and “Ma12″. The result is (as expected) a circular model because “Ma13″ is identical to “Ma01″ as shown by the scale comparator at the bottom of page “-cs.12_scales”.
This circularity is a property of the set of murcchana-s which has no influence on exported minor and major scales because their positions will be aligned in compliance with the basic rule exposed in the first section.
Exporting and aligning minor scales
The “Ma04″ murcchana produces “Cmin” by exporting notes facing marks on the inner wheel.
The “Cmin” chromatic scale exported from the “Ma04” transposition
As explained on page Just intonation: a general framework, the tonic and dominant notes of every minor chord should belong to the “minus-1” position. In this example, “C” and “G” are one comma lower in a “C minor” chord than in a “C major” chord (matching “DO-1” and “SOL-1” on the “2_cycles_of_fifths” scale) , a fact which had been predicted and experimentally checked by Pierre-Yves Asselin (2000 p. 137).
All chromatic minor scales exported from murchana-s of Ma-grama are correctly positioned with respect of enharmonic positions of main notes in just-intonation chords. This can easily be checked comparing ratios with the ones associated with the Western series on “2_cycles_of_fifths” (top of this page). This confirms that a tuning system using only two series of perfect fifths is convenient for the construction of a just-intonation framework.
Exporting and aligning major scales
The “Ma04″ murcchana produces “Ebmaj” by exporting notes facing marks on the inner wheel and raising “F”:
The “Ebmaj” chromatic scale exported from the “Ma04” transposition
According to a rule exposed on page Just intonation: a general framework, the basic note of every major chord should be both in the high position and in the Pythagorean series (blue markings). This is true of “Eb major” chord extracted from the “Ebmaj” chromatic scale, yet not with scales “F#maj”, “Bmaj” and “Emaj” displayed in bold style on the table.
Let us for instance look at “Emaj” exported without precaution from “Ma09″:
Scale “Emaj” exported from “Ma09”, before its alignment
Note “E” has a frequency ratio 5/4 which is labeled “MI-1” on scale “2_cycles_of_fifths” (top of this page). Since “MI-1” belongs to a harmonic series, it cannot be taken as a the tonic of a “E major chord”. The Pythagorean “MI” (ratio 81/64) should be used instead.
After its alignment — raising all notes by 1 syntonic comma — the final “Emaj” scale is obtained:
Scale “Emaj” exported from “Ma09”, after its alignment
This alignment of exported major scales is done automatically by the Bol Processor when exporting a major chromatic scale.
References
Asselin, P.-Y. Musique et tempérament. Paris, 1985, republished in 2000: Jobert. Soon available in English.
Tanpura: the drone of Indian musicians — manufactured in Miraj (read paper)
This article demonstrates the theoretical and practical construction of microtonal scales for the intonation of North Indian ragas, using tools available with Bol Processor (BP3) + Csound.
This exercise on raga intonation demonstrates the ability of BP3 to deal with sophisticated models of micro-intonation and support a fruitful creation of music embodied by these models.
Theory versus practice
To summarize the background, the framework for constructing “just-intonation” scales is a deciphering of the first six chapters of Nāṭyaśāstra, a Sanskrit treatise on music, dance and drama dating back to a period between 400 BCE and 200 CE. For convenience we call it “Bharata’s model” although there is no historical record of a single author bearing this name.
Using exclusive information driven from the text and its description of the Two-vina experiment provides an infinite set of valid interpretations of the ancient theory as shown in A Mathematical Discussion of the Ancient Theory of Scales according to Natyashastra (Bel 1988). Among these, the one advocated by many musicologists — influenced by Western acoustics and scale theories — states that the frequency ratio of the harmonic major third would be 5/4. This is equivalent to fixing the frequency ratio of the syntonic comma to 81/80.
Even though this interpretation yields a consistent model for just-intonation harmony — read Just intonation, a general framework — it would be far-fetched to stipulate that the same holds for raga intonation. Accurate measurements of raga performance using our Melodic Movement Analyzer (MMA) in the early 1980s revealed that melodic structures inferred from statistics (using selective tonagrams, read below) often differ significantly from scales predicted by the “just-intonation” interpretation of Bharata’s model. Part of the explanation may be the strong harmonic attraction effect of drones (tanpura) played in the background of performances of raga.
Talking about grama-s (scale frameworks) in the ancient Indian theory, E.J. Arnold wrote (1982 p. 40):
Strictly speaking the gramas belong to that aspect of nada (vibration) which is anahata (“unstruck”). That means to say that the “grama” can never be heard as a musical scale [as we did on page Just intonation, a general framework]. What can be heard as a musical scale is not the grama, but any of its murcchanas.
As soon as electronic devices such as the Shruti Harmonium (1979) and the Melodic Movement Analyzer (1981) became available, the challenge of research on raga intonation was to reconcile two methodologies: a top-down approach checking hypothetical models against data, and a data-driven bottom-up approach.
The “microscopic” observation of melodic lines (now rendered easy by software like Praat) confirmed the importance of note treatment (ornamentation, alankara) and time-driven dimensions of raga which are not taken into account by scale theories. For instance, long discussions have been held on the rendering of note “Ga” in raga Darbari Kanada (Bel & Bor 1984; van der Meer 2019) and typical treatment of notes in other ragas (e.g. Rao & Van der Meer 2009; 2010). The visual transcription of a phrase of raga Asha makes it evident:
A brief phrase of raga Asha transcribed by the MMA and in Western conventional notation
Non-selective tonagram of raga Sindhura sung by Ms. Bhupender Seetal
In order to extract scale information from this melodic continuum, a statistical model was implemented to display the distribution of pitch across one octave. The image shows the tonagram of a 2-minute sketch (chalana) of raga Sindhura taught by Pandit Dilip Chandra Vedi.
The same recording of Sindhura on a selective tonagram
The same melodic data was processed again after a filtering of 3 windows attempting to isolate “stable” parts of the line. The first window, typically 0.1 seconds, would eliminate irregular segments, the second one (0.4 s.) would discard segments outside a rectangle of 80 cents in height, and the third one was used for averaging. The outcome is a “skeleton” of the tonal scale displayed as a selective tonagram.
These results often would not match scale metrics predicted by the “just-intonation” interpretation of Bharata’s model. Proceeding further in this data-driven approach, we produced the (non-selective) tonagrams of 30 ragas (again chalana-s) to compute a classification based on their tonal material. Dissimilarities between pairs of graphs (calculated with Kuiper’s algorithm) were approximated as distances, from which a 3-dimensional classical scaling was extracted:
A map of 30 North-Indian ragas constructed by comparing tonagrams of 2-minute sketches (chalana-s) of sung performances (Bel 1988b)
This experiment suggests that contemporary North-Indian ragas are amenable to meaningful automatic classification on the sole basis of their (time-independent) intervalic content. This approach is analogous to techniques of human face recognition able to identify related images with the aid of limited sets of features.
Setup of Bel’s Melodic Movement Analyzer MMA2 (black front panel) on top of Fundamental Pitch Extractor at the National Centre for the Performing Arts (Mumbai) in 1983
This impressive classification has been obtained via statistical analyses of static representations of raga performance. This means that the same result would be achieved after playing the sound file in reverse direction, or even slicing it to segments reassembled in a random order… Music is a dynamic phenomenon that cannot be reduced to tonal “intervals”. Therefore, subsequent research in the representation of melodic lines of raga — once it could be efficiently processed by 100% digital computing — led to the concept of Music in Motion, i.e. synchronising graphs with sounds so that visuals reflect the music as it is being heard, arguably the only suitable “notation” for raga (Van der Meer & Rao 2010; Van der Meer 2020).
This graph model is probably a great achievement as an educational and documentary tool, indeed the environment I was dreaming of when designing the Melodic Movement Analyzer. However, promoting it as a theoretical model is the continuation of a Western selective bias. To the amount of my knowledge, no Indian music master ever attempted to describe the intricacies of raga via hand-drawn melograms, although they could. The fascination of technology — and Western ‘science’ at large — is not an indication of its relevance to ancient Indian concepts.
Music is appreciated by ears; therefore, a theory of music should be evaluated on its ability to produce musical sounds via predictive model(s). Numbers, charts and graphics are mere tools for the interpretation and anticipation of sound phenomena. This approach is termed analysis by synthesis in Daniel Hirst’s book on speech prosody (Hirst, 2022, forthcoming, p. 137):
Analysis by synthesis involves trying to set up an explicit predictive model to account for the data which we wish to describe. A model, in this sense, is a system which can be used for analysis — that is deriving a (simple) abstract underlying representation from the (complicated) raw acoustic data. A model which can do this is explicit but it is not necessarily predictive and empirically testable. To meet these additional criteria, the model must also be reversible, that is it must be possible to use the model to synthesise observable data from the underlying representation.
This is the raison d’être of the following investigation.
Microtonal framework
The “flexible” model derived from the theoretical model of Natya Shastra (read The Two-vina experiment) discards the assertion of a precise frequency ratio for the harmonic major third classified as anuvadi (asonant) in ancient literature. This amounts to admitting that the syntonic comma (pramāņa ṣruti in Sanskrit) might take any value between 0 and 56.8 cents.
Let us look at graphic representations (by the Bol Processor) to illustrate these points.
The basic framework of musical scales, according to Indian musicology, is a set of 22 tonal positions in the octave named shruti-s in ancient texts. Below is the framework displayed by Bol Processor (microtonal scale “grama”) with a 81/80 syntonic comma. The names of positions “r1_”, “r2_” etc follow the constraints of lowercase initials and appending a underline character to distinguish octave numbers. Positions “r1” and “r2” are two options for locating komal Re (“Db” or “re bemol”) whereas “r3” and “r4” designate shuddha Re (“D” or “re”) etc.
The “grama” scale displaying 22 shruti-s according to the model of Natya Shastra, with a 81/80 syntonic comma
The 22 shruti-s can be listened to on page Just intonation, a general framework, keeping in mind (read above) that this is a framework and not a scale. No musician would ever attempt to play or sing these positions as “notes”!
What happens if the value of the syntonic comma is modified? Below is the same framework with a comma of 0 cent. In this case, any “harmonic position” — one whose fraction contained a multiple of 5 — slides to its nearest Pythagorean neighbour (only multiples of 3 and 2). The result is a “Pythagorean tuning”. On top of the circle the remaining gap is a Pythagorean comma. Positions are slightly blurred because of mismatches linked with a very small interval (the schisma).
The “grama scale” of 22 shruti-s with a syntonic comma of 0 cent.
The following is the framework with a syntonic comma of 56.8 cents (its upper limit):
The “grama scale” of 22 shruti-s with a syntonic comma of 56.8 cents.
In this representation, “harmonic major thirds” of 351 cents would most likely sound “out of tune” because the 5/4 ratio yields 384 cents. In fact, “g2” and “g3” are both distant by a quartertone between Pythagorean “g1” (32/27) and Pythagorean “g4” (81/64). Nonetheless, the internal consistency of this framework (counting perfect fifths in blue) makes it still eligible for the construction of musical scales.
Between these limits of 0 and 56.8 cents, the graphic representation of scales and their internal tonal structure remain unchanged if we keep in mind that the size of major-third intervals is decided by the syntonic comma.
Construction of scale types
Manuscript of the description of Zarlino’s “natural” scale
The model extracted from Bharata’s Natya Shastra is not an evident reference for prescribing raga intonation because this musical genre started its existence a few centuries later.
Most of the background knowledge required for the following presentation is borrowed from Bose (1960) and my late colleague E. James Arnold who published A Mathematical model of the Shruti-Swara-Grama-Murcchana-Jati System (Journal of the Sangit Natak Akademi, New Delhi 1982). Arnold studied Indian music in Banaras and Delhi during the 1970s and the early 1980s.
Bose was convinced (1960 p. 211) that the scale named Kaishika Madhyama is equivalent to a “just-intonation” seven-grade scale of Western musicology. In other words, he took for granted that the 5/4 frequency ratio (harmonic major third) should be equivalent to the 7-shruti interval, but this statement had no influence on the rest of his analysis.
Arnold (right) and Bel (left) demonstrating shruti-s at the international East-West music conference, Bombay 1983
Arnold (1982 p. 17) immediately used integer ratios to design intervals with the fixed syntonic comma (81/80), but as suggested above this has no impact on his model with respect to its structural description. He insisted on setting up a “geometrical model” rather than a speculative description based on numbers as many authors (e.g. Alain Daniélou) had attempted it. The most innovative aspect of Arnold’s study has been the use a circular sliding model to illustrate the matchings of intervals in transposition processes (murcchana-s) — read page The Two-vina experiment.
Indeed it would be more convenient to keep expressing all intervals in numbers of shruti-s in compliance with the ancient Indian theory, but a machine needs metrical data to draw graphics of scales. For this reason we show graphs using a 81/80 syntonic comma, keeping in mind the option of modifying this value at a later stage.
Sa-grama and Ma-grama according to Natya Shastra. Red and green segments indicate perfect-fifth consonance. Underlined note names indicate ‘flat’ positions.
The 22-shruti framework offers the possibility of constructing 211 = 2048 chromatic scales, among which only 12 are “optimally consonant”, i.e. containing only one wolf major fifth (smaller by 1 syntonic comma = 22 cents).
The building blocks of the tonal system according to traditional Indian musicology are two seven-grade scales named Ma-grama and Sa-grama. Bose wrote (1960 p. 13): the Shadja Grāma developed from the ancient tetrachord in which the hymns of the Sāma Veda were chanted. Later on another scale, called the Madhyama Grāma, was added to the secular musical system. The two scales (Dorian modes, according to Western terminology) differ by the position of Pa (“G” or “sol”) which may differ by a syntonic comma (pramāņa ṣruti). In the Sa-grama, interval Sa-Pa is a perfect fifth (13 shruti-s) whereas it is a wolf fifth (12 shruti-s) in the Ma-grama. Conversely, interval Pa-Re is a perfect fifth in Ma-grama and a wolf fifth in Sa-grama.
Bharata used the Sa-grama to expose his thought experiment (The Two vinas) aimed at determining the sizes of shruti-s. Then he introduced two additional notes: kakali Nishada (komal Ni or “Bflat”) and antara Gandhara (shuddh Ga or “E”) to get a nine-grade scale from which “optimally consonant” chromatic scales could be derived from modal transpositions (murcchana). The process of building these 12 chromatic scales, namely “Ma01″, “Ma02″… “Sa01″, “Sa20″ etc. is explained on page Just intonation, a general framework.
Selecting notes in each chromatic scale yields 5 to 7-note melodic types. In the Natya Shastra these melodic types were named jāti. These may be seen as ancestors of ragas even though their lineages and structures are only speculated (read on). The termthāṭ (pronounce ‘taat’) translated as “mode” or “parent scale” — has later been adopted, each thāṭ being called by the name of a raga (see Wikipedia). Details of the process, terminology and surveys of subsequent musicological literature will be found in publications by Bose and other scholars.
The construction of the basic scale types is explained by Arnold (1982 p. 37-38). The starting point is the chromatic Ma-grama in its basic position — namely “Sa_murcchana” in the “-cs.12_scales” Csound resource file. This scale can be visualized, using Arnold’s sliding model, by placing the S note of the inner wheel on the S of the outer crown :
The Ma-grama chromatic scale in its basic position named “Sa_murcchana’
This yields the following intervals:
The Ma-grama chromatic scale in its basic position and with notes labeled in English
“Optimal consonance” is illustrated by two features: 1) there is only one wolf fifth (red line) in the scale (between D and G), and 2) every note is connected with another one by a perfect fifth (blue line). This consonance is of prior importance to Indian musicians. Consonant intervals are casually placed in melodic phrases to enhance the “flavor” of their notes, and no wolf fifth should exist in the scale.
Note that the Ma-grama chromatic scale has all its notes in their lower enharmonic position.
The Ma-grama chromatic scale has been renamed “Sa_murcchana” in this occurrence because ‘S’ of the moving wheel is facing ‘S’ of the fixed crown. The names of notes have been (in a single click) converted to the Indian convention. Note that key numbers also have been (automatically) fixed to match exclusively labeled notes. In this way, the upper “sa” is assigned key 72 instead of 83 in the “Ma01″ scale showed on page Just intonation, a general framework. The tonal content of this “Sa_murchana” is exposed on this table:
Tonal content of “Sa_murcchana”
Scale type named “kaphi1”
Selecting only “unaltered” notes in “Sa_murcchana” — sa, re, gak, ma, pa, dha, nik — yields the “kaphi1″ scale type named after raga Kaphi (pronounced ‘kafi’). This may be associated to a D-mode (Dorian) in Western musicology.
This scale type is stored under the name “kaphi1″ because there will be one more version of the Kaphi scale type.
In “Sa_murcchana” the selection of notes can differ in two ways:
Select antara Gandhara (namely “ga”) in replacement of the scale’s Gandhara (namely “gak”), thereby raising it by 2 shruti-s. This yields a vikrit (modified) scale type, namely “khamaj1″ associated with raga Khamaj.
Select both antara Gandhara and kakali Nishada (namely “ni” in replacement of “nik” raised by 2 shruti-s) which creates the “bilaval1″ scale type associated with raga Bilaval.
A scale type named “bilaval3” matching Zarlino’s “natural” scale
This “bilaval1″ scale type is one among three versions of Bilaval created by the murcchana procedure. Although it matches the scale of white keys on a Western keyboard instrument, it is not the common “just intonation” diatonic scale because of a wolf fifth between “sa” and “pa”.
An alternate Bilaval scale type named “bilaval3″ (extracted from “Ni1_murcchana”, see below) does match Giozeffo Zarlino’s “natural” scale — read Just intonation: a general framework. This should not be confused with Zarlino’s meantone temperament discussed on page Microtonality.
An incompletely consonant scale type
A fourth option: raising “nik” to “ni” and keeping “gak”, would produce a scale type in which “ni” does not have any consonant relation with another note of the scale. This option is therefore discarded from the model.
Every murcchana of the Ma-grama chromatic scale produces at least three scale types by selecting unaltered notes, antara Gandhara or both antara Gandhara and kakali Nishada.
Practically, to create for instance “Ni1_murcchana”, open the “Sa_murcchana” page and enter “nik” (i.e. N3) as the note to be placed on “sa”.
Raga scale types are stored in the “-cs.raga” Csound resource file. Images are available in a single click and scale structures are compared on the main page.
The entire process is summarized in the following table (Arnold 1982 p. 38):
Step
Ma-grama chromatic murcchana starting from
Shuddha grama
Vikrit grama (antara)
Vikrit grama (antara + kakali)
1
Sa
kaphi1
khamaj1
bilaval1
2
Ma1
khamaj2
bilaval2
kalyan1
3
Ni1
bilaval3
kalyan2
marva1
4
Ga1
kalyan3
marva2
purvi1
5
Dha1
marva3
purvi2
todi1
6
Re1
purvi3
todi2
7
Ma3
todi3
lalit1 bhairao1
8
Ni3
lalit2 bhairao2 bhairavi1
9
Ga3
todi4 bhairavi2
10
Dha3
bhairavi3
asavari1
11
Re3
bhairavi4
asavari2
kaphi2
12
Pa3
asavari3
kaphi3
khamaj3
Scale types of the extended grama-murcchana series (Arnold 1982)
Usage of this table deserves a graphic demonstration. Let us for instance create scale type “kalyan1″ based on the “Ma1_murcchana”. The table says that both “antara and kakali” should be selected. This means “antara Gandhara” which is “ga” in replacement of “gak” in the Ma-grama scale, and “kakali Nishada” which is “ni” in replacement of “nik” in the Ma-grama scale. This process is clear on the movable wheel model:
Selecting notes to create the “kalyan1” scale type from the “Ma1_murcchana” of chromatic Ma-grama. “M1” is placed on “S”. Then the standard intervals are picked up from the Ma-grama moving wheel, replacing G1 with G3 and N1 with N3 as indicated in the table.
To execute this selection and export the “kalyan1″ scale type, fill the form on page “Ma1_murcchana” as indicated on the picture.
Below is the resulting scale type.
The “kalyan1” scale type
Keep in mind that note positions expressed as integer frequency ratios are just a matter of convenience for readers acquainted with Western musicology. It would be more appropriate to follow the Indian convention of counting intervals in numbers of shruti-s. In this example, the interval between “sa” and “ma” raised from 9 shruti-s (perfect fourth) to 11 shruti-s (tritone).
Arnold’s model is an extension of the murcchana system described in Natya Shastra because it accepts murcchana-s starting from notes which do not belong to the original (7-grade) Ma-grama, taken from its “chromatic version”: Dha1, Re1, Ma3, Ni3, Ga3. This extension is necessary for creating scale types for Todi, Lalit and Bhairao which include augmented seconds.
In his 1982 paper (p. 39-41) Arnold connected his classification of scale types with the traditional list of jāti-s, the “ancestors of ragas” described in Sangita Ratnakara of Śārṅgadeva (Shringy & Sharma, 1978). Seven jāti-s are cited (p. 41), each of them being derived from a murcchana of Ma-grama on one of its shuddha swara-s (basic notes).
Every jāti is assigned a note of tension release (nyasa swara). In contemporary ragas, the nyasa swara is often found at the end of a phrase or a set of phrases. In Arnold’s interpretation, the same should define the murcchana from which the melodic type (jāti) is born. Since, in fact, the names of the shuddha jatis are tied to their nyasa swaras, this too suggests that they should be tied to the murcchanas belonging from those nyasa swaras (Arnold 1982 p. 40).
Performance times associated with murcchana-s of the Ma-grama, according to Arnold (1985)
In other publications (notably Arnold & Bel 1985), Arnold used the cycle of 12 chromatic scales to suggest that enharmonic positions of the notes might express tensions or release states bound to the changing ambience of the circadian cycle, thereby providing an explanation of performance times assigned to traditional ragas. Low enharmonic positions would be associated with darkness and higher ones with day light. In this way, ragas constructed with the aid of the Sa murcchana of Ma-grama chromatic scale (all low positions, step 1) might be interpreted near midnight whereas the ones mixing low and high positions (step 7) would carry the tensions of sunrise and sunset. Their succession is a cycle because, in the table shown above, it is possible to jump from step 12 to step 1 by lowering all note positions by one shruti. This circularity is implied by the process named sadja-sadharana in musicological literature (Shringy & Sharma 1978).
A list of 85 ragas with performance times predicted by the model is available in Arnold & Bel (1985). This hypothesis is indeed interesting — and it does hold for many well-known ragas — but we never found time to embark on a survey of musicians’ statements about performance times that might have assessed its validity.
Practice
Given scale types stored in the “-cs.raga” Csound resource file, Bol Processor + Csound can be used to check the validity of scales by playing melodies of ragas they are supposed to embody. It is also interesting to use these scales in musical genres unrelated with North Indian raga and distort them in any imaginable direction…
Choice of a raga
Todi Ragini, Ragamala, Bundi, Rajasthan, 1591 Public domain
We will take the challenge of matching one among the four “todi” scales with two real performances of raga Todi.
Miyan ki todi is presently the most important raga of the Todi family and therefore often simply referred to as Todi […], or sometimes Shuddh Todi. Like Miyan ki malhar it is supposed to be a creation of Miyan Tansen (d. 1589). This is very unlikely, however, since the scale of Todi at the time of Tansen was that of modern Bhairavi (S RG M P DN), and the name Miyan ki todi first appears in 19th century literature on music.
Joep Bor (1999)
This choice is a challenge for several reasons. Among them, the four variants of “todi” scales have been driven from a (questionable) extension of the grama-murcchana system. Then, notes “ni” and “rek”, “ma#” and “dhak” are close to the tonic “sa” and the dominant “pa” and might be “attracted” by the tonic and dominant, thereby disrupting the “geometry” of theoretical scales in the presence of a drone.
Finally, and most important, the performer’s style and personal options are expected to come in contradiction with this theoretical model. As suggested by Rao and van der Meer (2010 p. 693):
[…] it has been observed that musicians have their own views on intonation, which are handed down within the tradition. Most of them are not consciously aware of academic traditions and hence are not in a position to express their ideas in terms of theoretical formulations. However, their ideas are implicit in musical practice as musicians visualize tones, perhaps not as fixed points to be rendered accurately every time, but rather as tonal regions or pitch movements defined by the grammar of a specific raga and its melodic context. They also attach paramount importance to certain raga-specific notes within phrases to be intoned in a characteristic way.
We had already taken the Todi challenge with an analysis of eight occurrences using the Melodic Movement Analyzer (Bel 1988). The analyzer had produced streams of accurate pitch measurements which were submitted to a statistical analysis after being filtered as selective tonagrams (Bel 1984; Bel & Bor 1984). Occurrences included 6 performances of raga Todi and 2 experiments of tuning the Shruti Harmonium.
The MMA analysis revealed a relatively high consistency of note positions showing standard deviations better than 6 cents for all notes except “ma#” for which the deviation rose to 10 cents, still an excellent stability. Matching these results against the grama-murcchana “flexible” model revealed less than 4 cent standard deviation of intervals for 4 different scales in which the syntonic comma would be adjusted to 6, 18, 5 and 5 cents respeectively. In discussing tuning schemes, Wim van der Meer even envisaged that musicians might “solve the problem” of a “ni-ma#” wolf fifth by tempering fifths over the “ni-ma#-rek-dhak” cycle.
Our conclusion was that no particular “tuning scheme” could be taken for granted on the basis of “raw” data. It would be more realistic to study a particular performance by a particular musician.
Working with the Shruti Harmonium naturally incited us to meet Kishori Amonkar in 1981. She was a foremost exponent of Hindustani music, having developed a personal style that claimed to transcend classical schools (gharanas).
Most interesting, she used to perform with the accompaniment of a swara mandal (see picture), a zither which she would tune for each individual raga. Unfortunately, we were not equipped for measuring these tunings with sufficient accuracy. Therefore we brought the Shruti Harmonium to program intervals as per her instructions.
This did not work well for two reasons. A technical one: that day, a frequency divider (LSI circuit) was defective on the harmonium; until it was replaced some programmed intervals were inaccessible. A musical one: the experiment revealed that this accurate harmonium was unfit for tuning experiments with Indian musicians. Frequency ratios needed to be typed on a small keyboard, a usage too remote from the context of performance. This was a major incentive for designing and constructing our “microscope for Indian music”, the Melodic Movement Analyzer (MMA) (Bel & Bor 1984).
During the following years (1981-1984) MMA experiments took our entire time, revealing the variability (yet not the randomness) of raga intonation. For this reason we could not return to tuning experiments. Today, a similar approach would be much easier with the help of Bol Processor BP3… if only the expert musicians of that period were still alive!
Choice of a scale type
We need to decide between the four “todi” scale types produced by murcchana-s of the Ma-grama chromatic scale. To this effect we may use measurements by the Melodic Movement Analyzer (Bel 1988 p. 15). Let us pick up average measurements and the ones of a performance of Kishori Amonkar. These are note positions (in cents) against the tonic “sa”.
Note
Average
Standard deviation
Kishori Amonkar
rek
95
4
96
gak
294
4
288
ma#
606
10
594
pa
702
1
702
dhak
792
3
792
(dhak)
806
3
810
ni
1107
6
1110
The “dhak” between brackets is a measurement on the low octave
For the moment we ignore “dhak” in the lower octave as it will be dealt with separately. Let us match Kishori Amonkar’s results with the four scale types:
Note
Kishori Amonkar
todi1
todi2
todi3
todi4
rek
96
89
89
89
112
gak
288
294
294
294
294
ma#
594
590
590
610
610
pa
702
702
702
700
702
dhak
792
792
792
792
814
ni
1110
1088
1109
1109
1109
Scale type “todi2”, the best match to a performance of Kishori Amonkar
There are several ways of finding the best match for musical scales: either comparing scale intervals or comparing note positions with respect to the base note. Due to the importance of the drone we opt for the second method. The selection is easy here. Version “todi1″ may be discarded because of “ni”, the same with “todi3″ and “todi4″ because of “ma#”. We are left with “todi2″ which has a very good matching, including with the measurements of performances by other musicians.
Adjustment of the scale
The largest deviations are on “rek” which was performed 7 cents higher than the predicted value and “gak” 6 cents lower. Even a 10-cent variation is practically impossible to measure on a single note sung by a human, including a high-profile singer like Kishori Amonkar; the best resolution used in speech prosody is larger than 12 cents.
Any “measurement” of the MMA is an average of values along the rare stable melodic steps. It may not be representative of the “real” note because of its dependency on note treatment: if the approach of the note lies in a range on the lower/higher side, the average will be lower/higher than the target pitch.
Therefore it would be acceptable to declare that the “todi2″ scale type matches the performance. Nonetheless, let us demonstrate ways of modifying the model to reflect the measurements more accurately.
First we duplicate “todi2″ to create “todi-ka” (see picture). Note positions are identical in both versions.
Looking at the picture of the scale (or figures on its table) we notice that all note positions except “ma#” are Pythagorean. The series which a note belongs to is marked by the color of its pointer: blue for Pythagorean and green for harmonic.
Modified “todi2” scale matches the measured “ma#”
This means that modifying the size of the syntonic comma — in strict compliance with the grama-murcchana model — will only adjust “ma#”. In order to change “ma#” position from 590 to 594 cents (admittedly a ridicule adjustment) we need to decrease the size of the syntonic comma by the same amount. This can be done at the bottom right of the “todi-ka” page, changing the syntonic comma to 17.5 cents, a modification which is confirmed by the new picture.
A table on the “todi-ka” page indicates that the “rek-ma#” interval is still a perfect fifth even though it is smaller by 6 cents.
It may not be evident whether the syntonic comma needs to be increased or decreased to fix the position of “ma#”, but it is easy to try the other way in case the direction was wrong.
Final version of “todi2” adjusted to Kishori Amonkar’s performance in the medium octave (4)
Other adjustments will depart from the “pure” model. These lead to changing frequency ratios in the table of the “todi-ka” page. Raising “rek” from 89 to 96 cents requires a raising of 7 cents amounting to ratio 2(7/1200) = 1.00405. This brings the position of “rek” from 1.053 to 1.057.
In the same way, lowering “gak” from 294 to 288 cents requires a lowering of 6 cents amounting to ratio 2(-6/1200) = 0.9965. This brings the position of “gak” from 1.185 to 1.181.
Fortunately, these calculations are done by the machine: use the “MODIFY NOTE” button on the scale page.
The picture shows that the information of “rek” and “gak” belonging to Pythagorean series (blue line) is preserved. The reason is that whenever a frequency ratio is modified by its floating-point value, the machine verifies whether the new value comes close to an integer ratio of the same series. For instance, changing back “rek” to 1.053 would restore its ratio 256/243. Accuracy better than 1‰ is required for this matching.
A tuning scheme for this scale type is suggested by the machine. The graphic representation shows that “ni” is not consonant with “ma#” as their interval is 684 cents, close to a wolf fifth of 680 cents. Other notes are arranged on two cycles of perfect fifths. Interestingly, raising “rek” by 7 cents brought the “rek-ma#” fifth back to its perfect size (702 cents).
Again, these are meaningless adjustments for a vocal performance. We are only showing how to proceed when necessary.
The “todi2” scale type with “dhak” adjusted for the low octave (3)
The remaining adjustment will be that of “dhak” in the lower octave. To this effect we duplicate the preceding scale after renaming it “todi_ka_4″, indicating that it is designed for the 4th octave. In the new scale named “todi_ka_3″, we raise “dhak3” by 810 -792 = 18 cents.
This raises its position from 1.58 to 1.597. Note that this brings it exactly to a position in the harmonic series since the syntonic comma is 17.5 cents.
In addition, “dhak-sa” is now a harmonic major third — with a size of 390 cents fitting the 17.5 cents comma. This is certainly meaningful in the melodic context of this raga, a reason why an adjustment of the same size had been done by all musicians in their performances or tuning experiments.
This case is a simple illustration of raga intonation as a trade-off between harmonicity with respect to the drone and the requirement of consonant melodic intervals. It also indicates that the Shruti Harmonium could not follow musicians’ practice because its scale ratios were replicated in all octaves.
Choice of a recording
We don’t have the recording on which the MMA analysis had been done. A problem with old tape recordings is the unreliability of speed in tape transportation. On a long recording, too, the frequency of the tonic may change a little due to variations of room temperature influencing instruments — including tape dilation…
To try matching scales a with real performances and examine extremely small “deviations” (which have little musical significance, in any) it is therefore safer to work with digital recordings. This was the case with Kishori Amonkar’s Todi recorded in London in the early 2000 for the Passage to India collection and available free of copyright (link on Youtube). The following is based on that recording.
Setting up the diapason
Let us create the following “-gr.tryRagas” grammar:
-se.tryRagas -cs.raga
S --> _scale(todi_ka_4,0) sa4
Adjusting note convention in “-se.tryRagas”
In “-se.tryRagas” the note convention should be set to “Indian” so that “sa4” etc. is accepted even when no scale is specified.
The grammar calls “-cs.raga” containing the definitions of all scale types created by the procedure described above. Unsurprisingly, it does not play note “sa” at the frequency of the recording. We therefore need to measure the tonic to adjust the frequency of “A4” (diapason) in “-se.tryRagas” accordingly. There are several ways to achieve this with increasing accuracy.
A semitone approximation may be achieved by comparing the recording with notes played on a piano or any electronic instrument tuned with A4 = 440 Hz. Once we have found the key that is closest to “sa” we calculate its frequency ratio to A4. If the key is F#4, which is 3 semitones lower than A4, the ratio is r = 2(-3/12) = 0.840. To get this frequency on “sa4” we therefore would need to adjust the frequency of the diapason (in “-se.tryRagas”) to:
440 * r * 2(9/12) = 440 * 2((9-3)/12) = 311 Hz
A much better approximation is achieved by extracting a short occurrence of “sa4” at the very beginning of the performance:
A short occurrence of “sa4” in the beginning of Kishori Amonkar’s raga Todi
Then select a seemingly stable segment and expand the time scale to get a visible signal:
Expansion of a very brief “stable” occurrence of “sa4”
This sample contains 9 cycles for a duration of 38.5 ms. The fundamental frequency is therefore 9 * 1000 / 38.5 = 233.7 Hz. Consequently, adjust the diapason in “-se.tryRagas” to 233.7 * 2(9/12) = 393 Hz.
The last step is a fine tuning comparing by ear the production of notes in the grammar with the recording of “sa4” played in a loop. To this effect we produce the following sequence:
These are eight occurrences of “sa4” played at slightly increasing pitches adjusted by the pitchbend. First make sure that the pitchbend is measured in cents: this is indicated in instrument “Vina” called by “-cs.raga” and Csound orchestra file “new-vina.orc”.
Listening to the sequence may not reveal pitch differences, but these will appear to a trained ear when superposed with the recording:
Recording on “sa4” superposed with a sequence of “sa4” at slightly increasing pitches. Which occurrence is in tune? ➡ This is a stereo recording. Use earphones to hear the music and sequence of plucked notes separately
One of the four occurrences sounds best in tune. Suppose that the best match is on _pitchbend(+10). This means that the diapason should be raised by 10 cents. Its new frequency would therefore be 393 * 2(10/1200) = 395.27 Hz.
In fact the best frequency is 393.22 Hz, which amounts to saying that the second evaluation (yielding 393 Hz) was fair — and the singers’ voices very reliable! Now we can verify the frequency of “sa4” on the Csound score:
These methods could in fact be summarized by the third one: use the grammar to produce a sequence of notes in a wide range to determine an approximate pitch of “sa4” until the small range for the pitchbend (± 200 cents) is reached. Then play sequences with pitchbend values in increasing accuracy until no discrimination is possible.
In a real exercise it would be safe to check the measurement of “sa4” against occurrences in several parts of the recording.
This approach is indeed too demanding on accuracy for the analysis of a vocal performance, but it will be appreciable when working with a long-stringed instrument such as the rudra veena. We will show it with Asad Ali Kan’s performance.
Matching phrases of the performance
We are now ready to check whether note sequences produced by the model would match similar sequences of the recording.
We first try a sequence with emphasis on “rek”. The following note sequence is produced by the grammar:
Below is the phrase sung by the musicians (location 0′50″) then repeated in superposition with the sequence produced by the grammar:
A phrase with emphasis on “rek” sung by Kishori Amonkar, then reproduced in superposition with the sequence of notes produced by the grammar using scale “todi_ka_3” ➡ This is a stereo recording. Use earphones to hear the music and sequence of plucked notes separately
In this example, scale “todi_ka_3″ has been used because of the occurrence of brief instances of “dhak3”. The position of “rek” is identical in the 3d and 4th octaves. The blending of voice with the plucked instrument is remarkable in the final held note.
In the next sequence (location 1′36″) the position of “gak4” will be appreciated. The grammar is the following:
A phrase targeting “gak” repeated in superposition with the sequence of notes produced by the grammar using scale “todi_ka_4”
This time, the scale “todi_ka_4″ was selected, even though it had no incidence on the intonation since “dhak” is absent.
A word about building the grammar: we looked at the signal of the recorded phrase and measured the (approximate) durations of notes: 1.37s, 3.1s, 1.8s, 7.5s, 4.4s. Then we converted these durations to integer ratios — fractions of the basic tempo whose period is exactly 1 second as per the setting in “-se.tryRagas”: 137/100, 31/10 etc.
Signal of the preceding recorded phrase
Below is a pianoroll of the sequence produced by the grammar:
Pianoroll of the note sequence produced by the grammar
No we try a phrase with a long rest on “dhak3” (location 3′34″) proving that scale “todi_ka_3″ matches perfectly this occurrence of “dhak”:
S --> KishoriAmonkar6 KishoriAmonkar6 --> _scale(todi_ka_4,0) 28/100 {29/100,ma#4}{40/100,dhak4}{63/100,ni4 sa5 ni4}{122/100,dhak4}{64/100,pa4}{83/100,ma#4}{44/100,pa4}{79/100,dhak4}
A light touch of “pa”
Pitch accuracy is no surprise in performances by Kishori Amonkar. With a strong awareness of “shruti-s”, she would sit on the stage plucking her swara mandal carefully tuned for each raga.
A test with the rudra veena
Asad Ali Khan playing the rudra veena
Asad Ali Khan was one of the last performers of the rudra veena in the end of the 20th century and a very supportive participant in scientific research on raga intonation. Pitch accuracy is such on this instrument that we could identify tiny variations controlled and significant in the context of the raga. Read for instance Playing with Intonation (Arnold 1985). In order to measure vibrations below the range of audible sounds, we occasionally fixed a magnetic pickup near the last string.
Below are the statistics of measurements by the Melodic Movement Analyzer of raga Miyan ki Todi interpreted by Asad Ali Khan in 1981. The second column contains the measurements of his tuning of the Shruti Harmonium during an experiment. Columns on the right display predicted note positions according to the grama-murcchana model with a syntonic comma of ratio 81/80. Again in this raga, “dhak” may take different values in the peerformance, depending on the octave.
Note
Asad Ali Khan performing
Asad Ali Khan tuning
todi1
todi2
todi3
todi4
rek
99
100
89
89
89
112
gak
290
294
294
294
294
294
ma#
593
606
590
590
610
610
pa
702
702
702
702
700
702
dhak3
795
794
792
792
792
814
dhak2
802
ni
1105
1108
1088
1109
1109
1109
Again, the best match would be the “todi2″ scale with a syntonic comma of 17.5 cents. We created two scales, “todi_aak_2″ and “todi_aak_3″ for the 2nd and 3th octaves.
Adjustments of the “todi2” scale for Asad Ali Kan’s performance on the rudra veena. Low octave on the left and medium on the right.
The scale constructed during the Shruti Harmonium experiment is of lesser relevance because of the influence of the experimenter playing scale intervals with a low-attracting drone (produced by the machine). In his attempt to resolve dissonance in the scale — which always contained a wolf fifth and several Pythagorean major thirds — Khan saheb ended up with a tuning identical to the initial one but one comma lower. This was not a musically significant situation!
Tuning scheme for “todi_aak_2”
Scale “todi_aak_2″ (in the low octave) contains interesting intervals (harmonic major thirds) which lets us anticipate effective melodic movements. The tuning scheme summarizes these relations.
We are now taking fragments of Asad Ali Khan’s performance of Todi (2005) available on Youtube (follow this link).
The performance began in the low octave, therefore with scale “todi_aak_2″. The frequency of Sa was measured at 564.5 Hz with the method explained earlier.
Let us start with a simple melodic phrase repeated two times, the second time in superposition with the note sequence produced by the grammar.
A phrase of raga Todi by Asad Ali Khan repeated 2 times, the second time in superposition with the sequence of notes produced by the grammar ➡ This is a stereo recording. Use earphones to hear the music and sequence of plucked notes separately
This grammar contains an unusual sign ‘&’ used to concatenate sound-objects (or notes) beyond the borders of polymetric expressions (between curled brackets). This makes it possible to play the final “rek3” and “sa3” as continuous notes. This continuity is clear on the following graph:
The end of the phrase, showing “rek3” and “sa3” as continuous notes
It is time to make sure that accurate tunings and adjustments of scales are more than an intellectual exercise… After all, the main difference between scales “todi_aak_2″ and “todi_aak_3″ is that “dhak” is 7 cents higher in “todi_aak_2″, which means a third of a comma! To check the effect of the fine tuning, listen to the superimposition two times, once with “todi_aak_3″ and the second time with “todi_aak_2″:
The same “dhak2” with a note produced using “todi_aak_3” and the second time “todi_aak_2”
To check the difference between these two versions of “dhak2” we can play them in sequence, then superimposed:
The two versions of “dhak2” in sequence then superimposed
With fundamental frequencies 132.837 Hz and 133.341 Hz, the beat frequency (of sine waves) would be 133.341 - 132.837 = 0.5 Hz. The perceived beat frequency is higher because of the interference between higher partials. This suggests that a difference of 7 cents is not irrelevant in the context of notes played by a long-stringed instrument (Arnold 1985).
As “sa2” is out of range of the Csound instrument “Vina”, it is performed here as “rek2” with a pitchbend correction of one semitone.
Low-octave phrase repeated with attempted superimposition of a note sequence
The rendering of phrases in the low octave is very approximative because of the predominance of meend (pulling the string). Some effects could be better imitated with the aid of performance controls — see for instance Sarasvati Vina — but this requires a mastery of the real instrument to design patterns of musical “gestures” rather than sequences of sound events… Imitating the melodic intricacy of raga is not the topic of this page; we are merely checking the relevance of scale models to the “tonal skeleton” of ragas.
Accidental notes
Raga scales extracted from murcchanas of the Ma-grama chromatic scale (see above) contain exclusively notes presumably belonging to the raga. They cannot accommodate accidental notes nor the scales used by mixing ragas, a common practice.
Let us take for instance a fragment of the preceding example which was poorly rendered by the sequence of notes produced by the grammar. (We learn from our mistakes!) We may feel like replacing expression {38/10, pa2 gak2 pa2 dhak2 _ pa2 _} with {38/10, pa2 ga2 pa2 dhak2 _ pa2 _} making use of “ga2” which does not belong to the “todi_aak_2″ scale. Unfortunately, this produces an error message:
ERROR Pitch class ‘4’ does not exist in _scale(todi_aak_2). No Csound score produced.
This amounts to saying that scale “todi2″ contains no mapping of key #64 to “ga” — nor key # 65 to “ma”, see picture.
To solve this problem we may recall that scale “todi2″ has been extracted from “Re1_murcchana”. The latter contains all grades of a chromatic scale in addition to the extracted ones. Therefore it is sufficient to replace “_scale(todi_aak_2,0)” with “_scale(Re1_murcchana,0)” in this section:
The scale editor takes care of assigning each note a key number based on the chromatic scale if a standard English, Italian/French or Indian note convention is used. In other cases this mapping should be done by hand. Designers of microtonal scales should stay aware of key mappings if they use customized names for “notes”.
Another problem arises because in “todi_aak_2″ note “dhak” had been raised from 792 to 810 cents, which is not its value in “Re1_murcchana”. This may be fixed by creating another variant of the scale with this correction, or simply use the pitchbend to modify “dhak2” — in which case the same pitchbend could have been used in the first place to raise “gak2”.
Finally, the best approach to avoid this problem would be to use the source chromatic scale “Re1_murcchana”, a murcchana of Ma-grama, to construct raga scales even though some grades will never be used.
To conclude…
This whole discussion was technical. There is no musical relevance in trying to associate plucked notes with very subtly ornamented melodic movements. The last excerpt (2 repetitions) will prove — if at all necessary — that the intonation of Indian ragas is much more than a sequence of notes in a scale, whatever its accuracy:
This melodic phrase is repeated 2 times to check its superimposition with the sequence of notes produced by the grammar ➡ This is a stereo recording. Use earphones to hear the music and sequence of plucked notes separately
Trying to follow the intricacy of alankara (note treatment) with a simplistic notation of melodic phrases shows the disruption between “model-based” experimental musicology and the reality of musical practice. This explains why we resorted to descriptive models (e.g. automatic notation) captured by the Melodic Movement Analyzer or computer tools such as Praat, rather than attempting to reconstruct melodic phrases from theoretical models. Experiments on scales deal with the “skeletal” nature of intonation, which is a necessary yet not sufficient parameter for describing melodic types.
Bharata. Natya Shastra. There is no currently available English translation of the first six chapters of Bharata’s Natya Shastra. However, most of the information required for this interpretation has been reproduced and commented by Śārṅgadeva in his Sangita Ratnakara (13th century AD).
Bor, J.; Rao, S.; van der Meer, W.; Harvey, J. The Raga Guide. Nimbus Records & Rotterdam Conservatory of Music, 1999. (Book and CDs)