Placement of the Downbeat

Although it is possible to get a generic music "engraving" program to correctly print the music of the bagpipe, because of the importance on the timing of and within the embellishments, most generic programs are unable to accurately play from the written scores. My major issue with most programs is how a tune is played s-l-o-w-l-y, as a beginner would play it. It is in the forming of sound fundamentals that these programs have the greatest impact on young pipers. If these fundamentals are misrepresented to the student and not corrected befor that student presents these concepts to his/her audience, then piping itself is damaged..

Bagpipe Music Writer Gold/Bagpipe Player

The issue of embellishment timing in the Bagpipe Music Writer/Player programs has been much improved by the approach above.

However, I feel that I should point out that placement of the downbeat in this program is defined by two "Smoothing Factors" which place a certain fraction of an embellishment after the beat. The manual/help screens suggest that the majority of embellishments are affected by A and only the piobaireachd abbreviations for leumluaths, taorluaths, and crunluaths are affected by by factor B.

This one-size-fits-all approach doesn't work. If we place the beat properly for a three note embellishment, then a one, two, or four or five note embellishment isn't going to be timed correctly. We also know that the downbeat placement differs depending upon the embellishment.

If we could fix this problem, then many problems would go away. A pet peeve of mine is that melodies with harmonies (e.g., Kilworth Hills) having different embellishments, each properly played, would be composed such that their MIDI representations could be "meshed" with any of several software packages. That doesn't work today because the two harmony parts end up being of different duration because they have different embellishments. The only way to get the two harmony parts to be exactly the same duration is to set the Smoothing Factors to 100 and this results in an unacceptably stilted version of the tune.

Other programs

Most other generic programs have similar issues. From what I can hear of PiobMaster or ElectricPipes, they do a good job at this aspect.

A Conceptual Solution for all Systems

These timing issues could be "fixed" by defining where the starting time is for the next melody note. Embellishment notes before this time would be taken from the previous note and embellishment notes following this time would be taken from the following melody note.

All that is needed is a character (e.g., the "at" symbol - "@" ) to define the point at which the timing switches from one note to the next. This might be called the "note separator".

The "note separator" would be ignored by the music engraving portion of the program, but would be an important part of the music playing portion of the program.

For music without embellishments, this is easy. Two melody notes adjacent to each other would be defined to have an implied "note separator" - as they do now.

For embellishments, the duration of each note in the embellishment would need to be known.

Example in ABC format

We can model this in ABC format.

If there is a single gracenote, for example {g}, the gracing might be written as {g@}. The previous melody note would be shortened to allow this single gracenote to be played. The following melody note would fall at its exact point in time.
However a c doubling might be written as {g@cd} so that the downbeat falls at the beginning of the first repetition of the melody note in the doubling. As above, the previous melody note would be shortened to allow the single g gracenote to be played. The c in the embellishment would begin at the time of the next melody note followed by the d gracenote and the (presumably) c melody note.
A taurluath could be written as {GdGe@}. The previous melody note would be shortened to accomodate all four gracenotes and the following melody note would begin "on time".
The light throw would be played as as {G@dc} and the heavy throw as {GdGc@}.

Because these embellishments would be robbing time from their adjacent melody notes, there would need to be some error checking to be sure that the tune didn't have any problems with embellishments needing more time than the melody notes could allow (e.g. a taurluath with 100 msec gracenotes following a 32nd note at 90 bpm wouldn't make sense mathematically). A simple "stilted play" warning before playing the sounds would suffice. This would allow the user fix the problem to their own satisfaction.

Specifically for Electric Pipes

Since this is very similar in format to ABC files, the same approach would work.

Specifically for Bagpipe Music Writer Gold and Bagpipe Player

A suggested approach for these programs is as follows...

There is a "category" in the BMW32.INI file which is described as CAT_BEAT_SEPARATOR. The notes in BMW32.INI suggest that categories are defined in the manual, but I can't find it. The notes near CAT_BEAT_SEPARATOR also suggest that it isn't used. It sure would be nice if you could use this to "define" where the downbeat falls in the embellishment.

For example, and following the discussion about internal timing of embellishments in the BMW32.ini file, if dbc was G@c*d where the "@" symbol defined the downbeat, then the G would fall before (i.e., be subtracted from the previous note) and the c*d would fall after the downbeat (i.e., be subtracted from the following notes).

There would be no more need for the Smoothing Factors.