How a Computer Can Calculate A Tune's Difficulty (using BWW files)

Use our difficulty calculator here: DojoUniversity.com/difficulty

A tune's difficulty can be measured in "potential fingerwork errors per second."

For example, a Tune A that lasts 60 seconds that has 180 possible fingerwork errors would have a "rating" of 3 PEPS (potential errors per second).

Tune B that was 30 seconds long with 60 possible errors would only have a PEPS score of 2.

Therefore, Tune A is more difficult than Tune B.

Easy!

What are Potential Fingerwork Errors?

Before Dojo fingerwork methodology, it would have been hard to pinpoint exactly what errors were possible in any given piece of music, but now it's quite straightforward. The potential fingerwork errors are:

Missing a rhythmic target (like a beat or off-beat)
A crossing noise
A gracenote that is too big or missed (size error)
A gracenote that is not synchronized to its note change (sync error)
An embellishment whose steps are played incorrectly.
An embellishment whose steps are not played ASA(m)P (and thus evenly).
A dot-cut combination whose cut note is not played ASA(m)P.

Bagpipe Music Writer Code

Bagpipe Music Writer is basically a programming language to document bagpipe tunes. In theory, we should be able to take BWW code and extract the potential errors from it programatically.

Here is the first two lines of "The Abercairny Highlanders"

& sharpf sharpc 2_4 I! dbe E_8
!	gg LAr_16 'la Bl_32 grp Cr_16 'c Dl_32dbe Er_8 dbha HAl_8
!	hdbf Fr_8 gg Dr_16 'd Fl_32 						space		dbe Er_8 gg LAr_16 'la El_32
!	dbd Dr_16 'd Cl_32 dbb Bl_16 'b LAl_32			space		gg LGr_16 'lg LAr_32 gg Bl_32 dg LGl_16 'lg
!	dbhg HGr_8 tg Bl_8								space		tar Br_8 dbha HAl_8				!t

& sharpf sharpc
	 LAr_16 'la Bl_32 grp Cr_16 'c Dl_32				space		dbe Er_8 dbha HAl_8
!	hdbf Fr_8 gg Dr_16 'd Fl_32 						space		dbe Er_8 gg LAr_16 'la El_32
!	dbd Dr_16 'd Cl_32 dbb Br_16 'b LAl_32 			space		gg LGr_16 'lg LAr_32 gg Bl_32 Dl_16 'd
!	dbc Cr_8 eg LAl_8								space		brl LAr_8 dbha HAl_8					!t

Keep in mind that most tunes are much longer than this one. But it shows the code. For those not familiar with BWW code, the basics are as follows:

! = barlines. !'s with other things attached are different types of barlines. (like 'I' are double bar lines, for example)
2_4 is our time signature, 2/4 time. There are two beats in each bar, each with a duration of a quarter note.
Capital letters are melody notes.
Underscores followed by numbers are note values. (_8 means eighth note, _32 means 32nd note, etc.)
Two-letter lower case cominations ending in 'g' are single gracenotes. 'gg' = g gracenote, 'dg' = d gracenote, 'tg' = thumb gracenote, etc. There are also some special gracenotes like "strlg" that the computer will need to know are gracenotes.
3-or-more lower case combinations are embellishments. 'grp' = grip, 'dbe' = doubling on e, etc.
Apostrophes followed by lower-case melody note identifiers are simply dots added to a note value. 'lg means dot on low g, 'f would mean a dot on f, etc.
'r' or 'l' after melody notes simply indicate which direction the beaming should "point." These are for aesthetics only and we won't need them for our analysis.
& are treble clefs (we don't need these for our analysis)
sharpf sharpc is our key signature (we don't need this for our analysis)
"space" is optional syntax that we don't need for our analysis.

Transformation

There are two logical phases of transformation we need to do to our original text to get it to the state where it will enable our computer to find total possible errors. (Although, the computer will be able to do both "all at once.")

The first transformation is to simply get rid of everything in our code we don't need. In the perfect world, our transformation would come out looking like this:

2_4 ! dbe E_8
! gg LA16 B32 grp C16 D32 dbe E8 dbha HA8
! hdbf F8 gg D16 F32 dbe E8 gg LA16 E32
! dbd D16 C32 dbb B16 LA32 gg LG16 LA32 gg B32 dg LG16 
! dbhg HG8 tg B8 tar B8 dbha HA8

! LA16 B32 grp C16 D32 dbe E8 dbha HA8
! hdbf F8 D16 F32 dbe E8 gg LA16 E32
! dbd D16 C32 dbb B16 LA32 gg LG16 LA32 gg B32 D16 
! dbc C8 eg LA8	brl LA8 dbha HA8 
!

Now things are looking clean. We can clearly see all notes, gracenotes, embellishments, and whether a note value is equal to "ASA(m)P".

The next phase is to transform all embellishments into their "true state." A complete embellishment table would be needed for our full program, but let's preview the table by looking at just the embellishments we see in our sample:

dbe	gg E32 fg
grp	LG32 dg LG32
dbha	HA32 gg
hdbf	F32 gg
dbd	gg D32 eg
dbb	gg B32 dg
dbhg	gg F32
tar	LG32 dg LG32 eg
dbc	gg C32 dg
brl	strlg LA32 strlg

All of the embellishments in our tune-code should be replaced with these values.

The final transformation might look like this:

2_4 ! gg E32 fg E_8
! gg LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg HA8
! F32 gg F8 gg D16 F32 gg E32 fg E8 gg LA16 E32
! gg D32 eg D16 C32 gg B32 dg B16 LA32 gg LG16 LA32 gg B32 dg LG16 
! gg F32 HG8 tg B8 LG32 dg LG32 eg B8 HA32 gg HA8

! LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg  HA8
! F32 gg F8 gg D16 F32 gg E32 fg E8 gg LA16 E32
! gg D32 eg D16 C32 gg B32 dg B16 LA32 gg LG16 LA32 gg B32 D16 
! gg C32 dg C8 eg LA8 strlg LA32 strlg LA8 HA32 gg HA8 
!

Now that we have the data in this form, we can perform our analysis.

Missing a rhythmic target (like a beat or off-beat)

Our time signature give us clues about how many rhythmic targets may exist per bar, but it's best to simply let the user type this in manually.

Put an input box for "rhythmic targets per bar." In the case of Abercairny Highlanders (our current code) I would select 4. (Beats and off beats)

Have the computer count the total bars in the text file. A bar is defined as any TWO '!'s with content in between them.

Occasionally, though, "pick up" bars are seen in the music. We'll need an input box for the user to stipulate any "incomplete bars." The value of this input would need to be subracted from the computer's bar count. In this case, we have 1 incomplete bar, making the total bars = 8.

Rhythmic targets per bar (4) * Total Bars (8) = totalRhytmicTargetErrors (32)

We'll need this totalRhytmicTargetErrors variable for our grand total later.

Crossing Noises

To count possible crossing noises, we need to count every time a note changes in the text snippet.

Remember, a note is any capital letter.

gg LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg HA8

A note change is, fairly obviously, any time the capital letters indicating a melody note actually changes. In the above code, there are 6 note changes (even though there are 10 notes).

Exceptions: There are a few exceptions where, even though there is a note change, there is no possible error. The exceptions (globally, for all bagpipe tunes are)

LG:LA or LA:LG
LA:B or B:LA
C:D or D:C
E:F or F:E
F:HG or HG:F
LA:E or E:LA

We need to subtract exceptions from our note-change count. There are two in our snippet above (LA:B and C:D), so note-changes (6) minus exceptions (2) = totalScaleNavErrors (4)

Save totalScaleNavErrors for our grand total at the end.

Gracenote Size Errors

This one is straightforward. We simply need to count all gracenotes. In this snippet for example, there are _______ gracenotes?

gg LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg HA8

Answer = gg, dg, gg, fg, gg = 5 gracenotes.

The only tricky thing here is that there are some specialy gracenotes like "strlg" that don't follow the usual pattern of two lowercase letters ending in 'g'.

Save totalGracenoteSizeErrors (5) for our grand total at the end.

Gracenote Sync Errors

Gracenote Sync Errors are gracenotes that don't line up properly with a note change.

We defined the rules of note-changes in the "Crossing Noises" section above. If (and only if) a gracenote happens during a note change, it should be counted as a potential gracenote sync error.

Here's our code snippet again:

gg LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg HA8

In this snippet, there are 5 total gracenotes, but only one happens during a note-change (the 'gg' in between D:E).

So our totalGracenoteSyncErrors (1) should be saved for our grand total at the end.

Incorrect Embellishment Steps

Because we split embellishments out into their discrete steps in the transformation phase, potential incorrect embellishment steps will be "counted" as a part of Crossing Noise errors and/or gracenote errors! There's nothing left we need to do here.

Embellishment Steps Not Played ASA(m)P

ASA(m)P is a Dojo abbreviation for "as short as musically possible." In theory, all embellishment steps should be played ASA(m)P (and therefore even).

Because we broke all of the embellishments into their discrete steps in the transformation phase, their "32nd note" values will be counted in the upcoming "ASA(m)P Errors" section. So, there is nothing left to do here!

ALAP/ASAP Errors

ALAP/ASAP is Dojo-speak for how we should handle dot-cut rhythms in bagpipe music. ALAP means "as long as possible," and ASA(m)P means "as short as musically possible."

The bottom line here is that we don't play these rhythms metrically as written, instead we maximize the duration contrast between the two notes.

To calculate potential errors here, all we have to do is identify that an "ASA(m)P" note exists. If it does, we add 1 to our possible errors. If the ASA(m)P is played too long, it will result in roundness, and if it's played too short, its result is "crushed" playing.

To count ASA(m)Ps, we will need a user input box that specifies the maximum value of ASAP. Any note values of this duration or less will be counted as ASA(m)Ps by the computer and therefore 1 potential error.

Example: Let's set "32" as our maximum ASA(m)P value for our example below:

2_4 ! gg E32 fg E_8
! gg LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg HA8
! F32 gg F8 gg D16 F32 gg E32 fg E8 gg LA16 E32
! gg D32 eg D16 C32 gg B32 dg B16 LA32 gg LG16 LA32 gg B32 dg LG16 
! gg F32 HG8 tg B8 LG32 dg LG32 eg B8 HA32 gg HA8

! LA16 B32 LG32 dg LG32 C16 D32 gg E32 fg E8 HA32 gg  HA8
! F32 gg F8 gg D16 F32 gg E32 fg E8 gg LA16 E32
! gg D32 eg D16 C32 gg B32 dg B16 LA32 gg LG16 LA32 gg B32 D16 
! gg C32 dg C8 eg LA8 strlg LA32 strlg LA8 HA32 gg HA8 
!

If the computer counts all all 32 values (or shorter, i.e. 64, 128, etc), we come out with an ASA(m)P count of 38.

totalAsampErrors (38) should be saved for our grand total at the end.

Total Errors

To calculate the total errors in our tune, we simply need to add all of our error variables together:

totalErrors = totalRhytmicTargetErrors + totalScaleNavErrors + totalGracenoteSizeErrors + totalGracenoteSyncErrors + totalAsampErrors

Simple!

Next: How Many Seconds is Our Tune?

If we want to determine a "possible errors per second" score for our tune, we next need to find out how many seconds long our tune is (totalSeconds).

This is simple.

First, take our "total number of rhythmic targets" number from the Rhythmic Targets section:

Rhythmic targets per bar  * Total Bars = totalRhytmicTargetErrors

Now, next we need a user input box to tell us - how many rhythmic targets per minute should there be (targetsPerMinute)? (in other words, what is the tempo of the tune?) In the case of our Abercairny Highlanders example here, it would be 160 targetsPerMinute.

To find how many second long our tune is, we simply do this:

totalSeconds = totalRhythmicTargetErrors * (targetsPerMinute/60)