Parsing music

The Bol Processor can analyse musi­cal vari­a­tions (strings of ter­mi­nal sym­bols) using a gram­mar. A suc­cess­ful parse (mem­ber­ship test) indi­cates that the vari­a­tion was pro­duced by, or could be pro­duced by, the gram­mar. This process was used exten­sive­ly for mod­el­ling impro­vi­sa­tion and com­po­si­tion in north Indian tabla drum­ming — read Jim Kippen's inter­view.

On this page we will intro­duce the real data sets "-da.dhahatite" ver­sus "-gr.dhahatite", and "-da.dhin--" ver­sus "-gr.dhin--". However, let us first deal with a very sim­ple example.

A simple grammar

Grammar "-gr.tryAllItems0" in the "ctests" fold­er:

RND
gram#1[1] S <-> (= X) X (: X)
gram#1[2] S <-> X X
-----
RND
gram#2[1] X <-> a
gram#2[2] X <-> b

This gram­mar is a "true Bol Processor grammar":

• It does not con­tain erase rules such as X --> lambda
• Rules can be used for pro­duc­ing and pars­ing items, as indi­cat­ed by the "<->" operator
• Rules do not con­tain any /flag/
• Rules do not have pro­gram­ma­ble weights such as "<K3>", "<K1=50>", etc.
• Rules do not con­tain any pro­ce­dure such as "_goto", "_repeat", "_destru", etc.
• Rules do not con­tain any per­for­mance con­trol such as "_vel", "_pan", "_retro", etc.
• Note, how­ev­er, that rules can con­tain left/right con­texts, includ­ing remote ones.

When a gram­mar is read, the inter­face checks whether it is "true BP". If so, a "Create tem­plates" but­ton is displayed.

This gram­mar uses the ter­mi­nal alpha­bet "-al.abc" which is linked to a set of sound-objects, but we won't use this fea­ture here. Set the out­put mode to "BP data file".

Let us first pro­duce all items, i.e. the lan­guage of this gram­mar. In the set­tings, check "Produce all items" in the PRODUCTION sec­tion. You can set "Max items pro­duced" to a large num­ber, for instance 500, as we assume that the actu­al size of the lan­guage is much smaller.

Click "PRODUCE". The result is:

a a a
a b a
b a b
b b b
a a
a b
b a
b b

The first four items have been cre­at­ed by gram#1[1], the first rule of the first sub­gram­mar. The rule con­tains a pat­tern (=X)…(:X) mean­ing that the first and last parts must be identical.

The gram#1[2] rule pro­duces two instances of vari­able X that are rewrit­ten as 'a' or 'b' in gram#2. All pos­si­bil­i­ties are dis­played in the last four items.

These 8 items have been copied to "-da.tryAnalyse", with addi­tion­al emp­ty lines to sep­a­rate them.

Parse "-da.tryAnalyse"

In order to parse items in "-da.tryAnalyse", we need to write the name of the gram­mar on top of the Data page, along with links to the alpha­bet and settings:

-se.tryAnalyse
-al.abc
-gr.tryAllItems0

Now, "Analyse" but­tons are shown for each item. However, if you click on any of these, the pars­ing will fail for the first four. The rea­son is that these should be recog­nised by gram#1[1], which is a pat­tern rule. In oth­er words, we need to tell the engine that the pat­tern has been recog­nised.

👉  This is why we need to cre­ate tem­plates in true BP gram­mars that con­tain pat­tern rules.

Create templates for "-gr.tryAllItems0"

Click the "Create tem­plates" but­ton, then read the out­put file. We get:

----------
TEMPLATES:
[1] (@0 _)_(@1 )
[2] __
---------

In this sim­ple gram­mar, the two tem­plates rep­re­sent the pat­tern types of each rule in gram#1. Although no the­o­ret­i­cal knowl­edge of tem­plates is required to use them, let us have a lit­tle explanation:

Template [2] con­tains two occur­rences of '_', which means it will match any item con­tain­ing two ter­mi­nal symbols.

Template [1] con­tains the struc­tur­al mark­ers "@0" indi­cat­ing a mas­ter paren­the­sis, and "@1" its slave copy. Note that "@0" is fol­lowed by a sin­gle "_", indi­cat­ing a sin­gle ter­mi­nal sym­bol, but "@1" is not alone in its paren­the­sis, as it is meant to be the exact copy of its master.

Copy the tem­plates, paste them at the bot­tom of gram­mar "-gr.tryAllItems0", then save it. Note that the tem­plate but­ton is now labelled "Update tem­plates".

Parse "-da.tryAnalyse" using the templates

Return to the "-da.tryAnalyse" and click the "Analyse" but­tons. Now, all items are parsed suc­cess­ful­ly. The trace of the analy­sis of the first item "a a a" make it clear:

Analysing this item
Compiling gram­mar…
Compiling sub­gram­mar #1…
Compiling sub­gram­mar #2…
Compiling sub­gram­mar #3…
Parsing com­plet­ed
Errors: 0
Template(s) found, posi­tion 333
👉 We will try all tem­plates, as per your set­tings
Analyzing selec­tion…
Item matched tem­plate [1]
• Subgrammar 3/3
• Subgrammar 2/3
• Subgrammar 1/3
👉 Item match­ing tem­plate [1] accept­ed by grammar… ✅

Evidently, the four first items will match the "tem­plate [1]", and the four last items will match the "tem­plate [2]". The trace is self-explanatory:

[Step #1] Selected: gram#2[1] X <-> a
(= a) X(: a)
[Step #1] Selected: gram#2[1] X <-> a
(= X) X(: X)
[Step #1] Selected: gram#1[1] S <-> (= X) X(: X)
S

A few words about the cre­ation of tem­plates. Firstly, this pro­ce­dure is restrict­ed to finite lan­guages. A gram­mar con­tain­ing recur­sive rules could pro­duce items of unre­strict­ed length, result­ing in an infi­nite num­ber of tem­plates. The Bol Processor has gram­mar pro­ce­dures that restrict the num­ber of times a rule can be applied, there­by lim­it­ing the length or dura­tion of any pro­duc­tion. However, these pro­ce­dures are cur­rent­ly not applic­a­ble to the pars­ing of items.

Secondly, at first glance, cre­at­ing tem­plates for the sim­ple gram­mar amounts to pro­duc­ing the entire lan­guage, replac­ing ter­mi­nals with '_', and elim­i­nat­ing dupli­cate instances. This would be imprac­ti­cal for most real-world gram­mars because, although the lan­guage is finite, it is very large. To avoid this, the machine first deter­mines up to which sub­gram­mar struc­tur­al rules are found. Then it cre­ates all deriva­tions of these sub­gram­mars, and for each deriva­tion it pro­duces only one item which is con­vert­ed to its template.

Structural rules are the ones that con­tain syn­tac­tic struc­tures (master-slave paren­the­ses) or/and struc­tur­al mark­ers if they are not in contexts.

Structural mark­ers are the glyphs '+', ':', ';', '=' and '\'. We'll see their usage in gram­mars for tabla compositions.

Analysis of tabla compositions

Grammars "-gr.dhahatite" and "-gr.dhin--" are authen­tic exam­ples of qa‘ida, the basic composition/improvisation form in the Lucknow school of tabla, as taught to Jim Kippen by Ustad Afaq Husain Khan in the ear­ly 1980s. (Read our joint paper in Anthropological Quarterly, 1989.)

The meth­ods described here were first imple­ment­ed in 1981 on an Apple II com­put­er with just 64 kilo­bytes of mem­o­ry! The Bol Processor BP1 was pro­grammed in 6502 assem­bly lan­guage and was effi­cient enough to be used as an expert sys­tem for field research with lead­ing expo­nents of the tabla.

The Bol Processor gram­mars were devel­oped by for­mu­lat­ing hypothe­ses about the struc­ture of a spe­cif­ic qa‘ida with­in a teach­ing con­text. The aim was to gen­er­ate as many vari­a­tions as pos­si­ble that would be assessed as cor­rect by an expert. However, a prop­er iden­ti­fi­ca­tion of the lan­guage implied that the machine would be able to rec­og­nize good and bad vari­a­tions sug­gest­ed by experts and stu­dents. For this rea­son, each gram­mar should be able to work 'in reverse': giv­en a musi­cal vari­a­tion (a string of ter­mi­nals typed on the key­board), the rules are applied from bot­tom to top until no rule is applic­a­ble. If the final sym­bol is 'S', the start­ing sym­bol, then the musi­cal vari­a­tion is con­sid­ered "cor­rect".

The "-gr.dhahatite" grammar

The "dhad­hatite" qa‘ida is taught to tabla begin­ners. This is because it is tech­ni­cal­ly easy while also fol­low­ing com­plex syn­tac­tic struc­tures, which tra­di­tion­al musi­cians refer to as "qavaid" — a term mean­ing "gram­mar" in Urdu (and Arabic). So, the idea of using for­mal gram­mars to describe this com­po­si­tion­al type was very tempt­ing. Therefore, the idea of using for­mal gram­mars to describe this com­po­si­tion­al type was very promising.

The ear­ly ver­sion of the Bol Processor (BP1) enabled users to pro­gram the computer's key­board to map words to keys instead of char­ac­ters. For exam­ple, typ­ing "q" on an English key­board would type "dha" into the text. After some train­ing, Jim Kippen could type sequences of key­strokes at the same speed at which they were played. This was high­ly rel­e­vant for pro­gram­ming gram­mars and work­ing with large sets of data. Unfortunately we haven't been able to repro­duce this key­board map­ping on a PHP inter­face run­ning on var­i­ous systems.

When you open the "-gr.dhahatite" you will see that it is recog­nised as a "true BP gram­mar". Click the "Create tem­plates" but­ton and copy the tem­plates at the bot­tom of the grammar:

TEMPLATES:
[1] 4+4+4+4/4 ________+________(@0 ________)+________ * (@0 ________++________)(@2 )________
[2] 4+4+4+4/4 (@0 ++________)+________________+________ * (@1 ) * (@0 ++________)________________
[3] 4+4+4+4/4 ________(@0 ______+__)________+________ * (@0 ________) * (@2 )________________
[4] 4+4+4+4/4 (@0 ++____________+____)________+________ * (@1 )________________
[5] 4+4+4+4/4 (@0 ++______________+__)________+________ * (@1 )________________
[6] 4+4+4+4/4 (@0 ++________________)________+________ * (@1 )________________

These six tem­plates con­tain mark­ers of master-slave paren­the­ses cre­at­ed by sub­gra­mar #2, includ­ing mark­ers of a homo­mor­phism, notat­ed "*", that mod­i­fies the con­tent of the fol­low­ing paren­the­sis, apply­ing a map­ping defined in "-al.dhadhatite":

*
dha --> ta
ti --> ti
te --> te
na --> na
dhee --> tee
tr --> tr

The ter­mi­nal alpha­bet of this gram­mar is made of sound-objects named "dha", "ta", etc. These are quasi-onomatopoeic mnemon­ics, in an oral nota­tion sys­tem, that rep­re­sent drum-strokes. The "*" homo­mor­phism reflects the musi­cal con­cept of replac­ing "open" (res­onat­ing) strokes, such as "dha" and "dhee", with their "closed" coun­ter­parts, here "ta" and "tee". So, for instance "*(dhadhatite)" should be played "tatatite". You can use any word you like instead of "*" to label the mapping.

The tem­plates also con­tain struc­tur­al mark­ers "+" also pro­duced by sub­gram­mar #2, for example:

gram#2[1] S1F S2F S1V S2F E32 <-> S1F +S2F (= V8 ) +S2F * (= S1F ++ S2F ) (: V8 ) S1F

These mark­ers are used as (prox­i­mate) con­texts in sub­gram­mar #5, for example:

gram#5[5] ++ A2 <-> ++dheena
gram#5[6] #+ S1F <-> #+ dhadhatitedhadhadheena

In rule [5], the string "++" is a left con­text, but in rule [6] the string "#+" is a neg­a­tive con­text, mean­ing any­thing but '+'.

The last rule of sub­ram­mar #5 deserves our attention:

gram#5[8] ++ S2F <-- ++ dhadhatitedhadhadheena

It is using the deriva­tion sign "<--" instead of "<->". This means that this rule can only be used in the analy­sis. It is easy to guess that when the sequence of strokes "dhad­hatit­ed­had­had­heena" is found pre­ced­ed by a "++" (picked up from the tem­plate), it is imme­di­ate­ly iden­ti­fied as "S2F". Sequences S1F and S2F appear in typ­i­cal rhyth­mic con­texts shown in sub­gram­mar #1, for example:

gram#1[3] S64 <-> S1V S2F S1F S2F E32

In sub­gram­mar #2, some of these fixed units are replaced with variations:

gram#2[2] S1V S2F S1F S2F E32 <-> (=++ A1 V7 ) +S2F S1F +S2F * (:++ A1 V7 ) * (= ++ S2F ) S1F S1F

To make things eas­i­er, the ana­lyst labelled the vari­ables with num­bers indi­cat­ing their dura­tions: 1 for A1, for exam­ple, and 7 for V7. This is not com­pul­so­ry, however.

In sub­gram­mar #3, vari­a­tions are bro­ken down into small­er units. For example:

gram#3[18] V7 <-> T1 V6
gram#3[19] V7 <-> T2 V5

Then in the fol­low­ing sub­gram­mars, small units are rewrit­ten as sequences of strokes, for instance:

gram#4[5] T2 <-> dheena
…
gram#5[2] + B4 <-> +dhad­ha­teena

Experts famil­iar with this musi­cal genre will be con­vinced by an in-depth analy­sis of this gram­mar and exper­i­ments of pro­duc­tion that its con­struc­tion is based on musi­cal con­cepts that are embod­ied per­fect­ly in the for­mal gram­mars of the Bol Processor.

There is lit­tle to say about the deriva­tion modes of these sub­gram­mars. Most of them could be set to "RND", but "LIN" pro­duces equiv­a­lent out­put in less com­pu­ta­tion time. This was crit­i­cal in the Apple II era… Subgrammar #5 is "ORD", the fastest option, but "LIN" or "RND" would also be acceptable.

Now, let us pro­duce a few vari­a­tions of the "-gr.dhahatite" gram­mar. In the set­tings, check the "Non-stop improvize" option and set "Maxitems pro­duced" to a small num­ber, e.g. "4"., which is safe in terms of com­pu­ta­tion time and disk usage. Set the out­put file to "BP data file", since no sounds are expected.

If the "Seed for ran­dom­iza­tion" is set to 0 in the set­tings, you will get a dif­fer­ent sequence each time you click the "PRODUCE ITEM(s)" but­ton, for example:

4+4+4+4/4 dha dha ti te • dha dha dhee na • dha dha dhee na • ti te tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha tee na •
ta ta ti te • ta ta tee na • ta ta tee na • ti te tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha dhee na

4+4+4+4/4 dha dha tee na • dha dha dhee na • dha dha ti te • dha dha tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha tee na •
ta ta tee na • ta ta tee na • ta ta ti te • ta ta tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha dhee na

4+4+4+4/4 dha dha ti te • dha dha dhee na • dhee na ti te • dhee na tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha tee na •
ta ta ti te • ta ta tee na • tee na ti te • tee na tee na •
dha dha ti te • dha dha dhee na • dha dha ti te • dha dha dhee na

4+4+4+4/4 dha dha ti te • dha dha dhee na • dha dha ti te • dha dha tee na •
tee na dhee na • dha dha ti te • dha dha ti te • dha dha tee na •
ta ta ti te • ta ta tee na • ta ta ti te • ta ta tee na •
tee na dhee na • dha dha ti te • dha dha ti te • dha dha dhee na

The "4+4+4+4/4" mark­ing at the start of each vari­a­tion indi­cates a lay­out most suit­able for musi­cians: the beats are sep­a­rat­ed by peri­ods ("." or "•"), with each beat con­tain­ing four strokes — hence the "/4".

The expres­sion "4+4+4+4" indi­cates that there are four lines, each con­tain­ing four beats. As expect­ed, the total dura­tion is 16 beats.

👉 An old, still-valid for­mat for "4+4+4+4/4" is "4+4+4+4*1/4".

Note that if Split ter­mi­nal sym­bols is unchecked, you get a more com­pact rep­re­sen­ta­tion, for instance:

4+4+4+4/4 dhad­hatite . dhad­had­heena . dhadha-- . tite­teena .
dhad­hatite . dhad­had­heena . dhad­hatite . dhad­ha­teena .
tatatite . tata­teena . tata-- . tite­teena .
dhad­hatite . dhad­had­heena . dhad­hatite . dhadhadheena

There is no guar­an­tee that all vari­a­tions will be dif­fer­ent. Another method that ensures this (at the cost of com­pu­ta­tion time) is to select "Produce all items" instead of "Non-stop improvize" in the set­tings. Now, the machine only keeps pro­duc­tions that have not been found in the list before.

Items pro­duced by this gram­mar can be copied to a Data project, here "-da.dhadhatite". The file in "ctests" con­tains eight vari­a­tions. Beware that items should be sep­a­rat­ed by emp­ty lines, which is auto­mat­i­cal­ly the case if you checked "Add lines between items" in the set­tings of "-gr.dhadhatite". In the set­tings of "-da.dhadhatite", check "Trace pro­duc­tion or pars­ing", then save the set­tings and data and click "Analyze" near the first item. The "trace file" dis­plays the detailed process which we won't com­ment. The "Show trace" but­ton dis­plays a summary:

4+4+4+4/4 dhad­hatite • dhad­had­heena • dheenatite • dheena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhad­ha­teena •
tatatite • tata­teena • teenatite • teena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhadhadheena

Template(s) found, posi­tion 3664
👉 We will try all tem­plates, as per your set­tings
Analyzing selec­tion…
Interpreting struc­ture…
Expanding poly­met­ric expres­sion…
Using quan­ti­za­tion = 10 ms with com­pres­sion rate = 1
Phase dia­gram con­tains 2 lines
👉 Item matched tem­plate [1]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [1] reject­ed by gram­mar… ❌
Result of failed analy­sis:
4+4+4+4/4 S1F +V8(= S1F) +S2F *(= S1F ++V8)(: S1F) S1F
👉 Item matched tem­plate [2]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [2] reject­ed by gram­mar… ❌
Result of failed analy­sis:
4+4+4+4/4 (= ++S2F) +V8 S1F +S2F *(: ++S2F) *(= ++V8) S1F S1F
👉 Item matched tem­plate [3]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [3] accept­ed by gram­mar… ✅
👉 Item matched tem­plate [4]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [4] reject­ed by gram­mar… ❌
Result of failed analy­sis:
4+4+4+4/4 (= ++S2F V4 +B4) S1F +S2F *(: ++S2F V4 +B4) S1F S1F
👉 Item matched tem­plate [5]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [5] reject­ed by gram­mar… ❌
Result of failed analy­sis:
4+4+4+4/4 (= ++S2F V6 +B2) S1F +S2F *(: ++S2F V6 +B2) S1F S1F
👉 Item matched tem­plate [6]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [6] reject­ed by gram­mar… ❌
Result of failed analy­sis:
4+4+4+4/4 (= ++S2F V8) S1F +S2F *(: ++S2F V8) S1F S1F

This sum­ma­ry trace shows that this vari­a­tion match­es all six tem­plates. However, only one leads to suc­cess­ful pars­ing, end­ing with the start string  "S". This helps deter­mine the syn­tac­tic struc­ture of the musi­cal exam­ple, in addi­tion to telling that it is "cor­rect".

The ini­tial beat and tem­po expres­sion "4+4+4+4/4" can be ignored. The fol­low­ing ver­sions will also be parsed successfully:

/4 dhad­hatite • dhad­had­heena • dheenatite • dheena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhad­ha­teena •
tatatite • tata­teena • teenatite • teena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhadhadheena

dhad­hatite • dhad­had­heena • dheenatite • dheena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhad­ha­teena •
tatatite • tata­teena • teenatite • teena­teena •
dhad­hatite • dhad­had­heena • dhad­hatite • dhadhadheena

dhad­hatit­ed­had­had­heenad­heenatit­ed­heena­teena
dhad­hatit­ed­had­had­heenad­had­hatit­ed­had­ha­teena
tatatite­tata­teena­teenatite­teena­teena
dhad­hatit­ed­had­had­heenad­had­hatit­ed­had­had­heena

dhad­hatit­ed­had­had­heenad­heenatit­ed­heena­teenad­had­hatit­ed­had­had­heenad­had­hatit­ed­had­ha­teenatatatite­tata­teena­teenatite­teena­teenad­had­hatit­ed­had­had­heenad­had­hatit­ed­had­had­heena

The "-gr.dhin--" grammar

This gram­mar describes two sets of vari­a­tions asso­ci­at­ed with the qa'ida. The first set cov­ers 16 beats, i.e. 96 strokes at a speed of 6 per beat. The sec­ond set cov­ers 32 beats, i.e. 192 strokes.

The 16-beat ver­sion was taught to Jim Kippen by Ustad Afaq Husain Khan in the 1980s. Within weeks, Jim had learned to iden­ti­fy the "lan­guage" of this qa‘ida, mean­ing that the machine suc­cess­ful­ly parsed all exam­ples pro­vid­ed by the expert musi­cian. However, at the end of the train­ing, when Afaq Husain Khan played the same qa‘ida in a con­cert, he delib­er­ate­ly expand­ed vari­a­tions to 32 beats. None of these were recog­nised by the gram­mar. Therefore, the gram­mar was adapt­ed to pro­duce 32-beat vari­a­tions, and its valid­i­ty was ver­i­fied by analysing the vari­a­tions per­formed at the concert.

Each set is rep­re­sent­ed by a vari­able named "S96" or "S192", cre­at­ed by sub­gram­mar #1:

RND
gram#1 [1] <0> S <-> 4+4/6 S96
gram#1 [2] <5> S <-> 4+4+4+4/6 S192

The weights of rules 0 and 5 indi­cate that the weights of the rules have been inferred from a set of exam­ples, five of which belonged to the S192 form and none of which belonged to the S96 form. We will imple­ment and explain weight infer­ence later.

The weights of rules 0 and 5 indi­cate that the weights of the rules have been inferred from a set of exam­ples, five of which belonged to the S192 form and none of which belonged to the S96 form. We will explain weight infer­ence later.

S192 and S96 are bro­ken down fur­ther into fixed or vari­able blocks in sub­gram­mar #2, which also intro­duces master-slave paren­the­ses and the open-closed homo­mor­phism notated "*":

RND
gram#2 [1] <5> S192 <-> (= F48 ) (= V24 ) F'24 *(: F48 ) (: V24 ) F24
gram#2 [2] <0> S96 <-> (= V24 ) F'24 *(: V24 ) F24
gram#2 [3] <0> V24 <-> (= V12 ) (: V12 )
gram#2 [4] <1> V24 <-> (= V12 ) *(: V12 )
gram#2 [5] <0> V24 <-> Q24
gram#2 [6] <0> V24 <-> V12 V12
gram#2 [7] <4> V24 <-> B24
gram#2 [8] <0> V12 <-> (= B6 ) *(: B6 )
gram#2 [9] <1> V12 <-> B12

Once again, we see that sev­er­al weight 0 rules have not been used to analyse the exam­ple set. No expla­na­tion is required for oth­er subgrammars.

Let's ask the machine to pro­duce ran­dom­ly 5 vari­a­tions using this gram­mar and rule weights to deter­mine their probabilities:

4+4+4+4/6 dhin--dhagena . dha--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
dheened­heena­ge­na . dhagenadhin-- . dheened­heena­ge­na . dheenedha-dheene .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
tin--takena . ta--takena . tatikeke­na­ka . teene­teenake­na .
take­ti­raki­ta . tin--takena . tatikeke­na­ka . teene­teenake­na .
dheened­heena­ge­na . dhagenadhin-- . dheened­heena­ge­na . dheenedha-dheene .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na

4+4+4+4/6 dhin--dhagena . dha--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
dhin--dhagena . dha--dhin-- . dheened­heena­ge­na . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
tin--takena . ta--takena . tatikeke­na­ka . teene­teenake­na .
take­ti­raki­ta . tin--takena . tatikeke­na­ka . teene­teenake­na .
dhin--dhagena . dha--dhin-- . dheened­heena­ge­na . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na

4+4+4+4/6 dhin--dhagena . dha--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dheened­heena­ge­na . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
tin--takena . ta--takena . tatikeke­na­ka . teene­teenake­na .
take­ti­raki­ta . tin--takena . tatikeke­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dheened­heena­ge­na . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na

4+4+4+4/6 dhin--dhagena . dha--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dheenedha-dheene . dhagenadhin-- .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
tin--takena . ta--takena . tatikeke­na­ka . teene­teenake­na .
take­ti­raki­ta . tin--takena . tatikeke­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dheenedha-dheene . dhagenadhin-- .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na

4+4+4+4/6 dhin--dhagena . dha--dhagena . dhatige­ge­na­ka . dheened­heena­ge­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dhatige­ge­na­ka . teene­teenake­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . teene­teenake­na .
tin--takena . ta--takena . tatikeke­na­ka . teene­teenake­na .
take­ti­raki­ta . tin--takena . tatikeke­na­ka . teene­teenake­na .
dhagenadha-- . dheened­heena­ge­na . dhatige­ge­na­ka . teene­teenake­na .
tage­ti­raki­ta . dhin--dhagena . dhatige­ge­na­ka . dheenedheenagena

The vari­a­tions dif­fer slight­ly. These sub­tle dif­fer­ences are intend­ed to cre­ate a "poet­ic" effect for lis­ten­ers famil­iar with the "lan­guage" of the tabla.

Create 16 tem­plates in the "-gr.dhin--" gram­mar. You will notice that the first eight cov­er 16 beats and the next eight cov­er 32 beats. This indi­cates that the cre­ation of tem­plates dis­re­gards rule weights and takes all rules in order. The same is true when cre­at­ing vari­a­tions with the "Produce all items" option.

A set of three 32-beat vari­a­tions is pro­vid­ed in the "-da.dhin--" Data project. You can check that all these vari­a­tions are suc­cess­ful­ly parsed. The pars­ing of the third item deserves our attention:

dhin--dhagena • dha--dhagena • dhatige­ge­na­ka • dheened­heena­ge­na •
tage­ti­raki­ta • dhin--dhagena • dhatige­ge­na­ka • teene­teenake­na •
dheened­heena­ge­na • dheened­heena­ge­na • teene­teenake­na • teene­teenake­na •
tage­ti­raki­ta • dhin--dhagena • dhatige­ge­na­ka • teene­teenake­na •
tin--takena • ta--takena • tatikeke­na­ka • teene­teenake­na •
take­ti­raki­ta • tin--takena • tatikeke­na­ka • teene­teenake­na •
dheened­heena­ge­na • dheened­heena­ge­na • teene­teenake­na • teene­teenake­na •
tage­ti­raki­ta • dhin--dhagena • dhatige­ge­na­ka • dheenedheenagena

👉 Item matched tem­plate [12]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [12] accept­ed by gram­mar… ✅
👉 Item matched tem­plate [13]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [13] accept­ed by gram­mar… ✅
👉 Item matched tem­plate [16]
Subgrammar 6/6
Subgrammar 5/6
Subgrammar 4/6
Subgrammar 3/6
Subgrammar 2/6
Subgrammar 1/6
Item match­ing tem­plate [16] reject­ed by grammar… ❌

In the set­tings of "-da.dhin--", the option "When pars­ing, check all tem­plates" is select­ed. This means that even after a suc­cess­ful analy­sis, the machine will try all the oth­er tem­plates. In this exam­ple, tem­plates [12] and [13] match the com­po­si­tion and both lead to suc­cess­ful pars­ing. Therefore, there is a syn­tac­tic ambi­gu­i­ty in this piece, which we may see as part of its "poet­ic" dimension.

This qa‘ida is dis­cussed in detail in our paper Modelling music with gram­mars: for­mal lan­guage rep­re­sen­ta­tion in the Bol Processor (Kippen & Bel, 1992, p. 15-17). The paper demon­strates the abil­i­ty of the mod­el to han­dle com­plex struc­tures by tak­ing real exam­ples from the reper­toire. It also ques­tions the rel­e­vance of attempt­ing to mod­el irreg­u­lar­i­ties encoun­tered in actu­al performance.

(For geeks) An appen­dix of our paper (page 21) explains the process of  context-sensitive canon­ic right­most deriva­tion  which is used for the parsing.