Author: Bernard Bel

Posted on

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 "<->" deriva­tion sign;
  • 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.;
  • 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.

(For geeks) The inter­face uses the is_true_bp($line) func­tion to check the grammar.

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 the gram­mar. Note that the tem­plate but­ton now appears as "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:

Selected: gram#2[1] X <-> a
(= a) X(: a)
Selected: gram#2[1] X <-> a
(= X) X(: X)
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] ________+________(@0 ________)+________ * (@0 ________++________)(@2 )________
[2] (@0 ++________)+________________+________ * (@1 ) * (@0 ++________)________________
[3] ________(@0 ______+__)________+________ * (@0 ________) * (@2 )________________
[4] (@0 ++____________+____)________+________ * (@1 )________________
[5] (@0 ++______________+__)________+________ * (@1 )________________
[6] (@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" sec­tions 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:
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:
(= ++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:
(= ++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:
(= ++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:
(= ++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 notat­ed "*":

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 (Kippen & Bel, 1992, appen­dix 3). 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.

References

Modelling music with gram­mars: for­mal lan­guage rep­re­sen­ta­tion in the Bol Processor. In A. Marsden & A. Pople (eds.): Computer Representations and Models in Music, London, Academic Press, 1992, p. 207-238.

Posted on

Derivation modes

 

Let us com­pare pro­duc­tions by the same gram­mar
“-gr.tryDerivationModes” in all deriva­tion modes.

The gram­mar com­pris­es two sub­gram­mars. The sec­ond one (gram#2) uses the ORD deriva­tion mode in all exam­ples. We show the trace of a deriva­tion and the result­ing production.

'A' and 'B' are vari­ables. 'a', 'b', 'e' and 'f' are ter­mi­nal sym­bols that are used to label sound objects.

[Derivation mode]
gram#1[1] S --> A B B A B B A
gram#1[2] A B --> a B
gram#1[3] B A --> B b
gram#1[4] B B A --> e B A
gram#1[5] B B --> f B

ORD
gram#2[1] f B --> f f
gram#2[2] e B --> e e
gram#2[3] A e --> c e

ORD

[Step #1] Selected: [1] LEFT S --> A B B A B B A
A B B A B B A
[Step #2] Selected: [2] LEFT A B --> a B
a B B A B B A
[Step #3] Selected: [2] LEFT A B --> a B
a B B a B B A
[Step #4] Selected: [3] LEFT B A --> B b
a B B a B B b
[Step #5] Selected: [5] LEFT B B --> f B
a f B a B B b
[Step #6] Selected: [5] LEFT B B --> f B
a f B a f B b
[Step #7] Selected: gram#2[1] LEFT f B --> f f
a f f a f B b
[Step #8] Selected: gram#2[1] LEFT f B --> f f
a f f a f f b

Result:  a f f a f f b

In this mode, the rules are applied in order and the rewrit­ing posi­tions are searched from left to right. This process is the fastest way to find a unique solution.

RND  (default deriva­tion mode)

[Step #1] Selected: [1] RND S --> A B B A B B A
A B B A B B A
[Step #2] Selected: [4] RND B B A --> e B A
A e B A B B A
[Step #3] Selected: [3] RND B A --> B b
A e B A B B b
[Step #4] Selected: [2] RND A B --> a B
A e B a B B b
[Step #5] Selected: [5] RND B B --> f B
A e B a f B b
[Step #6] Selected: gram#2[1] LEFT f B --> f f
A e B a f f b
[Step #7] Selected: gram#2[2] LEFT e B --> e e
A e e a f f b
[Step #8] Selected: gram#2[3] LEFT A e --> c e
c e e a f f b

Result:  c e e a f f b
More results:
a f f a f f b
a f f a e e b
a f f b f f b
a f f b e e b
a e e a f f b
a e e b f f b
a e e a e e b
a e e b e e b
a e e c e e b
a f f c e e b
c e e b f f b
c e e a e e b
c e e b e e b
c e e c e e b

Rules are select­ed at ran­dom, with prob­a­bil­i­ties depend­ing on their weights. The rewrit­ing posi­tion is also select­ed at ran­dom unless it is spec­i­fied as "LEFT" or "RIGHT."

LIN

[Step #1] Selected: [1] LEFT S --> A B B A B B A
A B B A B B A
[Step #2] Selected: [2] LEFT A B --> a B
a B B A B B A
[Step #3] Selected: [4] LEFT B B A --> e B A
a e B A B B A
[Step #4] Selected: [3] LEFT B A --> B b
a e B b B B A
[Step #5] Selected: [4] LEFT B B A --> e B A
a e B b e B A
[Step #6] Selected: [3] LEFT B A --> B b
a e B b e B b
[Step #7] Selected: gram#2[2] LEFT e B --> e e
a e e b e B b
[Step #8] Selected: gram#2[2] LEFT e B --> e e
a e e b e e b

Result:  a e e b e e b
More results:
a e e a f f b
a e e b e e b
a e e b f f b
a f f a e e b
a f f a f f b
a f f b e e b
a f f b f f b

Here, rules are select­ed at ran­dom but the rewrit­ing posi­tion is searched from left to right, unless it is spec­i­fied as "RIGHT" or "RND".

SUB

[Step #1] Selected: [1] RND S --> A B B A B B A
A B B A B B A
[Step #2] Selected: [2] RND A B --> a B
[Step #3] Selected: [4] RND B B A --> e B A
[Step #4] Selected: [2] RND A B --> a B
[Step #5] Selected: [4] RND B B A --> e B A
[Step #6] Selected: [3] RND B A --> B b
[Step #7] Selected: gram#2[2] LEFT e B --> e e
[Step #8] Selected: gram#2[2] LEFT e B --> e e

Result:  a e e a e e b

Here, all eli­gi­ble rules are applied at once. The process is repeat­ed until no rule is eligible.

SUB1

[Step #1] Selected: [1] LEFT S --> A B B A B B A
[Step #2] Selected: [2] LEFT A B --> a B
[Step #3] Selected: [2] LEFT A B --> a B
[Step #4] Selected: [3] LEFT B A --> B b
[Step #5] Selected: [5] LEFT B B --> f B
[Step #6] Selected: [5] LEFT B B --> f B
[Step #7] Selected: gram#2[1] LEFT f B --> f f
[Step #8] Selected: gram#2[1] LEFT f B --> f f

Result:  a f f a f f b

This is sim­i­lar to "SUB," except that rewrit­ing posi­tions are searched from left to right, and the set of eli­gi­ble rules is applied only once.

POSLONG

[Step #1] Selected: [1] LEFT S --> A B B A B B A
A B B A B B A
[Step #2] Selected: [2] LEFT A B --> a B
a B B A B B A
[Step #3] Selected: [4] LEFT B B A --> e B A
a e B A B B A
[Step #4] Selected: [2] LEFT A B --> a B
a e B a B B A
[Step #5] Selected: [4] LEFT B B A --> e B A
a e B a e B A
[Step #6] Selected: [3] LEFT B A --> B b
a e B a e B b
[Step #7] Selected: gram#2[2] LEFT e B --> e e
a e e a e B b
[Step #8] Selected: gram#2[2] LEFT e B --> e e

Result:  a e e a e e b

This is sim­i­lar to SUB1, except that rewrit­ings only occur in the posi­tions of the longest sub­strings matched by a rule.

Posted on

Silent sound-objects

In the cur­rent ver­sion of the Bol Processor, sound-objects con­tain either a stream of MIDI codes or a few lines of Csound score, or both. Each ter­mi­nal is either inter­pret­ed as either a sim­ple note (a NoteOn/NoteOff sequence) or linked to a sound-object, pro­vid­ed that one with the same name exists in a sound object descrip­tion file (e.g. "-so.MySounds").

When an item is played in real time using MIDI, a MIDI file or Csound, any ter­mi­nal not list­ed in the asso­ci­at­ed sound object descrip­tion file is ignored. The same applies to vari­ables that were not rewrit­ten or erased at the end of the pro­duc­tion process.

In ear­li­er ver­sions of BP3 (before 3.15), these unused sym­bols were erased before con­struct­ing the phase table con­tain­ing the list of sound events. At present, they are treat­ed as silent sound objects. While these objects car­ry nei­ther MIDI nor Csound instruc­tions, they have the same met­ric char­ac­ter­is­tics as a sim­ple note: a dura­tion of one unit, a piv­ot at the begin­ning for its loca­tion, and relocatability.

Silent sound-objects are of lit­tle or no util­i­ty in the MacOS, Windows and Linux imple­men­ta­tions of BP3. They are intend­ed for envi­ron­ments using the WebAssembly (WASM) archi­tec­ture. The idea is to use the Bol Processor's sophis­ti­cat­ed time-setting fea­tures to send the struc­ture to exter­nal devices and cre­ate sounds of great design. Read this page for more information.

Examples of data cre­at­ing silent sound-objects can be found in "-da.trySilentSoundObjects". The result­ing graphs are shown below.

The ter­mi­nal alpha­bet of this data project includes 'a', 'y', 'z', but only 'a' is found in "-so.trySilentSoundObjects". The note con­ven­tion is English.

z

'z' is treat­ed as a silent sound-object. It is dis­played as a hatched rec­tan­gle. Its dura­tion is 1 unit.

a z a C4

In this sequence, the silent sound-object 'z' occu­pies 1 unit but it does not pro­duce any sound.

a <<z>> a

Here, 'z' is an out-time silent sound-object (no dura­tion). No sound and no duration.

a <<a>> _tempo(2) z <<y>> a <<a>> C4

'z' has 1/2 beat dura­tion, due to the tem­po. 'y' is an out-time silent sound-object.

a Truc a

Variable 'Truc' is con­vert­ed to a silent sound-object. Its dura­tion is 1 unit.

{a Truc a, z C4}

In this poly­met­ric expres­sion, 'z' is resized to have the same sym­bol­ic dura­tion as C4.

a <<Truc>> z a

Variable 'Truc' is con­vert­ed to an out-time silent sound-object.

D4 z& a &z

Silent sound-object 'z' is tied to itself.
👉  Read the Tied notes page.

Truc& a &Truc

Variable 'Truc' is con­vert­ed to a silent sound-object and tied to itself.

The con­ver­sion of vari­ables to silent sound-objects may have an impact on gram­mars using sub­sti­tu­tion rules in which an erase rule can­not be used at each sub­sti­tu­tion. Check for instance "-gr.koto3":

Variable 'Y' hasn't been erased and it occu­pies a one-unit time seg­ment with­out pro­duc­ing any sound.

Posted on

Minimising a polymetric structure

👉 For geeks only!

This page is about the poly­met­ric nota­tion used in the Bol Processor project and, most like­ly, oth­er soft­ware envi­ron­ments. This advanced tool is used to rep­re­sent the time struc­ture of events, which can be sim­ple notes, sound-objects, or more gen­er­al­ly time-objects that can be instan­ti­at­ed as video frag­ments, sequences of robot­ic actions, and so on.

In a poly­met­ric struc­ture, rests (or 'silences') are rep­re­sent­ed by inte­ger ratios (their sym­bol­ic dura­tion), for exam­ple ‘6’ for "six beats" or '4 2/3' for "four and two third beats". Small inte­gers can be replaced with hyphens, for exam­ple '---' for '3'.

In some (but not all) poly­met­ric struc­tures, rests with explic­it dura­tions can be replaced with unde­ter­mined rests (notat­ed '…' or '_rest'), the val­ue of which is cal­cu­lat­ed by a (deter­min­is­tic) algo­rithm in the con­sole (file 'polymetric.c'). This is an impor­tant fea­ture because it enables the nota­tion to be sim­pli­fied with­out com­pro­mis­ing the accu­ra­cy of the time. Take a look at Charles Ames' exam­ple, for instance.

A poly­met­ric struc­ture con­tain­ing at least an unde­ter­mined rest is called 'min­imised" for this rea­son. Examples of min­imised struc­tures are found on the Polymetric struc­tures page.

The top­ic of this page is about 'revert­ing' the algo­rithm that assigns explic­it dura­tions to unde­ter­mined rests in the Bol Processor con­sole. Geeks will find this algo­rithm in the 'polymetric.c' file, and they can set the 'trace_und' vari­able to '1' to trace its operation.

Examples of minimisation

All exam­ples are found in the "-da.tryMinimise" data file (dis­trib­uted from the 3.3.6 ver­sion). Click the MINIMISE but­ton to min­imise all (eli­gi­ble) poly­met­ric expres­sions on the page.

Only poly­met­ric expres­sions between curled braces { } are processed.

The first exam­ple {2, C4 C4 --} will be min­imised as {2, C4 C4 …} where­as the sec­ond exam­ple {2, C4 C4 -} is not eli­gi­ble. The rea­son is that {2, C4 C4 …} is always instan­ti­at­ed as {2, C4 C4 --} (or {2, C4 C4 2}) and there is no min­imised ver­sion of {2, C4 C4 -}.

The third exam­ple {C4 D4 E4, A4 B4 F4 3 G4 A4 B4} is min­imised as {C4 D4 E4, A4 B4 F4 …G4 A4 B4}. Both ver­sions yield the fol­low­ing time structure:

For this demo, we use sim­ple notes with arbi­trary pitch­es in English nota­tion, as we are only focus­ing on the time structures.

The fol­low­ing exam­ples are not eli­gi­ble for a minimisation:

{C4 D4 E4, A4 B4 F4 1 G4 A4 B4}
{C4 D4 E4, A4 B4 F4 2 G4 A4 B4}
{C4 D4 E4, A4 B4 F4 4 G4 A4 B4}

It is not easy to guess which dura­tion of the rest — 1, 2, 3, 4 beats? — makes it eli­gi­ble for being unde­ter­mined. The cor­rect val­ue can be found by click­ing the EXPAND but­ton to the right of {C4 D4 E4, A4 B4 F4 … G4 A4 B4}. The first line of the result is the expand­ed poly­met­ric expression:

/1 {*1/1 C4 D4 E4,*1/3 A4 B4 F4 - _ _ G4 A4 B4}

The '- _ _ ' sequence is a rest of dura­tion 3 beats. The sym­bol '-' rep­re­sents a rest of one beat. This is fol­lowed by two pro­lon­ga­tions, '_'.

Note that the "expand­ed poly­met­ric expres­sion" dis­plays absolute tem­po mark­ers, such as '*1/3', to rep­re­sent the struc­ture, rather than rel­a­tive mark­ers, such as '__tempo(1/3)'. This rep­re­sen­ta­tion can be used for data, as was the case in ear­ly ver­sions of the Bol Processor.

Indeed, in this sim­ple exam­ple, the dura­tion was vis­i­ble on the graph. However, it becomes increas­ing­ly dif­fi­cult to mea­sure when rhyth­mic struc­tures become more com­pli­cat­ed. For exam­ple, {A4 F4 G4, … C4 D4 … E4} is expand­ed as:

/1 {*1/1 A4 F4 G4, *3/8 - *3/4 C4 D4 *3/8 - *3/4 E4}

It is not easy to fig­ure out that '*3/8 -' is a silence at twice the speed of '*3/4 C4', there­fore its (rel­a­tive) dura­tion is 1/2 and the struc­ture is equiv­a­lent to {A4 F4 G4, 1/2 C4 D4 1/2 E4}.

The process is more com­plex for fields of the poly­met­ric struc­ture that con­tain at least two rests with dif­fer­ent dura­tions. For example:

{C3 D3 E3, A5 5/4 B5 5/2 C5 5/4 D5}

The algo­rithm gen­er­ates a table of equiv­a­lent rests in chains, such as two 5/4 rests and one 5/2 rest. The table is sort­ed down on the num­ber of rests in each chain, which yields:

5/4 5/4
5/2

Then, each chain is con­sid­ered as a poten­tial solu­tion to the unde­ter­mined rest(s). The first one that meets the con­di­tions pro­vides the solu­tion. Here, it is "5/4 5/4", which yields:

{C3 D3 E3, A5 … B5 5/2 C5 … D5}

In this exam­ple, {C3 D3 E3, A5 5/4 B5 … C5 5/4 D5} is anoth­er solution.

If sev­er­al chains con­tain the same num­ber of units, the first accept­able one is giv­en as the solu­tion and the (deter­min­is­tic) algo­rithm ends. However, oth­er chains of max­i­mum length might also meet the con­di­tions. This means that the min­imi­sa­tion algo­rithm does not pro­vide all solu­tions, but at least it does pro­vide one which has the max­i­mum num­ber of unde­ter­mined rests.

Tracing the minimisation

The algo­rithm for min­imis­ing poly­met­ric struc­tures is more com­pli­cat­ed to design than the one for assign­ing explic­it dura­tions to unde­ter­mined rests. As per this writ­ing, it does not cov­er all cas­es. Updated ver­sions will be imple­ment­ed in the inter­face file 'data.php'.

If you need to fol­low the process while look­ing at the code, open the set­tings file and enter the item num­ber at the bot­tom of the form. In this exam­ple, we have cho­sen to trace the min­imi­sa­tion of item #30.

Don't for­get to save the set­tings and save again the Data page. Now, click the MINIMISE but­ton. You will get a trace that looks like this:

👉 { C3 D3 E3 , A5 5/4 B5 5/2 C5 5/4 D5 }
field #0 = 3/1 sounds, 3/1 beats, tem­po = 1/1
field #1 = 9/1 sounds, 9/1 beats, tem­po = 1/1
ref field = 0, dura­tion = 3/1 beats
sounds = 9/1
TRYING field #1, "A5 5/4 B5 5/2 C5 5/4 D5 "
—> ref_field = 0, token = "5/4", number_rests = 2, dura­tion = 5/2
➡ beats (3/1) - sounds (9/1) + rest dura­tion (5/2) = xp/xq = -7/2, number_rests = 2
case 1 —> beats[ref_field] = 3/1, sounds[field] = 13/4
pmax/qmax = 12/4, lcm = 4, psounds/qsounds = 13/4
mgap = 1, x = 1.0833333333333, p_therest (before adjust) = 5.5
p_therest (after adjust) = 5, q_therest = 4
[field #1 -> rest = 5/4]
GOT IT: "A5 _rest B5 5/2 C5 _rest D5" —> count_this = 2
Result = {C3 D3 E3 , A5 _rest B5 5/2 C5 _rest D5}

(This trace will dif­fer in sub­se­quent versions.)

.🛠 Work in progress .…. to be continued .….…

Posted on

A flexible environment for music composition in non-European contexts

Bernard Bel

Journées d'Informatique Musicale 1996, Caen (France)

Abstract

Most com­put­er music envi­ron­ments priv­i­lege music rep­re­sen­ta­tions derived from west­ern com­mon music nota­tion, which make it dif­fi­cult to explore musi­cal ideas based on dif­fer­ent con­cepts. This is notably the case with Indian com­posers eager to han­dle sophis­ti­cat­ed note treat­ment and com­plex polyrhyth­mic struc­tures. This paper presents recent devel­op­ments of a com­po­si­tion­al envi­ron­ment, Bol Processor BP2, address­ing the issue of abstract and com­pre­hen­sive, alto­geth­er flex­i­ble and accu­rate, music representations.

Sound examples

Broken links point to sound exam­ples, which can be found in this fold­er. Just replace 'mov' exten­sions with 'mp3'.

Download this paper

Seven radical ideas from an old music software that are still revolutionary today

This blog post was cre­at­ed with the help of NotebookLM (November 2025)

👉 In the fol­low­ing text, "BP2" is the old acronym for "Bol Processor". It can be replaced with "BP3".

Introduction: The Unseen Blueprint of Digital Music

Open any mod­ern music pro­duc­tion app, and you’re greet­ed by a famil­iar land­scape: a piano roll, a time­line divid­ed into bars and beats, and tools designed to place dis­crete notes on a grid. This envi­ron­ment is so uni­ver­sal that we rarely ques­tion its foun­da­tions. We treat it as a neu­tral can­vas for creativity.

But what if it isn’t? What if the very archi­tec­ture of our dig­i­tal tools—the twelve-tone scale, the rigid tim­ing, the con­cept of a sin­gle "note"—is a cul­tur­al box, sub­tly shap­ing our music to fit a Western mod­el? For musi­cians from tra­di­tions with dif­fer­ent melod­ic and rhyth­mic philoso­phies, this isn't just a hypo­thet­i­cal ques­tion. It's a dai­ly cre­ative hur­dle. A fas­ci­nat­ing piece of 1990s soft­ware called Bol Processor BP2 offered a rad­i­cal­ly dif­fer­ent path, and its core con­cepts are more rel­e­vant today than ever. This is a look at the most mind-bending ideas from a pro­gram that dared to think out­side the grid.

1. Our Digital Tools Have a Western Accent

The cen­tral prob­lem that Bol Processor BP2 set out to solve is that most music soft­ware is built on a foun­da­tion of Western com­mon music nota­tion. It priv­i­leges the twelve-tone sys­tem and the bina­ry divi­sion of time (whole notes, half notes, quar­ter notes, etc.). This isn't just about the on-screen inter­face; as the source text notes, the MIDI stan­dard itself helps "rein­force this con­ven­tion­al approach," mak­ing it a sys­temic bias built into the very plumb­ing of dig­i­tal music. This design choice cre­ates an imme­di­ate and pro­found chal­lenge for com­posers from oth­er musi­cal worlds, such as India, who want to express the "melod­ic sub­tleties and rhyth­mic intri­ca­cies of their musi­cal heritage."

When the tools don't match the tra­di­tion, the music itself is com­pro­mised. In a com­mer­cial set­ting, this can lead to a prob­lem­at­ic for­mu­la where tra­di­tion­al instru­ments are reduced to a mere "masala ingre­di­ent" sprin­kled on top of a gener­ic elec­tron­ic track. The expres­sive depth of the orig­i­nal music is lost because the under­ly­ing dig­i­tal skele­ton can't sup­port it. This isn't a fail­ure of the musi­cian, but a lim­i­ta­tion of the tool. A new approach wasn't just a tech­ni­cal chal­lenge; it was a cul­tur­al necessity.

2. The Big Idea: Treating Music Like Vector Graphics, Not Pixels

To break free from the Western frame­work, BP2’s cre­ators re-imagined the very nature of musi­cal data. They drew a dis­tinc­tion between "descrip­tive" and "pre­scrip­tive" nota­tion, using a pow­er­ful anal­o­gy from graph­ic design.

  • Descriptive nota­tion is like a "pix­el" image. To cre­ate a curve, you must explic­it­ly define the col­or and posi­tion of every sin­gle pix­el along its path. In music, this is like using a stan­dard sequencer to cre­ate a del­i­cate Indian melod­ic pat­tern (gama­ka), where the com­pos­er must man­u­al­ly pro­gram every sin­gle micro­ton­al "PitchBend" mes­sage. It’s clum­sy, com­pu­ta­tion­al­ly inef­fi­cient, and fails to cap­ture the holis­tic ges­ture of the musi­cal idea.
  • BP2's approach is like "vec­tor" graph­ics. Instead of defin­ing pix­els, a vector-based pro­gram uses math­e­mat­i­cal descriptions—a start­ing point, an end­ing point, and the shape of the curve in between. BP2 applies this log­ic to music. It uses abstract, effi­cient rep­re­sen­ta­tions to gen­er­ate com­plex and accu­rate musi­cal shapes with­out need­ing to define every sin­gle point.

This shift is more than just an effi­cien­cy hack; it's a philo­soph­i­cal one. A vec­tor encodes the composer's intent—the idea of a gesture—while pix­els mere­ly describe a sta­t­ic, unchange­able result. This con­cep­tu­al leap is the key to BP2's pow­er, offer­ing immense cre­ative free­dom and efficiency.

3. Beyond the "Note": Learning from Indian Drum Syllables

In Western music, the "note" is the fun­da­men­tal build­ing block. But BP2 pro­posed a more flex­i­ble and musi­cal­ly intu­itive unit: the "sound-object." This con­cept was derived direct­ly from the study of North Indian tabla drum­ming, where ono­matopoe­ic syl­la­bles called bols are used to rep­re­sent com­plex rhyth­mic gestures.

The cre­ators of BP2 observed that tabla play­ers don't think in indi­vid­ual sounds. A com­plex phrase like ‘tiraki­ta’ (four strokes) isn't four sep­a­rate events; it's one con­cep­tu­al unit, a sin­gle word in a rhyth­mic lan­guage. The same is true for a sim­pler phrase like ‘tira’ (two strokes). BP2 was built to hon­or this, treat­ing such ges­tures as a sin­gle, indi­vis­i­ble "sound-object." This allows a com­pos­er to work with musi­cal­ly mean­ing­ful phras­es as the pri­ma­ry mate­r­i­al, rather than being forced to con­struct every­thing from a series of iso­lat­ed, atom­ized events. It's the dif­fer­ence between writ­ing with words instead of indi­vid­ual letters.

Definition: A time-object is a basic sequence of mes­sages (e.g., MIDI NoteOn/NoteOff). When this sequence is assigned met­ri­cal and topo­log­i­cal prop­er­ties, it becomes a sound-object, which can rep­re­sent an ele­men­tary musi­cal ges­ture or its result­ing sound.

Key Properties of Sound-Objects
  •     Metrical: Defines how a sound-object's inter­nal tim­ing adjusts to tem­po. For exam­ple, the four strokes in 'tiraki­ta' may be forced to main­tain equal spac­ing, which changes with the over­all tempo.
  •     Topological: Governs how sound-objects can be trun­cat­ed or over­lapped to cre­ate real­is­tic phrasing.
  •     Pivot: A spe­cif­ic time point with­in the sound-object that is anchored to a musi­cal pulse or "time streak."
  •     Relocatable: An object that can be shift­ed freely in time.
Special Types
  •     Out-time Sound-Objects: Have a null dura­tion, with all con­stituent mes­sages dis­patched simultaneously.
  •     Input Objects: Time-objects with null dura­tion that wait for an exter­nal input (MIDI note, mouse click) to facil­i­tate basic real-time synchronization.

4. Time Management

BP2 pro­vides sophis­ti­cat­ed tools for struc­tur­ing both pulsed and non-pulsed musi­cal time.

  • Striated vs. Smooth Time: The sys­tem han­dles both stri­at­ed time (built on reg­u­lar or irreg­u­lar puls­es) and smooth time (where no pulse is nec­es­sary, e.g., the alap of Indian music).
  • Time-Patterns: In smooth time, users can define arbi­trary phys­i­cal time ratios using spe­cial time-objects (t1, t2, etc.) to cre­ate a spe­cif­ic tem­po­ral structure.
  • Time-Base: An inter­nal clock cal­cu­lates phys­i­cal dura­tions. It can be set via a metronome val­ue or with absolute accu­ra­cy (e.g., a num­ber of ticks in a giv­en num­ber of sec­onds). It can also pro­duce audi­ble tick pat­terns with super­im­posed cycles (e.g., cycles of 4, 5, and 7).

5. Taming Complex Rhythms with a Single Dot

Creating com­plex rhyth­mic cycles and sub­di­vi­sions in stan­dard soft­ware can be a tedious process of click­ing, drag­ging, and set­ting grid val­ues. BP2’s solu­tion evolved into an aston­ish­ing­ly sim­ple text-based sys­tem. The old­er syn­tax was func­tion­al but rigid, using explic­it mark­ers like /2 or /3 to force absolute tem­po assign­ments: /1 a b c /2 a b c d e f. This was inflex­i­ble because these sequences couldn't be eas­i­ly reused as build­ing blocks in new con­texts with­out man­u­al recalculation.

The rev­o­lu­tion­ary solu­tion was "peri­od nota­tion." By con­nect­ing sym­bols with a peri­od (.), a com­pos­er can cre­ate beats of equal sym­bol­ic dura­tion, and the soft­ware auto­mat­i­cal­ly cal­cu­lates the sub­di­vi­sions. Consider this sim­ple line of text:

a.b.c.ab.cd.abc.def

Without any com­plex com­mands, this nota­tion intu­itive­ly rep­re­sents a rhyth­mic accel­er­a­tion. It starts with one note per beat (a.b.c.), pro­gress­es to two notes per beat (ab.cd.), and fin­ish­es with three notes per beat (abc.def). In the lan­guage of North Indian music, this ele­gant­ly describes a pro­gres­sion from har­gun (speed 1), to dogun (speed 2), and final­ly to tigun (speed 3). This plain-text syn­tax pro­vides a flu­id and pow­er­ful way to build intri­cate rhyth­mic struc­tures that would be incred­i­bly cum­ber­some to cre­ate in a con­ven­tion­al point-and-click interface.

Period nota­tion can of course be com­bined with poly­met­ric struc­tures for simul­tane­ity (see 6).

How to Compose Backwards in Time

Perhaps the most sur­pris­ing and pow­er­ful fea­ture of BP2 is its abil­i­ty to solve a com­po­si­tion­al prob­lem that feels like work­ing in reverse. In poly­met­ric music, dif­fer­ent per­form­ers play in dif­fer­ent time sig­na­tures or rhyth­mic cycles simul­ta­ne­ous­ly. A com­mon chal­lenge is mak­ing sure every­one, despite their dif­fer­ent paths, resolves togeth­er at the very end.

This was exact­ly the prob­lem faced in Andréine Bel's 1994 dance pro­duc­tion "Cronos" (read 765432). The piece fea­tured six dancers—Suresh, Smriti, Olivier, and others—performing parts based on dif­fer­ent rhyth­mic cycles. Suresh count­ed in 7s, Smriti in 6s, Olivier in 5s, and so on. The chore­og­ra­phy demand­ed that they all fin­ish at the exact same moment. Calculating the pre­cise start­ing points and rests to achieve this would be a math­e­mat­i­cal nightmare.

BP2’s solu­tion was a fea­ture called "unde­ter­mined rests," notat­ed sim­ply as "...". A com­pos­er could place this sym­bol at the begin­ning of each part, and the soft­ware itself would cal­cu­late the pre­cise dura­tion of silence need­ed for all the dif­fer­ent rhyth­mic cycles to align per­fect­ly at their con­clu­sion. The sys­tem had one log­i­cal con­straint: each part of the struc­ture could con­tain at most one unde­ter­mined rest. This fea­ture allowed the com­pos­er to define the end point and let the machine fig­ure out the beginning.

A musi­cian right­ly iden­ti­fied this tech­nique as "work­ing on reversed time", a prob­lem that is cru­cial in Indian rhythm.

6. Polymetric Structures for Simultaneity

  • The Comma Operator: The , (com­ma) oper­a­tor indi­cates simul­tane­ity. An expres­sion like {A, B, C} means that the musi­cal expres­sions A, B, and C (called fields) are per­formed together.
  • Duration Matching: The inter­preter uses the same algo­rithm to match sym­bol­ic dura­tions in poly­met­ric struc­tures as it does for sequen­tial ones, ensur­ing alignment.
  • Duration Precedence: By con­ven­tion, the dura­tion of a poly­met­ric expres­sion is deter­mined by its left­most field. For exam­ple, {abc,de} has a dura­tion of three beats, while {de,abc} has a dura­tion of two.

Read more on this top­ic …

7. Advanced Performance Control

BP2 includes a macro lan­guage of approx­i­mate­ly 200 instruc­tions for automat­ing process­es and con­trol­ling per­for­mance para­me­ters with a "vec­tor­ized" approach.

  • Stepwise Control: Parameter val­ues change from one sound-object to the next.
  •  Example (Articulation): The _staccato(x) and _legato(x) instruc­tions mod­i­fy the dura­tion of sub­se­quent sound-objects by a per­cent­age. These val­ues can be inter­po­lat­ed across a musi­cal phrase.
  • Continuous Control: Parameter val­ues are changed via lin­ear inter­po­la­tion between spec­i­fied points. This is high­ly effi­cient, as it avoids stor­ing mas­sive streams of MIDI data.
  • Example (Microtonal Pitch): The _pitchbend(x) instruc­tion, when com­bined with _pitchcont, cre­ates smooth por­ta­men­ti. The pitch val­ues can be spec­i­fied in cents if a pitch ben­der range is defined (_pitchrange(r)), mak­ing micro­ton­al work intuitive.
  • Independent Control in Polymetric Structures: Different fields with­in a poly­met­ric struc­ture can have inde­pen­dent, simul­ta­ne­ous para­me­ter changes. For exam­ple, two melod­ic lines can exe­cute dif­fer­ent micro­ton­al pitch bends at the same time, pro­vid­ed they are assigned to sep­a­rate MIDI channels.

Conclusion: Looking Beyond Our Creative Code

The true inno­va­tion of Bol Processor BP2 wasn't just its clever fea­tures, but its fun­da­men­tal phi­los­o­phy. Instead of sim­ply dig­i­tiz­ing the con­ven­tions of an exist­ing musi­cal tra­di­tion, it built a cre­ative envi­ron­ment from abstract, culturally-aware prin­ci­ples. It acknowl­edged that the tools we use are not neu­tral; they car­ry inher­ent bias­es that shape what we can eas­i­ly create.

BP2 is a pow­er­ful reminder to look at the assump­tions embed­ded in our own cre­ative soft­ware. In a world increas­ing­ly shaped by AI and algo­rithms that learn from exist­ing data, what oth­er cul­tur­al blue­prints are being baked into our tools? What new forms of art, music, and expres­sion are we fail­ing to imag­ine sim­ply because our dig­i­tal can­vas wasn't designed to sup­port them?

View Fullscreen
Skip to PDF content

Posted on

AI recognition of polymetric notation

The aim of the cur­rent project is to tran­scribe a musi­cal input (giv­en by a stream or a table of MIDI events) to the most com­pre­hen­si­ble poly­met­ric nota­tion. An exten­sion of this would indeed be to accept a sound sig­nal as input.

Polymetric nota­tion is one of the main fea­tures of the Bol Processor project, which is here con­sid­ered as musi­co­log­i­cal research rather than soft­ware devel­op­ment. Other fea­tures include tonal mod­el­ling and the time-setting of sound-objects.

Polymetric expres­sions are a con­ve­nient prod­uct of rule-based music com­po­si­tion. They are rep­re­sent­ed as strings of sym­bols that embody a semi-lattice struc­ture, here mean­ing a tree of sound objects with ties. Polymetric nota­tion, gen­er­al­ly speak­ing, is a sequence of poly­met­ric expres­sions that is processed as a sin­gle poly­met­ric expression.

(just for decoration)

To achieve this, we plan to train a trans­former (a type of neur­al net­work), using sets of poly­met­ric expres­sions along­side their asso­ci­at­ed MIDI file ren­der­ings, both as stan­dard MIDI files and in tables of events. As we require large datasets that cov­er a wide range of musi­cal styles, the plan is to cre­ate these sets using exist­ing musi­cal scores.

The process described on the Importing MusicXML scores page demon­strates the abil­i­ty to "trans­late" any Western musi­cal score (in its dig­i­tal for­mat) to a poly­met­ric expres­sion. This process is irre­versible because poly­met­ric expres­sions can­not be ful­ly con­vert­ed into human-readable musi­cal scores, despite them car­ry­ing time struc­tures that sound "musi­cal". A typ­i­cal exam­ple of this is the use of unde­ter­mined rests, as these imply fur­ther pro­cess­ing of the struc­ture in order to set exact durations.

Datasets that asso­ciate poly­met­ric expres­sions with their MIDI file ren­der­ings con­tain iden­ti­cal pitch and tim­ing infor­ma­tion on both sides. Since both descrip­tions are com­plete and not redun­dant, the match­ing is a game of full infor­ma­tion.

At a lat­er stage, the trans­former should also be able to han­dle streams of MIDI events cre­at­ed by humans or ran­dom effects, where the tim­ings are not based on a sim­ple frame­work. Therefore, a quan­ti­za­tion of tim­ings is need­ed to adjust the stream before it is analysed. This quan­ti­za­tion is already oper­a­tional on the Bol Processor — see the Capture MIDI input page.

The creation of datasets

Datasets are cre­at­ed from musi­cal works import­ed from MusicXML scores. For instance:

Click the CREATE DATASET FOR AI button.

A dataset is cre­at­ed and can be down­loaded in a zip file:
set_-da.Hungarian_Rhapsody_OguzSirin.zip.

More sets can be cre­at­ed using the same musi­cal work. Clicking the CREATE DATASET FOR AI but­ton again would pro­duce the same set, as it is built from a sequence of ran­dom num­bers that is not reini­tialised. To ensure the new set is dif­fer­ent, click the refresh but­ton. When down­load­ing it, the sys­tem will auto­mat­i­cal­ly assign it a dif­fer­ent name, e.g.:
set_-da.Hungarian_Rhapsody_OguzSirin (1).zip.

Datasets of minimised polymetric structures

The mini but­ton close to the refresh but­ton mod­i­fies the dataset so that all (eli­gi­ble) poly­met­ric struc­tures are min­imised. In a min­imised struc­ture, some rests with explic­it dura­tions are replaced with unde­ter­mined rests (notat­ed '…') with­out any loss of tim­ing accu­ra­cy. Read the Minimising a poly­met­ric struc­ture page for more details. These sets are small­er in size than the ones they are derived from because only eli­gi­ble struc­tures have been retained.

Once sam­ples in the train­ing set have been min­imised, the CREATE DATASET FOR AI but­ton is changed to CREATE min­imised DATASET FOR AI.

The sets of min­imised struc­tures are down­loaded with spe­cif­ic names that men­tion the 'mini' fea­ture, such as:
set_-da.Hungarian_Rhapsody_OguzSirin_mini.zip

When train­ing an AI, these sets should be used sep­a­rate­ly from stan­dard sets because they are expect­ed to train the trans­former to guess the prop­er loca­tions of unde­ter­mined rests. Nevertheless, it could be inter­est­ing to com­pare relat­ed (stan­dard ver­sus min­imised) sam­ples in order to mod­el changes between stan­dard and min­imised poly­met­ric structures.

The content of a dataset

The first dataset cre­at­ed in this demo con­tains 160 sam­ples. These sam­ples are text files named 1.txt, 2.txt, etc., asso­ci­at­ed with MIDI files 1.mid, 2.mid, etc., and tables of events (see below) 1.tab, 2.tab, etc., 1.tsv, 2.tsv, etc. A text file whose name ends in "_units.txt" con­tains all the sam­ple text files, enabling these sam­ples to be copied in a sin­gle piece to a data project. Clicking on the word "sam­ples" dis­plays it in a pop-up window.

One of the text files con­tains for instance:

{_tempo(4/3) _vel(85){2,{3/16,D6& E6& D7&}{3/16,&D6,&E6,&D7}{1/8,C6,C7}{3/8,B5,B6}{1/8,A5,A6}{3/8,G#5,G#6}{1/8,A5,A6}{3/8,B5,B6}{1/8,G#5,G#6},{3/8,G#3}{1/8,D4}{3/8,B4}{1/8,E4}{3/8,E3}{1/8,B3}{3/8,G#4}{1/8,E4}}} {_tempo(4/3) _vel(85){2,{3/8,A5,A6}{1/8,G#5,G#6}{3/8,A5,A6}{1/8,B5,B6}{3/8,C6,C7}{1/8,B5,B6}{3/8,C6,C7}{1/8,D6,D7},{3/8,A3}{1/8,D4}{3/8,C5}{1/8,A4}{3/8,E3}{1/8,C4}{3/8,A4}{1/8,E4}}}

This poly­met­ric expres­sion cov­ers 2 mea­sures of the musi­cal score. Clicking the Refresh but­ton (or reload­ing the page) slices the score ran­dom­ly into chunks con­tain­ing between 1 and 5 mea­sures. The upper lim­it of 5 has been set arbi­trar­i­ly and may be revised at a lat­er date. Every time the Refresh but­ton is clicked, a new slice is cre­at­ed, result­ing in a dif­fer­ent dataset.

The idea is twofold: (1) the trans­former should be trained to recog­nise sequences of poly­met­ric expres­sions, and (2) tied notes may span more than one mea­sure. A tied note in the above exam­ple is the pair "D6& &D6" (read more). Each sam­ple con­tains only com­plete pairs of tied notes. This means that any notes whose ties are not present in the sam­ple are untied for the sake of consistency.

Note that the tim­ings of the poly­met­ric expres­sion and the MIDI file are iden­ti­cal, as the metronome is auto­mat­i­cal­ly set to a default tem­po of 60 beats per minute when the MIDI file sam­ples are cre­at­ed. In the above phrase, the tem­po is set to 4/3, which is equiv­a­lent to a metronome set at 80 bpm.

Tables of events

The tables of events pro­vide an easy-to-read rep­re­sen­ta­tion of the con­tents of MIDI files.

Two kinds of text files are created.

1) The file with exten­sion "tab" lists MIDI events in four columns. The left­most col­umn con­tains the tim­ing of each event in mil­lisec­onds. For instance, the fol­low­ing text (from Couperin's Les Ombres errantes):

{_vel(64) {25/6, D5 1/6 {2, G5} F5, {25/6, C5 B4 4/3 B4& &B4 C5& &C5 C5&}, {25/6, G3 1/6 G4 {1/8, Ab4 G4} {7/8, Ab4} _legato(20) A4}}} {_vel(64) {4, {2, &C5 D5& &D5 _legato(20) C5} _legato(0) C5 {1, B4 {2, C5 B4 A4} B4}, F5 Eb5 {1/8, _legato(20) Eb5} {7/8, _legato(0) D5} 1, _legato(0) {1/8, B4 A4} {7/8, B4} C5 F4 G4}} {_tempo(9/10) _vel(64) {4, {G4, C5} Eb4 {1, D4 1} _tempo(26/27) Eb4, Eb4 {3, 1 C4& &C4 B3 1 C4}, C4 C3 G2 C3}}

which can be min­imised to:

{_vel(64) {25/6,D5 … {2,G5}F5,{25/6,C5 B4 … B4& &B4 C5& &C5 C5&},{25/6,G3 … G4 {1/8,Ab4 G4}{7/8,Ab4}_legato(20) A4}}}{_vel(64) {4,{2,&C5 D5& &D5 _legato(20) C5}_legato(0) C5 {1,B4 {2,C5 B4 A4}B4},F5 Eb5 {1/8,_legato(20) Eb5}{7/8,_legato(0) D5}1,_legato(0) {1/8,B4 A4}{7/8,B4}C5 F4 G4}}{_tempo(9/10) _vel(64) {4,{G4,C5}Eb4 {1,D4 1}_tempo(26/27) Eb4,Eb4 {3,1 C4& &C4 B3 - C4},C4 C3 G2 C3}}

is con­vert­ed to:

0 144 74 64
0 144 72 64
0 144 55 64
500 128 72 0
500 144 71 64
1000 128 74 0
1000 128 55 0
1001 128 71 0
1165 144 79 64
1165 144 67 64
1666 144 71 64
etc.

The "tab" table con­tains only NoteOn/NoteOff events. However, the MIDI file may con­tain con­trols, such as vol­ume, panoram­ic, pres­sure, pitch­bend, mod­u­la­tion, ped­al on/off, and more in the range 65 to 95, which are per­for­mance para­me­ters in the Bol Processor score. Therefore, a more detailed for­mat of tables of events is need­ed to list them.

2) The text file with exten­sion "tsv" con­tains a detailed list of (all) MIDI events car­ried by the MIDI file.

The fol­low­ing exam­ple is the open­ing of Listz's La Campanella.

{_tempo(97/60) _vel(52) {3,2 {1/2,D#6,D#7} {1/2,D#6,D#7},1/2 {1/2,_switchon(64,1) D#4,D#5} {1/2,D#4,D#5} {1/2,D#4,D#5} 1}} {_tempo(97/60) _vel(52) {3,{1/2,D#6,D#7} 3/2 {1/2,D#6,D#7} {1/2,D#6,D#7},1/2 {1/2,_switchoff(64,1) _switchon(64,1) D#4,D#5} {1/2,D#4,D#5} {1/2,D#4,D#5} -}}

Screenshot
Note that at time 1866ms, the ped­al is released and pushed again imme­di­ate­ly, as indi­cat­ed in the score below. The source is '0' by default and can be mod­i­fied by _part() con­trol parameters.
Note that the ped­al remains pressed at the end of this frag­ment, as indi­cat­ed in the "tsv" table.

Since the Bol Processor can cap­ture a MIDI stream and cre­ate a "tsv" table of events with quan­tized tim­ings (see Capture MIDI input), train­ing a trans­former to con­vert these tables into poly­met­ric struc­tures could elim­i­nate the need to decrypt MIDI files and quan­tize their timings.

A collection of datasets

Several col­lec­tions of datasets can be found in the fold­er:
https://bolprocessor.org/misc/AI/samples

These can be used for train­ing a trans­former of your choice. We rec­om­mend cre­at­ing more sets from more musi­cal works to achieve a bet­ter train­ing. Run the Bol Processor and browse import­ed MusicXML scores in the ctests/Imported_MusicXML work­space, or import more works from a ded­i­cat­ed MusicXML server.

A test of the transformer's abil­i­ty to "trans­late" MIDI files (or tables of events) to poly­met­ric nota­tion will first be to retro-convert (to poly­met­ric expres­sions) all sam­ples. Then, if suc­cess­ful, retro-convert the MIDI files of com­plete musi­cal works used for the training.

What follows…

Once the cor­rect trans­former type and opti­mum dataset size have been iden­ti­fied, we will work on the fol­low­ing extensions:

  1. Translate MIDI streams pro­duced by human inter­preters for which pre­cise tim­ing is not guaranteed.
  2. (Optional) Extend the AI recog­ni­tion to the use of unde­ter­mined rests as it pro­vides a more sim­ple poly­met­ric structure.
  3. Use a sound to MIDI con­vert­er to con­vert a sound input to poly­met­ric notation.
  4. Let us assume that the musi­cal input con­sists of frag­ments sep­a­rat­ed by silences. Convert these frag­ments into poly­met­ric struc­tures and then search for reg­u­lar­i­ties in the rhyth­mic and tonal struc­tures to cre­ate vari­a­tions in the same style. Formal gram­mars will be employed for this purpose.

🛠 Work in progress! Please con­tact us to participate.

Posted on

Acquisition et représentation de connaissances en musique

Bernard Bel

Knowledge acquisition and representation in music

Thèse de doc­tor­at en sci­ences. Université de droit, d'économie et des sci­ences - Aix-Marseille III
https://theses.hal.science/tel-00009692

Résumé

Cette étude traite de la représen­ta­tion infor­ma­tique de con­nais­sances en musique, abor­dée à par­tir de deux expéri­ences en grandeur réelle. La pre­mière est une méth­ode d'acquisition de con­nais­sances en ethno­gra­phie met­tant en inter­ac­tion un expert (le musi­cien), un ana­lyste (le musi­co­logue) et une machine dans une sit­u­a­tion d'apprentissage. Les sché­mas d'improvisation des musi­ciens sont iden­ti­fiés et exprimés à l'aide de règles de pro­duc­tion dans un for­mal­isme dérivé des gram­maires généra­tives et des lan­gages de formes. Un algo­rithme déter­min­iste de test d'appartenance de chaînes arbi­traires au lan­gage défi­ni par une gram­maire (sen­si­ble au con­texte) est présen­té, ain­si qu'une tech­nique d'inférence induc­tive de lan­gages réguliers per­me­t­tant l'acquisition automa­tique de con­nais­sances lex­i­cales et syn­tax­iques. La sec­onde expéri­ence s'insère dans l'élaboration d'un envi­ron­nement de com­po­si­tion musi­cale assistée par ordi­na­teur. Le prob­lème est ici la représen­ta­tion du temps dans une struc­ture dis­crète d'“objets tem­porels”, et plus générale­ment la syn­chro­ni­sa­tion de proces­sus par­al­lèles. Une méth­ode est pro­posée pour la déter­mi­na­tion d'une struc­ture à par­tir de don­nées incom­plètes sur la syn­chro­ni­sa­tion des objets. La notion d'“objet sonore” est ensuite explic­itée formelle­ment. Un algo­rithme effi­cace per­met l'instanciation des objets sonores affec­tés à une struc­ture en ten­ant compte des con­traintes liées à leurs pro­priétés métriques et topologiques.

Excerpts of an AI review of this paper (Claude AI, June 2025)

Summary

This 1990 doc­tor­al the­sis presents an inno­v­a­tive approach to com­put­er rep­re­sen­ta­tion of musi­cal knowl­edge through two major exper­i­men­tal frame­works. The work bridges arti­fi­cial intel­li­gence, for­mal lan­guage the­o­ry, and musi­col­o­gy, address­ing fun­da­men­tal prob­lems in knowl­edge acqui­si­tion and time rep­re­sen­ta­tion in musi­cal structures.

First Experiment: Knowledge Acquisition in Ethnography

The first part intro­duces a nov­el method­ol­o­gy for acquir­ing musi­cal knowl­edge through a "dialec­ti­cal anthro­pol­o­gy" approach involv­ing three actors: an expert musi­cian, a musicologist-analyst, and a com­put­er sys­tem. This method­ol­o­gy was applied to study­ing impro­vi­sa­tion pat­terns (qa'ida) of North Indian tabla per­cus­sion music.

Key Contributions

  • Development of BP (Bol Processor) gram­mars, an exten­sion of for­mal gram­mars capa­ble of rep­re­sent­ing rep­e­ti­tion pat­terns and homo­mor­phic transformations
  • A deter­min­is­tic mem­ber­ship test algo­rithm for a sub­class of context-sensitive grammars
  • An induc­tive infer­ence tech­nique for reg­u­lar lan­guages that simul­ta­ne­ous­ly acquires lex­i­cal and syn­tac­tic knowledge
  • Introduction of neg­a­tive con­text rules and sto­chas­tic con­trol mechanisms

The sys­tem enables musi­cians to val­i­date machine-generated musi­cal phras­es, cre­at­ing a feed­back loop that refines gram­mat­i­cal mod­els of impro­vi­sa­tion schemas. The approach moves beyond tra­di­tion­al ethno­graph­ic col­lec­tion by mak­ing the com­put­er an active part­ner in knowl­edge acquisition.

Second Experiment: Computer-Assisted Musical Composition

The sec­ond part address­es time rep­re­sen­ta­tion and syn­chro­niza­tion in dis­crete musi­cal struc­tures, devel­op­ing the BP2 envi­ron­ment for musi­cal composition.

Key Innovations

  • Introduction of "sym­bol­ic time" as dis­tinct from phys­i­cal time
  • Development of poly­met­ric for­mu­las for rep­re­sent­ing par­al­lel musi­cal sequences
  • Formal treat­ment of "time objects" and "out-time objects" (tem­po­ral vs. atemporal)
  • An effi­cient algo­rithm for syn­chro­niz­ing sequences with incom­plete tem­po­ral information
  • A con­straint sat­is­fac­tion approach to "sound object" instan­ti­a­tion con­sid­er­ing met­ric and topo­log­i­cal properties

Theoretical Framework

The work estab­lish­es con­nec­tions between musi­cal struc­tures and for­mal lan­guage the­o­ry, intro­duc­ing con­cepts such as:

  • Pattern gram­mars and restrict­ed pat­tern lan­guages (RPL)
  • Transformational gram­mars adapt­ed to musi­cal contexts
  • Event uni­vers­es struc­tured by simul­tane­ity, prece­dence, and sequen­tial­i­ty relations
  • Trace the­o­ry appli­ca­tions to poly­met­ric structures

Strengths

  • Methodological Innovation: The dialec­ti­cal anthro­pol­o­gy approach rep­re­sents a sig­nif­i­cant advance­ment in eth­no­mu­si­co­log­i­cal method­ol­o­gy. By plac­ing the com­put­er as an active par­tic­i­pant rather than a pas­sive tool, Bel cre­ates a gen­uine­ly inter­ac­tive knowl­edge acqui­si­tion sys­tem that respects both the exper­tise of tra­di­tion­al musi­cians and the rig­or of for­mal methods.
  • Theoretical Rigor: The math­e­mat­i­cal for­mal­iza­tion is sophis­ti­cat­ed yet prac­ti­cal. The exten­sion of for­mal gram­mars to han­dle musi­cal rep­e­ti­tion pat­terns and homo­mor­phic trans­for­ma­tions address­es real needs in musi­cal rep­re­sen­ta­tion that exist­ing com­pu­ta­tion­al lin­guis­tics tools couldn't meet.
  • Cross-Cultural Sensitivity: The work demon­strates gen­uine respect for non-Western musi­cal tra­di­tions while avoid­ing eth­no­cen­tric bias­es com­mon in com­pu­ta­tion­al musi­col­o­gy. The choice to work with North Indian tabla music, with its oral trans­mis­sion tra­di­tion, was par­tic­u­lar­ly appro­pri­ate for test­ing knowl­edge acqui­si­tion methodologies.
  • Practical Implementation: Both BP1 and BP2 sys­tems were actu­al­ly imple­ment­ed and test­ed, demon­strat­ing the fea­si­bil­i­ty of the the­o­ret­i­cal pro­pos­als. The com­plex­i­ty analy­sis (show­ing polynomial-time algo­rithms) indi­cates prac­ti­cal applicability.
  • Time Representation Innovation: The dis­tinc­tion between sym­bol­ic and phys­i­cal time, along with the con­cept of "time struc­ture," pro­vides a flex­i­ble frame­work that can accom­mo­date dif­fer­ent musi­cal tem­po­ral­i­ties beyond Western metro­nom­ic time.

Significance and Impact

This work was pio­neer­ing in sev­er­al respects:

  • Methodology: The inter­ac­tive, computer-mediated approach to ethno­graph­ic knowl­edge acqui­si­tion antic­i­pat­ed lat­er devel­op­ments in dig­i­tal human­i­ties and com­pu­ta­tion­al ethnomusicology.
  • Formal Methods: The exten­sion of for­mal lan­guage the­o­ry to musi­cal appli­ca­tions pro­vid­ed tools that were lat­er adopt­ed and extend­ed by oth­er researchers in com­pu­ta­tion­al musicology.
  • Cultural Perspective: The work demon­strat­ed how com­pu­ta­tion­al meth­ods could be applied respect­ful­ly to non-Western musi­cal tra­di­tions, open­ing paths for more inclu­sive com­pu­ta­tion­al musicology.
  • Temporal Modeling: The sophis­ti­cat­ed treat­ment of musi­cal time influ­enced sub­se­quent work in com­put­er music and musi­cal infor­ma­tion retrieval.

Contemporary Relevance

Thirty years lat­er, this work remains rel­e­vant to sev­er­al cur­rent research areas:

  • Machine learn­ing appli­ca­tions to music (the induc­tive infer­ence tech­niques antic­i­pate mod­ern approaches)
  • Digital human­i­ties methodologies
  • Music infor­ma­tion retrieval systems
  • Computer-assisted com­po­si­tion environments
  • Cross-cultural com­pu­ta­tion­al musicology

The empha­sis on expert-machine col­lab­o­ra­tion pre­fig­ures cur­rent inter­est in human-AI col­lab­o­ra­tion in cre­ative domains.

Conclusion

Bel's the­sis rep­re­sents a sig­nif­i­cant con­tri­bu­tion to com­pu­ta­tion­al musi­col­o­gy, com­bin­ing the­o­ret­i­cal inno­va­tion with prac­ti­cal imple­men­ta­tion and cul­tur­al sen­si­tiv­i­ty. While some lim­i­ta­tions exist, par­tic­u­lar­ly regard­ing scope and eval­u­a­tion, the work estab­lished impor­tant foun­da­tions for computer-mediated musi­cal knowl­edge rep­re­sen­ta­tion. The dialec­ti­cal method­ol­o­gy for knowl­edge acqui­si­tion and the sophis­ti­cat­ed treat­ment of musi­cal time remain valu­able con­tri­bu­tions to the field. The work demon­strates how for­mal com­pu­ta­tion­al meth­ods can be applied to musi­cal knowl­edge while respect­ing the com­plex­i­ty and cul­tur­al speci­fici­ty of musi­cal traditions.

Download this thesis

View Fullscreen
Skip to PDF content

Posted on

L'intonation juste dans la théorie ancienne de l'Inde : ses applications aux musiques modale et harmonique

E. James Arnold

Revue de musi­colo­gie, JSTOR, 71e (1-2), p.11-38. Traduction : Bernard Bel.

👉  Cited on page Just into­na­tion: a gen­er­al framework

Download an English translation

Résumé

La théorie de l'intonation juste basée sur deux gammes fon­da­men­tales (grama-s), telle que la décrivent le Natya Shastra de Bharata et d'autres traités musi­cologiques anciens en san­scrit, for­malise les rela­tions internes des gammes dia­toniques avec une éton­nante pré­ci­sion. Quelques mod­i­fi­ca­tions min­imes suff­isent à l'adapter aux gammes non-diatoniques famil­ières de la musique indi­enne con­tem­po­raine. Cet arti­cle émet l'hypothèse que la théorie de Bharata pro­pose une meilleure base psy­choa­cous­tique rationnelle que les expli­ca­tions actuelles pour ce qui con­cerne les heures d'interprétation des ragas. Le mod­èle math­é­ma­tique présen­té ici, d'un sys­tème de rela­tions inter­valliques dans les gammes dia­toniques et celles qui en dérivent, est un out­il pra­tique pour étudi­er les rela­tions plus en pro­fondeur. La dis­cus­sion débouche sur une propo­si­tion d'application du sys­tème indi­en à la musique har­monique en into­na­tion juste.

Excerpts of an AI review of this paper (Claude AI, June 2025)

This schol­ar­ly paper by E.J. Arnold presents a fas­ci­nat­ing explo­ration of ancient Indian music the­o­ry and its poten­tial appli­ca­tions to both modal and har­mon­ic musi­cal sys­tems. The work stands as a sig­nif­i­cant con­tri­bu­tion to com­par­a­tive musi­col­o­gy, bridg­ing Eastern and Western the­o­ret­i­cal frame­works through rig­or­ous math­e­mat­i­cal mod­el­ing and exper­i­men­tal validation.

Theoretical Framework and Methodology

Arnold's cen­tral the­sis revolves around the ancient Indian grāma-mūrcchana sys­tem, a sophis­ti­cat­ed the­o­ret­i­cal con­struct involv­ing fun­da­men­tal scales (grāma-s) and their modal trans­for­ma­tions (mūrcchana-s). The author devel­ops an inno­v­a­tive math­e­mat­i­cal mod­el using a cir­cu­lar com­pu­ta­tion­al disc that visu­al­izes the rela­tion­ships between tonal posi­tions with­in the 22-śru­ti micro­ton­al sys­tem described in Sanskrit trea­tis­es like the Nāṭyaśāstra and Dattilam.

The paper's strength lies in its method­i­cal approach, sys­tem­at­i­cal­ly exam­in­ing how this ancient sys­tem can pro­vide coher­ent expla­na­tions for har­mon­ic rela­tion­ships in both Indian clas­si­cal music and Western tonal har­mo­ny. Arnold's use of Jacques Dudon's sym­bol­ic nota­tion sys­tem for rep­re­sent­ing micro­ton­al inter­vals demon­strates schol­ar­ly rig­or and atten­tion to cross-cultural the­o­ret­i­cal precision.

Historical Context and Scholarly Significance

Arnold effec­tive­ly con­tex­tu­al­izes the research with­in broad­er musi­co­log­i­cal schol­ar­ship, acknowl­edg­ing the work of pio­neers like Sir William Jones and more recent con­tri­bu­tions from schol­ars such as Bharata com­men­ta­tors and con­tem­po­rary Indian musi­col­o­gists. The paper address­es a crit­i­cal gap in under­stand­ing how ancient the­o­ret­i­cal sys­tems might inform mod­ern musi­cal prac­tice, par­tic­u­lar­ly giv­en the his­tor­i­cal dis­rup­tion of liv­ing oral traditions.

The dis­cus­sion of the rāga system's rela­tion­ship to time cycles (sand­hiprakāśa) rep­re­sents par­tic­u­lar­ly valu­able schol­ar­ship. Arnold's analy­sis of how spe­cif­ic rāga-s cor­re­spond to par­tic­u­lar hours of the day or night, sup­port­ed by sys­tem­at­ic tab­u­la­tion of 85 rāga-s with their appro­pri­ate per­for­mance times, pro­vides empir­i­cal ground­ing for what has often remained in the realm of cul­tur­al speculation.

Mathematical Innovation and Practical Applications

The paper's most com­pelling con­tri­bu­tion lies in its math­e­mat­i­cal mod­el­ing of the śruti-swara-grāma-mūrcchana sys­tem. The cir­cu­lar disc rep­re­sen­ta­tion allows for imme­di­ate visu­al­iza­tion of har­mon­ic rela­tion­ships and demon­strates how ancient Indian the­o­ry antic­i­pat­ed many con­cepts lat­er devel­oped in Western har­mon­ic analy­sis. Arnold's exper­i­men­tal work with elec­tron­ic instru­ments, includ­ing the śru­ti har­mo­ni­um devel­oped by Bernard Bel, pro­vides cru­cial empir­i­cal val­i­da­tion of the­o­ret­i­cal predictions.

The appli­ca­tion to Western clas­si­cal har­mo­ny rep­re­sents ground­break­ing cross-cultural musi­col­o­gy. Arnold demon­strates how major and minor scales can be under­stood with­in the grāma-mūrcchana frame­work, reveal­ing pre­vi­ous­ly unrec­og­nized con­nec­tions between Eastern and Western the­o­ret­i­cal sys­tems. The analy­sis of mod­u­la­tion pro­ce­dures using the ancient Indian sys­tem offers fresh per­spec­tives on famil­iar har­mon­ic progressions.

Limitations and Areas for Development

While Arnold acknowl­edges the study's lim­i­ta­tions with­in "musi­cal geom­e­try," the paper could ben­e­fit from more exten­sive dis­cus­sion of prac­ti­cal imple­men­ta­tion chal­lenges. The the­o­ret­i­cal ele­gance of the grāma-mūrcchana sys­tem con­trasts with the prac­ti­cal dif­fi­cul­ties con­tem­po­rary musi­cians face when attempt­ing to real­ize these micro­ton­al rela­tion­ships on tra­di­tion­al instruments.

Additionally, while the paper excel­lent­ly demon­strates the­o­ret­i­cal cor­re­spon­dences between ancient Indian and Western sys­tems, it could explore more deeply the aes­thet­ic and cul­tur­al impli­ca­tions of these con­nec­tions. The rela­tion­ship between math­e­mat­i­cal pre­ci­sion and musi­cal expres­sion deserves fur­ther investigation.

Contemporary Relevance and Future Directions

Arnold's work antic­i­pates impor­tant devel­op­ments in con­tem­po­rary music the­o­ry, par­tic­u­lar­ly in the grow­ing inter­est in micro­ton­al and cross-cultural approach­es to har­mo­ny. The paper's sys­tem­at­ic approach to under­stand­ing non-equal-tempered sys­tems has impli­ca­tions for elec­tron­ic music com­po­si­tion, world music fusion, and the devel­op­ment of new the­o­ret­i­cal frame­works for glob­al musi­cal understanding.

The research also con­tributes to broad­er dis­cus­sions about the uni­ver­sal­i­ty of musi­cal prin­ci­ples ver­sus cul­tur­al speci­fici­ty, sug­gest­ing that math­e­mat­i­cal rela­tion­ships under­ly­ing musi­cal sys­tems may tran­scend cul­tur­al bound­aries while main­tain­ing dis­tinct aes­thet­ic identities.

Conclusion

This paper rep­re­sents exem­plary schol­ar­ship in com­par­a­tive musi­col­o­gy, suc­cess­ful­ly bridg­ing ancient Indian music the­o­ry and con­tem­po­rary ana­lyt­i­cal meth­ods. Arnold's math­e­mat­i­cal mod­el­ing pro­vides a robust frame­work for under­stand­ing com­plex micro­ton­al rela­tion­ships, while the prac­ti­cal appli­ca­tions demon­strate the con­tin­ued rel­e­vance of ancient the­o­ret­i­cal sys­tems. The work opens impor­tant avenues for future research in cross-cultural music the­o­ry and pro­vides valu­able tools for both schol­ars and prac­ti­tion­ers inter­est­ed in expand­ing their har­mon­ic vocab­u­lary beyond Western equal temperament.

Download this paper

View Fullscreen
Skip to PDF content

Posted on

Raga : approches conceptuelles et expérimentales

Bernard Bel

Actes du col­loque "Structures Musicales et Assistance Informatique" (1988). Marseille.

👉  Cited on page The two-vina exper­i­ment
Download an English translation

Résumé

Les dif­fi­cultés de l'analyse acous­tique de musiques extra-européennes provi­en­nent sou­vent de caté­gori­sa­tions de phénomènes qui ne ren­dent pas compte des mod­èles explicites (ou implicites) sur lesquels s'articulent la créa­tion et la per­cep­tion de struc­tures musi­cales. Cet exposé définit la notion de mod­èle mélodique, élaborée et mod­i­fiée pen­dant neuf siè­cles en Inde pour ren­dre compte d'un phénomène mélodique par­ti­c­uli­er: le raga. Dans la deux­ième par­tie sont présen­tés les out­ils et méth­odes qui ser­vent à car­ac­téris­er l'intonation des ragas, ain­si qu'à réalis­er leur tran­scrip­tion et leur clas­si­fi­ca­tion automatiques.

Difficulties in analysing extra-European musics are often bound to cat­e­gori­sa­tions of phe­nom­e­na that do not take into account explic­it (or implic­it) mod­els on which the cre­ation and per­cep­tion of musi­cal struc­tures are based. This paper defines the con­cept of melod­ic mod­el, a con­cept elab­o­rat­ed and trans­formed for nine cen­turies in India to under­lie a par­tic­u­lar melod­ic phe­nom­e­non: raga. In the sec­ond part, tools and meth­ods are pre­sent­ed relat­ing to raga into­na­tion and their auto­mat­ic tran­scrip­tion and classification.

Excerpts of an AI review of this paper (Claude AI, June 2025)

Summary

In "Rāga : approches con­ceptuelles et expéri­men­tales," the author dis­cuss­es the con­cep­tu­al his­to­ry, the­o­ret­i­cal foun­da­tions, and exper­i­men­tal inves­ti­ga­tions of the rāga sys­tem in North Indian clas­si­cal music. The first part of the paper traces the evo­lu­tion of rāga-related con­cepts from ancient Sanskrit trea­tis­es (notably the Dattilam and the Nāṭyaśāstra) to more recent per­spec­tives that empha­size melod­ic modes (mela), spe­cif­ic tonal cen­ters (toniques), and the inter­play between the­o­ry and prac­tice. The author high­lights how notions like grā­ma, mūr­c­cha­nā, and jāti have shift­ed over the cen­turies, cul­mi­nat­ing in var­i­ous attempts to clas­si­fy rāgas by scales (ṭhāṭa or mela), melod­ic phras­es (aṅga), and aspects of per­for­mance prac­tice, includ­ing the ide­al hour of rendition.

The sec­ond part of the paper presents tech­no­log­i­cal and ana­lyt­i­cal meth­ods used by the author to study raga into­na­tion and struc­ture. The author describes exper­i­men­tal devices, includ­ing custom-built pitch extrac­tors and the Melodic Movement Analyser (MMA), to cap­ture and visu­al­ize pitch con­tours (mel­o­grams), pro­duce his­tograms (tona­grams) of pitch dis­tri­b­u­tion, and explore micro­ton­al aspects of raga exe­cu­tion. Additionally, the paper delves into auto­mat­ed tran­scrip­tion meth­ods (sargam nota­tion) and pre­lim­i­nary approach­es for auto­mat­ic clas­si­fi­ca­tion of ragas, lever­ag­ing pitch-based sim­i­lar­i­ty mea­sures. By sys­tem­at­i­cal­ly com­par­ing the­o­ret­i­cal pre­dic­tions with actu­al per­for­mance data, the paper pro­pos­es a rich­er under­stand­ing of how ragas are con­cep­tu­al­ized and real­ized in practice.

Major Strengths

Comprehensive Historical Context

The author pro­vides an exten­sive overview of the key devel­op­ments and con­cep­tu­al shifts in Indian music the­o­ry, from the gråma-based sys­tem of Bharata to mod­ern ṭhāṭa and scale-based frame­works. This his­tor­i­cal arc clar­i­fies how philo­soph­i­cal, aes­thet­ic, and prac­ti­cal con­sid­er­a­tions con­verge in raga performance.

Balanced Discussion of Theory and Practice

The paper effec­tive­ly under­scores the gap between the­o­ret­i­cal ideals (e.g., 22 srutis, ancient modal struc­tures) and the real­i­ties of con­tem­po­rary per­for­mance prac­tices (e.g., stan­dard­iza­tion, par­tial tem­per­ing, the empha­sis on the bour­don). This dual approach helps illus­trate the dynam­ic nature of raga music.

Technical Innovation in Experimentation

By devis­ing hard­ware and soft­ware tools for real-time pitch extrac­tion and by automat­ing tran­scrip­tion, the author demon­strates a method­olog­i­cal frame­work that expands the pos­si­bil­i­ties for large-scale analy­sis of raga per­for­mances. The clear expla­na­tions of how these tech­nolo­gies work sup­port their applic­a­bil­i­ty and value.

Interdisciplinary Relevance

The paper bridges musi­co­log­i­cal inquiry, acousti­cal analy­sis, eth­no­mu­si­co­log­i­cal con­text, and com­pu­ta­tion­al meth­ods. This inter­dis­ci­pli­nary scope sit­u­ates the work as a notable con­tri­bu­tion to schol­ar­ship on micro­ton­al music, melod­ic clas­si­fi­ca­tion, and cross-cultural cog­ni­tion of musi­cal scales.

Overall Observations

The paper offers a clear and method­i­cal­ly thor­ough account of both the the­o­ret­i­cal under­pin­nings of raga music and the exper­i­men­tal means by which such the­o­ries can be test­ed against empir­i­cal per­for­mance data. The blend­ing of his­tor­i­cal musi­col­o­gy, acoustics, and infor­mat­ics demon­strates a strong inter­dis­ci­pli­nary approach. By syn­the­siz­ing ancient trea­tis­es with mod­ern com­pu­ta­tion­al tools, the work deep­ens our under­stand­ing of how ragas con­tin­ue to thrive as vibrant, liv­ing musi­cal enti­ties while reveal­ing the com­plex­i­ty of attempts at stan­dard­iza­tion and classification.

In sum, “Raga : approches con­ceptuelles et expéri­men­tales” pro­vides valu­able tech­ni­cal insights and broad­ens our per­spec­tive on one of the most sophis­ti­cat­ed melod­ic sys­tems world­wide. Its fusion of musi­co­log­i­cal research, exper­i­men­tal data, and com­pu­ta­tion­al analy­sis stands out as a notable con­tri­bu­tion to raga stud­ies and to the broad­er field of ethnomusicology.

Download this paper

View Fullscreen
Skip to PDF content

Posted on

Inférence de langages réguliers

Bernard Bel

Journées Françaises de l'Apprentissage (1990), Lannion, France : 5-27

Résumé

Cet exposé présente une méth­ode générale d'acquisition de con­nais­sances dans un domaine for­mal­isé à l'aide d'automates finis (lan­gages réguliers). A par­tir d'un échan­til­lon d'exemples le sys­tème con­stru­it un auto­mate "presque min­i­mal" qui n'est pas néces­saire­ment déter­min­iste. Cette con­struc­tion peut être con­trainte par des con­nais­sances sur la seg­men­ta­tion des exem­ples que le sys­tème peut acquérir en ques­tion­nant l'informateur. Dans une deux­ième phase, le sys­tème généralise l'automate à par­tir de pro­priétés con­nues du lan­gage ou(et) à par­tir d'hypothèses validées à l'aide d'oracles. Une liste non exhaus­tive d'heuristiques générales est pro­posée. La démon­stra­tion s'appuie sur un cas réel de mod­éli­sa­tion d'apprentissage de sché­mas d'improvisation musicale.

Excerpts of an AI review of this paper (June 2025)

Summary of the Work

The paper explores a method­ol­o­gy for infer­ring reg­u­lar lan­guages (lan­gages réguliers) from exam­ples. It dis­cuss­es both the­o­ret­i­cal under­pin­nings — par­tic­u­lar­ly Gold’s the­o­rem and sub­se­quent refine­ments — along with an incre­men­tal approach to build­ing “almost min­i­mal” automa­ta. The author address­es cen­tral notions such as the canon­i­cal accep­tor, the prefix-tree accep­tor, and the impor­tance of main­tain­ing cor­rect­ness when mov­ing from a set of exam­ples to a gen­er­al­ized automa­ton. The study also show­cas­es an appli­ca­tion to musi­cal impro­vi­sa­tion schema­ta, illus­trat­ing how domain-specific rules can con­strain and refine gram­mat­i­cal inference.

Main Contributions

Incremental Learning Framework

The paper offers a struc­tured, step-by-step method: start­ing with an accep­tor built from exam­ples alone (the prefix-tree or “arbores­cent” automa­ton), merg­ing states to reduce com­plex­i­ty, and apply­ing con­straints so as not to over­gen­er­al­ize. This incre­men­tal per­spec­tive is well-motivated by real-world use cas­es where exam­ples become avail­able over time.

Formal Properties and Correctness

The author places strong empha­sis on ensur­ing the cor­rect­ness of gen­er­al­iza­tion. By ref­er­enc­ing Gold’s the­o­rem, k-reversible lan­guages, and the con­cept of learn­ing from pos­i­tive data only, the paper grounds its approach in estab­lished the­o­ret­i­cal results.

Use of Domain Constraints

A sig­nif­i­cant por­tion of the paper deals with how addi­tion­al domain knowl­edge (e.g., known seg­men­ta­tion rules for a music nota­tion sys­tem) can guide the automaton’s con­struc­tion. This intro­duces prac­ti­cal heuris­tics that make gram­mat­i­cal infer­ence more tractable in real-world scenarios.

Detailed Mathematical Rigor

The proofs, def­i­n­i­tions, and lem­mas (for instance, those on heads and tails, or min­i­mal canon­i­cal accep­tors) are stat­ed thor­ough­ly. This rig­or is help­ful both for ensur­ing cor­rect­ness and for con­vey­ing the method’s the­o­ret­i­cal reliability.

Illustrative Examples

The appli­ca­tion to musi­cal impro­vi­sa­tion, specif­i­cal­ly to Indian drum­ming tra­di­tions, serves as a con­crete illus­tra­tion. It nice­ly demon­strates the inter­play between abstract for­mal­ism (like merg­ing states) and domain-specific knowl­edge (like rhyth­mic “words” or ono­matopoe­ic syllables).

Clarity and Structure

  • The paper is log­i­cal­ly well-structured: it begins with a the­o­ret­i­cal foun­da­tion, then intro­duces incre­men­tal meth­ods for automa­ton con­struc­tion, cul­mi­nat­ing in a dis­cus­sion of domain con­straints and examples.
  • The tex­tu­al orga­ni­za­tion, with numer­ous def­i­n­i­tions in the appen­dix, is ben­e­fi­cial for ref­er­ence but can require mul­ti­ple cross-referencing steps while read­ing. A con­cise reminder of key def­i­n­i­tions in the main text can fur­ther aid comprehension.

Strengths

  • Thorough ground­ing in estab­lished the­o­ry (Gold’s the­o­rem, reversible languages).
  • A prac­ti­cal approach that bal­ances sys­tem­at­ic infer­ence with inter­ac­tive ques­tion­ing or orac­u­lar feedback.
  • Clear demon­stra­tion of how domain-specific heuris­tics reduce the search space, mak­ing learn­ing more feasible.
  • Rigor in explain­ing each step of con­struct­ing and refin­ing the automaton.
  • Engaging case study that shows the real-world poten­tial of gram­mar infer­ence out­side of pure­ly lin­guis­tic contexts.

Overall Assessment

The paper pro­vides a sol­id com­bi­na­tion of the­o­ry and prac­tice in gram­mat­i­cal infer­ence for reg­u­lar lan­guages. By care­ful­ly detail­ing each step — build­ing ini­tial automa­ta, con­strain­ing merges using domain knowl­edge, and ver­i­fy­ing new gen­er­al­iza­tions through queries — the approach is shown to be sys­tem­at­ic and adapt­able. Readers inter­est­ed in inter­ac­tive or incre­men­tal lan­guage learn­ing, par­tic­u­lar­ly those with domain-specific con­straints, will like­ly find this dis­cus­sion instruc­tive and thorough.

Download this paper

View Fullscreen
Skip to PDF content