Bagpipe ornaments

• Oct 30, 2018 - 14:24

I love that the bagpipe ornamentation tool is there, and my piper friend who helped me compose a piece recently was very impressed that MuseScore2 even had the tool available.
There are, as I see it, two problems.
There are inaccuracies with pitch - the 'concert pitch' button must always be used, pipe music I've seen is always written at concert pitch, at least for the Highland pipes. It's just that A is tuned to close to 470.
The major problem is that ornamentation timing during playback is way off.

Playback is useless with the timing of ornamentation so far off - basically it's too slow. Musescore gives too much time value to the grace notes - often times even playing them as actual 32nd notes rather than as part of the duration of the actual note they lead in to. Maybe there's a work-around for it?


In reply to by sjlawson

Hmm... listened to it again, and it seems like some are correct, and some are just a little messed up. I'm noticing that the ones that are correct play like acciaccaturas, but some play like Appoggiatura. It should be noted that grace notes for bagpipes are always acciaccaturas, even when written without the slash through the grace note. Still - I'm grateful the bagpipe ornamentation tool exists at all. Just if someone wants to improve it, that's the main problem. Eh... maybe I'll have a look. It is open source, right?

In reply to by Jojo-Schmitz

I notice mainly, single 32nd notes (single grace) seem to play as appoggiaturas rather than acciaccatura. Picking the acciaccatura grace note is an o-kay work-around, but pipe music isn't typically written that way. I'm looking at the source now, but unsure where the gracenote type is determined. Reading through bagpembell.cpp and bagpembell.h...

I notice the larger embellishments seem correct for quarter notes, but are played too long in the case of embellishments to longer notes, suggesting they are being interpreted as appoggiaturas.

In reply to by sjlawson

See libmscore/rendermidi.cpp. That's where pretty much everything about playback is handled. Do a search for "grace" in that file and you should be able to find that code, it's pretty well localized.

But, if the issue is that they should simply have been created as acciccaturas instead of appoggiatures, then I wouldn't look to the playback code - I'd fix how they are actually created in the palette.

In reply to by Marc Sabatella

As said above: It should be noted that grace notes for bagpipes are always acciaccaturas, even when written without the slash through the grace note.
So here apparently we need appoggiaturas that sound like acciaccaturas. Or acciaccaturas that look like appoggiaturas.
Maybe they get get added to the pallete as acciaccaturas with the slash through the stem removed or made invisible?

In reply to by Jojo-Schmitz

OK, some more investigation on that:
Bagpipe Embellishments not only look like NoteType::GRACE32, they also get added as such in libmscore/note.cpp, with the duration of an 8th of a quarternote and the corresponding playback.

Changing this here to NoteType::ACCIACCATURA would trigger a special case for playback in libmscore/rendermidi.cpp, which would be desired here, but also trigger libmscore/chord.cpp, so get that slash though stem, which is not wanted.
So it seems we'd need a special NoteType::BAGPIPE_EMBELISHMENT that triggers one but not the other?

In reply to by Jojo-Schmitz

Not only bagpipe embellishments should be played as acciaccaturas without a slash through the stem, but also in other places where there is more than one grace note before a chord. See for example the three-note grace notes before the quarter notes from rehearsal mark D onwards in Grieg's Peer Gynt suite no. 1, mvt. 4 "In the Hall of the Mountain King" here

I have always understood such grace notes to mean "play us as quickly as you can". If I am wrong and I have always understood such multiple grace notes before a note wrong, this comment can be ignored.

In reply to by Louis Cloete

Rather setting the chords to small. Yes that would work (and maybe even better, as you don't need any 'parent' note to attach these fake cadenzas to), also these could get entered as (small) custom tuplets (with bracket and number disabled), thus not requiring an unregular measure.
Question is what happens to 'gracenote cadenzas' from existing 2.x scores? Do we care? After all they look the same, just may sound different? And having used a workaround in an older version shouldn't keep us from providing better means in a newer version, breaking the old workaround, or should it? We even did this in 2.x, with voltas and repeat lists.

What the heck, here we go:

If you're on Windows you may want to give the build at… a try

In reply to by Marc Sabatella

I think that is a bit hacky ;-)

I had another (unrelated) idea: how about changing libmscore/chord.cpp, function virtual void layoutStem1() (…) line 10:

if ((_noteType == NoteType::ACCIACCATURA) && !(beam() && beam()->elements().front() != this)) {


if ((_noteType == NoteType::ACCIACCATURA) && (this->parent()->graceNotes().size() == 1)) {

That would get rid of the thing where you get a slash through the first stem if you enter more than one acciaccatura (I think). That always look a bit strange to me. That would also maybe give us a solution to the cadenza appoggiaturas. I think the original workaround (add an invisible, non-playing note and add appoggiaturas to it) is already a hack, however, so I am not too worried if people have to fix that in files created with 2.x and opened with 3.0.

In reply to by Marc Sabatella

I did not know it was optional. I haven't seen that in any published sheet music, but it is as you say, it's easy enough to hide it. Do you think it is a common enough use case to want to hide the slash when you put more than one acciaccatura before a note to warrant a checkbox in the inspector?

Do you still have an unanswered question? Please log in first to post your question.