Add native support for slash notation

• Jan 28, 2011 - 09:00
S5 - Suggestion

In jazz leadsheet notation is often done to mark beat with slashes. Currently, MuseScore provides this facility via slash notehead and stemless notes, as in this snippet .
This way to get the results as several drawbacks :

  1. When you transpose the score, the noteheads are transposed and there are not expected to move
  2. When you play the score, the notes are played even if slashed. A possible workaround is to adjust the velocity, but it can be cumbersome.

Add a way to change a rest into a slash (and back to a normal rest). Rests are note transposed and don't sound on playback.

See :


I'm not sure that this is really a drawback. I don't know that I've ever seen lyrics in a score attached to the slashes in either a solo or comping section in a jazz score. Lyrics are typically attached to actual notes, so if slash notation is needed with lyrics, the current method of changing the notehead to a slash would work just fine. The proposal isn't to change it so that slashes can ONLY be put on rests, but rather to ALLOW them to be put on rests.

- Mike.

Although someone recently described this feature as effectively turning rests into slashes, and that isn't a bad way of thinking about it, it isn't the only way to think of it. I see slash notation as being intended to replace *anything* - notes or rests. So you could have a measure full of actual notes intended for playback, but you wish to *display* it as a full of slashes (one per beat). This could be done by marking the notes invisible in one voice and then having rests in another voice display as slashes, but that's a very roundabout way of doing what is actually a fairly common operation.

That is for the basic stemless-slashes-one-per-beat notation used to indicate a section open for improvisation (or accompaniment). There is a conceptually similar notation in which you specify a particular rhythm (usually for accompaniment) but wish it to display using slash noteheads, still with normal stems.

BTW, some people like their slashes to display middle line, others on the space just below. In passages where there are multiple voices on the same staff, it can be necessary to display slashes higher or lower, just as is done with rests.

I'd recommend that thought go into designing a system that handles all of these cases well. We already have a system that sort of but not really works; no need to crank out a slightly better but still not really fully baked scheme.

The mechanism used in Finale - a "staff style" that can apply to a given range of measures on a given staff - works pretty well for most purposes. You can choose either slash notation (the basic stemless-slashes-one-per-beat) or "rhythmic notation" as your staff style. The slashes appear in a fixed position regardless of transposition (I think there is an option somewhere to control the position). But it's not a perfect system. You have to enter actual notes for the rhythmic notation and they do play back unless you do something about it. And having multiple voices on a staff does not move the slashes, so in those cases you need to enter regular notes and convert them to stemless slashes much as you do with MuseScore today..

As I see it, once you've chosen a range of measures (or parts of measures - we do see this mixed with regular notation within a measure), there are a few different things you might want to do with the notes in that range:

- replace content for display with stemless fixed-position slashes, one per beat
- replace content for display with stemmed fixed-position slashes representing the rhythm
- optionally suppress playback

The first two are basically radio buttons; the third a toggle that can be combined with either of the display styles. Finale also provides an option to suppress display of items attached to the replaced notes, but this strikes me a unnecessarily global in scope. I'd often want chord symbols, lyrics, and "stage directions" (eg, D.S. al Coda) to appear, but not articulations or other markings intended just to make the playback sound good. Just being sure that this mechanism works in conjunction with the ability to hide individual elements would be sufficient, I think.

This also needs to be controlled voice-by-voice, so you can have on voice with normal notes, another with slashes or rhythmic notation. And as mentioned, a global option to control the default position of the slashes, but they need to be treated like rests in the presence of multiple voices on a staff.

Title Ability to turn rests into slashes Add native support for slash notation

Just a name change to reflect the fact there are different ways this could be implemented.

Status (old) active patch (code needs review)

Here is a "low weight" implementation of native slash notation, described in some detail in the PR comments:

I've tested the code pretty thoroughly and it works as intended. One could quibble some of the design decisions I made, but my goal to was to minimize the amount of change to the "core" functionality, and I think I've done that as well as possible while still producing an effective solution. Here's the summary from a user perspective:

Using two new commands in Edit / Tools, you can either fill a range with slashes or toggle between normal and "rhythmic" notation. In either command, the slashes are not affected by transposition or by ekly or key changes, which is the important thing here. The slashes are fixed to a specific staff line, chosen for you by default (middle line for voices 1 & 2, above staff for 3, below for 4), but you can use the Inspector to modify this.

So the basic use cases supported by the plugin still work, but better - no need to select the clef or key, nd no need to worry about transposition or subsequent clef/key changes.


Is there a nightly build with this available yet? When one becomes available I'd be glad to put this through its paces. I've been wanting this (as you know :-) ) for a long time. Well done Marc!!!!

- Mike.

Thanks! If/when the PR (= "pull request") gets merged, then this issue shuld automatically be updated. It will be marked as fixed, and there will a comment added that names which build you can find the change in.

We weren't planning on dealing with this until after 2.0, but at some point recently when discussing what might need to be done for the new plugin framework to allow some of the old 1.3 plugins to be ported and perhaps improved, it started to seem like simply implementing a few of them as native functions might actually be easier/better. Specifically, this and explode / implode (which were done and merged in a couple of days ago, so they are already in nightly builds).

Can't wait to give this a try.

For what it's worth, I just gave the Explode/Implode native implementation a try in one of the latest nightlies... outstanding! I don't know all of the intricacies of how it works in all situations (I only tried the simplest thing... splitting up a chord of 4 notes over 4 staves), but it worked exactly as expected and will make some of my arranging jobs for my horn band a whole lot easier.

Thanks for all your hard work!!!!

- Mike.

Just grabbed the latest nightly. Gotta say... BRILLIANT! Thanks SO much for getting this in. This and the native implode/explode will make writing arrangements MUCH faster and simpler for me.

Well done sir!!!

You're welcome. It's been something I've wanted to see happen a long time. If you encounter bugs, please file new issues. Feel free to suggest improvements too, but realistically, I am not planning on making any significant changes for 2.0.