In a preceding article we explained how to install and run Bol Processor ‘BP1’ on a virtual Apple IIe. BP1 is the earliest version of Bol Processor implemented in 1981 on Apple II computers, as a requirement for Jim Kippen’s fieldwork in India — read At the heart of Indian rhythms and their evolution.… We will now show its operation in a real musical context: the modelling of a ‘theme-and-variations’ piece of drumming (called q‘aida) taught by Ustad Afaq Husain Khan, an expert of the Lucknow style of tabla in India.
This work dates back to the 1980s and has been documented in several publications, including Kippen and Bel’s Modelling music with grammars: formal language representation in the Bol Processor (1992) from which the example will be taken. Excerpt (page 207):
A large part of the tabla repertoire involves improvisation. Any sequence of strokes may be considered as a finite string of symbols whose organisation is related to some implicit formal system. Automatic sequences (i.e. sequences generated by finite-state automata) share properties that place them somewhere between periodicity and chaos, yet closer to periodicity. Since both strict and approximate periodicity are essential features in music, it is realistic to think that strings of musical events may be appropriately represented with automata or formal grammars. In other words, the most fundamental reason for us to view formal language models as relevant models of music lies in properties that are intrinsic to music, rather than in analogical links between music and natural languages.
The theme of this q‘aida is the following sequence:
Strokes on the drum — bols such as ‘dha’, ‘ti’, ‘ge’, ‘na’… — belong to the (terminal) alphabet of the formal grammar. This sequence should be read linearly from left to right. Each group represents a beat comprising 4 units (‘trkt’ is a compound stroke of 2 units). Thus, the theme and its variations are framed on a 16-beat rhythmic model named tintal in North-Indian music.
The grammar and examples of this qa‘ida are stored as “Q2.7” on diskette “BP-JULY87.DSK” which can be loaded after starting Bol Processor (BP-PRG.DSK). We recommend setting the virtual Apple II to maximum speed to save the time of reading (virtual) diskettes! After loading Q2.7’s grammar and data, the theme can be displayed as data item #2:
Note that the terminal alphabet used on BP1 is not exactly the one of the publication. For instance, ‘dhee’ has been replaced with ‘dhi’, ‘tee’ with ‘ti’, comprehensive changes for readers prefering a transliteration of Hindustani phonemes to the rendering of syllables in English.
In addition, syllable ‘ti’ may be rendered as ‘tit’. These subtleties are governed by the keyboard mapping that can be displayed (and modified) by selecting “Alphabet” then “Modify” from the main menu.
The grammar implemented in BP1 is the same as the one displayed in Appendix 2 of the publication, leaving out spellings variants of a few bols and different glyphs used for tagging patterns (“master” and “slave” markers) and the instruction of bol density, as explained in our a preceding article. For example, rule
GRAM#2  <100> S32 <—> * (= /6+ A16 V8 + /4) + O16
was displayed as:
Bol density marker “6” is nowadays written “/6” and “4” as “/4”. The plus sign ‘+’ is used as a context marker.
In later versions of Bol Processor we created a “_tempo()” tool which is more flexible than bol density. For instance, “_tempo(8)” would produce the same effect as “/8” in a simple sequence. However, in polyphonic structures, “/8” is an absolute value whereas “_tempo(8)” is relative to the current tempo. This makes it possible to calibrate the durations of several sequences contained in a polymetric expression — read Two Algorithms for the Instantiation of Musical Structures (1994) for details. Furthermore, expressions such as “_tempo(7/4)” and even “_tempo(0.476)” are licit…
Subrammar #7 contains the templates of this grammar:
 (=+.….….….…+.….….….…+ * (=+.….….….…+) +.….….….…;)
 (=+.….….….…+.….….….…+ * (=+.….….….…+) +/8+.….….….….….….….…;/4;)
 (=+.….….….…+.….….….…+ * (=/6+.….….…/4.….…+) +.….….….…;)
These templates are the complete list of patterns produced by (presumably) all variations of the q‘aida. They contain brackets bordering reference strings with the “=” marker (displayed as “◆” in BP1), bol density figures and arbitrary symbols “+” and “;” used as context in rule, as explained in the publication. Technically, patterns are similar to regular expressions against which a variation is matched before being parsed by the grammar.
Any grammar containing patterns and/or bol density figures must be completed with templates in order to assess the grammaticality of variations. Fortunately, these templates are automatically produced by the grammar!
To produce variations based on this grammar, select “Grammars” in the main menu, then go to subgrammar #1, “Edit”, and move for instance to rule #2:
<100> S <—> (=+ S64 ;)
This will produce variations containing 64 bols as suggested by the name of variable “S64”. Rule #3 would produce variations of 128 bols as suggested by “D128”.
Type ctrl-C ([C]ompute). You will be asked to indicate the first subgrammar (1) and the last subgrammar (6). If you start computing from a rule of subgrammar #3, for instance, it makes sense to specify #3 as the first subgrammar. If a subgrammar lower than 6 is specified as the last one, some variables may not be rewritten as strings of terminal symbols. This may be useful to check partial processes in the production of variations.
Options offered then are A)nalyse, S)ynthesize, D)estroy structure and Q)uit. Choose “Synthesize”. Say “no” to “Create templates” and to “Systematic tree-search”. You may reply “yes” to “Step by step?” to display all derivation steps, which makes you familiar with the grammar. Example of result:
This is an interesting example: on the third line, bol density is doubled (8 instead of 4).
You are now offered the option of “Appending” the variation to the data set, “Repeating” the production process, “Printing” (on the virtual printer), creating “More” variations or “Verifying” this variation. It is not evident that the grammar accepts this variation if it has been poorly designed. (This is unlikely with this example.) Option “Verify” should quickly end up with “S”, the start string, if the variation is correct.
If a few variations have been appended to the data set, editing Data will show them at the end of the set.
This process of producing variations is called “modus ponens” in the jargon of expert systems. Variations produced in this way were read by the analyst (Jim Kippen) to the expert musician to check their acceptance as licit variations of the q‘aida.
Imagine now that the expert musician is reciting a variation which is typed in the data set. This makes it clear that quick and faultless typing was crucial for this field research… Use the keyboard mapping to learn typing at high speed; it is less difficult than playing on the drums!
In the data set, when a variation is displayed, type ctrl-C for “[C]ompute”. Say “yes” to “Revise processing?”. Now the first grammar is #1 but the last grammar should be #7 so that templates are taken into account. Select “Analyse”, say “no” to “Display probability?” and “yes” or “no” to “Step by step?”.
If you are analyzing step by step, use the right arrow to proceed or the left arrow to backtrack. The subgrammar currently used for derivations is mentioned at the bottom of the page, and the index of the latest candidate rule appears on top. Thus, it is possible to visualize all details of the computation for the production or analysis of a variation.
You can check the entire data set against the grammar by selecting “Verify grammars” on the main menu.
If the variation matches several templates, each one will be used to parse it. In case the parsing is successful with several templates, the structure of the piece is ambiguous. This is analogous to parsing sentence “John said Mary is a liar” which requires the placement of either two commas or a semi-colon, each “template” yielding an opposite meaning…
Currently, in the grammar, all rule weights are set to 100 except for rule #3 of subgrammar #1. We can use the 12 variations in the data set to infer rule weights: each of them will be analyzed and every rule in this process will have its weight incremented by 1 unit.
In the main menu, select “Weights”, then “Emulate learning” and “Reset weights to 0”. From item #2 to item #13. Last grammar is “7” (as templates are required).
The result can be printed. Note that all weights in subgrammar #6 are set to 100 because it is an “ORD” grammar: no random choice of the candidate rule.
Entering new data sets allowed “learning” from more examples and improving the stochastic model that would produce more “aesthetically acceptable” variations.
Accessed from the main menu. This procedure is used for changing the names of variables. This procedure proved helpful in creating grammars making sense to humans, not only machines…
To check this process we recommend to quite and reload the current project, as some procedures may have been stored in memory. Load only grammar, no data to keep enough free memory
Select “Grammars” from the main menu, then go to subgrammar #7 (the current templates) and delete it by selecting “Remove from series”. (This might not be necessary as the machine never duplicates a template, but things will be more clear in this manner.)
Then create a new subgrammar #7, select “Compute” and “Create templates”. You will be asked about the “last grammar defining structures”. This choice is of high relevance to the speed of computation because template production implies the production of “all variations”. If your answer is “6” the machine may work an extremely long time. Looking at the grammar shows that subgrammar #3 is the last one containing structural markers. Therefore the proper answer is “3”.
This process takes a very long time even at the highest speed. Its progression is shown by ‘+’ signs printed on the line under “WAIT”. Since this grammar produces 21 templates, you need to wait for 21 ‘+’ signs. Fortunately, template production was performed once for ever in most grammars…
This demo is an attempt to illustrate the usage of Bol Processor BP1, in the early 1980’s, as an expert system modelling compositional/improvisational processes in the q‘aida genre of tabla drumming. It was of great relevance to develop an editor facilitating the quick and accurate writing of bols (representations of strokes on the drum) and the creation of pattern rules taking into account implicit syntactic structures of these musical pieces.
Later on, Bol Processor was implemented on Macintosh computers. Versions of ‘BP2’ compliant with system versions up to MacOS 10.14 (Mojave) can be dowloaded from SourceForge.
BP2 reproduced all procedures of BP1, notably the ones described in Kippen & Bel’s paper Modelling music with grammars: formal language representation in the Bol Processor (1992). However, its editor is not as sophisticated with respect to pattern editing. Furthermore, the “smart keyboard” option makes it possible to map terminal symbols to individual keys, but the cursor does not “jump” over terminal symbols, variables and reserved words.
BP2 introduced the possibility of polyphonic/polyrhythmic representation. Polymetric structures are an unmatched model for the representation of musical time and by extension the structure of “time objects”: music, speech, noises, video, robotic movements etc. This model is able to deal with incomplete definitions and performs all terminal time calculations accurately, using integer ratios. Results are simplified to avoid integer overflow and comply with the quantization required for the actual performance.
At present, a new version of Bol Processor compliant with 64-bit processors on various systems (MacOS, Windows, Linux…) is under development. Currently it works with a PHP interface. We invite software designers to join the team and contribute to the development of the core application and its client applications. Please join the BP open discussion forum and/or the BP developers list to stay in touch with work progress and discussions of related theoretical issues.
- Time and Musical Structures (1990) on polymetric structures
- Two Algorithms for the Instantiation of Musical Structures (1994) on polymetric structures and the time-setting algorithm of sound objects
- Migrating Musical Concepts: An Overview of the Bol Processor (1998) for a general presentation including a description of quantization.
Contributors to this article: Bernard Bel