Applying clef changes to selected bars only

• Oct 22, 2014 - 10:39

Hi

New user here.

I am arranging some some Bach solo flute music for bass viol, inputting it in the original key, then transposing to keys and clefs suitable for the viol. Viol players prefer to change clef rather than read lots of ledger lines and in music like this will switch between Bass and Alto clef.

While it is not very difficult to do, each clef change that I make applies to the whole of the rest of the piece, so that I have to keep changing back and forth, and if later I am asked to make the change at a different place, I have to redo all the other changes after that point.

Is it possible to select a group of notes and apply a clef change to those notes only, so that following ones are not changed? It is not a big deal if it can't be done but it would be very convenient. I am using 1.2 - is this feature available in version 2.0?

(I am using 1.2, as that is the only version available in my Linux distro's repositories -- MX-14, Debian Wheezy. I think I can get 1.3 without much problem but not 2.0.)

Finally I'd like to say that I'm very impressed - over the years I have dabbled with various programs but find this the easiest and most intuitive to use. The Akai LPK25 keyboard works brilliantly with it. My main interest is making arrangements for viol as above, or for organ.

cheers
BF


Comments

Hello, and thanks for your comments!

I'm not understanding what you mean about needing to redo clef changes. That should not be necessary. When you add a clef change, it should only affect the music up until the next existing clef change, which should be left intact. Maybe there is some corruption i the particular score you are working on, or something about how you are doing this that is causing you to see an issue? If you post the score you are having problems with and specific steps to reproduce what you are seeing, hopefully we can help.

In reply to by Marc Sabatella

The issue raised by the original post is very familiar to me, and I too have been very frustrated by what he describes.

Consider a word processing analogy - underscoring, say. Imagine if you had to turn on underscoring and it applied to the remainder of your document (or, at least, up until another instance of underscoring). You would have to go to where you want the underscoring to end and apply an instruction to turn it off there.

That's not how we expect or want underscoring to work; instead, we want to select what we wish to underscore ... and have the 'underscore on' and 'underscore off' be placed at the beginning and end, respectively, of the selection.

Unless I have misunderstood, this is exactly what's referred to here: the ability to select a group of notes that are, for example, in treble clef and then implement a clef change only to those notes. The clef would change at the start of the selection, and - most importantly - change back to treble clef at the end of the selection without disturbing or affecting anything anywhere else in the score.

In reply to by [DELETED] 448831

Yes, I can see the value of selecting a range first, rather than needing to insert the changes at each end of the range. Selecting the range first would save one or two clicks I think, so it does seem like a win over the current method in this particular use case and hence could be worth providing as an additional feature at some point.

Still, what the OP is describing is something different - some sort of bug where every clef changes wipes out other existing clef changes forcing him to redo them. That definitely should *not* be happening, and that is what I am trying to understand here.

In reply to by Marc Sabatella

Sorry - my post crossed with Marc's.

The clef change doesn't wipe out earlier clef changes, but does wipe all the subsequent ones. Isn't that inevitable if you can't select the range first?

Say I have 30 bars in the alto clef, but want bars 10 to 20 to be bass clef, I change clef to bass at bar 10, then change back to alto at bar 21. But if the player then asks for the bass clef to start at bar 9 and I make the change, it overrides the alto clef in bar 21 and I have to redo it.

It is not a big deal but gets a little tedious in a long piece.

In reply to by [DELETED] 448831

Yes - stevbob's underscore analogy is a good one and you describe exactly what is happening in my score. It starts in alto clef but switches between alto and bass clef a few times. When the player for whom I did it asked me to alter one of the places where I had changed clef, it applied the change to the whole of the rest of the score so that I had to go through the whole lot again to make the rest of the clef changes.

If the same thing happens in version 2.0 (which I can't test) then I hope it can be improved to work as you describe:

"...select a group of notes that are, for example, in treble clef and then implement a clef change only to those notes. The clef would change at the start of the selection, and - most importantly - change back to treble clef at the end of the selection without disturbing or affecting anything anywhere else in the score."

In reply to by Brer Fox

First, realize that under the hood, clefs are different from underlining. Underlining is literally applied to every character within the selection - you see an actual underline below each. Underlining a selection is exactly the same as underlining character individually. Whereas you certainly don't want to see a clef in front of every single note. So in that sense, you are asking for applying a clef to a selection to work very *differently* from underlining - you want it to *not* work the same as applying it to each note individually, whereas with underlining, you do.

I point this out because in 2.0 builds currently, applying a clef to a selection *does* work like underlining in this sense - it dutifully applies the clef to each individual note, so you end up with a clef in front of each. Not what you want, obviously. It may indeed be possible to alter this behavior; feel free to file an official feature request in the issue tracker.

Anyhow, back to the real issue you are describing, where adding a clef change deletes subsequent ones. That isn't really supposed to happen in general, but I think i now understand what you are referring to. Say you start in treble clef, then change to alto in bar 10, then back to treble in bar 12. If you then decide you wish make bar 4 also be alto clef, adding an alto clef to bar 4 in version 1.3 will remove the following alto clef because it happens to be the same as the one you are adding and MuseScore thinks the one in bar 10 is no longer needed. And then when you try adding a treble clef in bar 5, the treble clef in bar 12 gets removed, again because MuseScore doesn't think it's necessary. And so on and so on, with a potential ripple effect that *eventually* causes you to need to replace more than you you should have needed to, even though they don't all disappear at once. Does this sound accurate>

So it's not that adding a clef removes all the subsequent clefs, but in 1.3, it *will* remove the very next clef if it happens to be the same as the one you are adding. In 2.0, this is not the case. You can happily add your alto clef in measure 4, and the alto clef in 10 remains in place. Some would consider that a bug because they'd *rather* it be removed automatically, but that depends on your use case.

Meanwhile, in 1.3, it's possible to workaround this automatic deletion behavior. Instead of adding an alto clef in bar 4, add some other random clef - bass, say. Now you can add the treble clef in 5, and then change the bass clef in 4 to alto. So one extra step, but that

As for the feature request, I agree it is a ncie idea. Howeve,r if you consider how things work in 2.0, you'll see it is actually not much if any of a savings. To create a selection and then apply a clef you would do something like the following

1) click first note/measure of range
2) shift+click last note/measure of range
3) double click desired clef

Three clicks, and you might think you can't improve on that. But currently in 2.0 builds, you can manage this in only two operations if you don't mind drag and drop:

1) drag first desired clef to first note/measure of range
2) drag second desired clef to first note/measure *after* range

Personally, I don't like drag and drop much, so I'd rather click my way there. I can still do this in only clicks:

1) click first note of range
2) double click first desired clef
3) click first note after range
4) double click second desired clef

Again, I do agree that in some way, the idea of first selecting the range and then double clicking the clef seems more intuitive and even marginally more efficient. So it is definitely worth filing the feature request. But I do want to assure you than in 2.0, it really is about as easy as that already. And even in 1.3, you can get the desired results with only a small amount of extra pain.

In reply to by Marc Sabatella

Given that this would appear to be one of the less common feature requests it might not get coded into the main program as there are other, more popular, requests. Would it be possible to do this as a Plugin, though? I haven't got to grips with the new Qt coding yet but I see the "Break every X measures" might already have some of the required elements (start and end of selection get identified, jump to start of selection and then do stuff, stop before end). You'd have to get it to identify (and save the answer) the last clef placed prior to the start, add the new clef just before the start and then add the saved clef type just before the next note or rest after the selection.

I can't see a way to tell the "current" clef other than reading back until you find a clef sign and I don;t know how to do this, nor do I know how to place a clef on the score (or a chord, for that matter or most of the new Plugin architecture but someone might?).

In reply to by Marc Sabatella

Hi Marc

Many thanks for taking the time to post in such detail. What you describe is perfectly logical and isn't a problem when making the clef changes in the score for the first time. However I did find that when making subsequent alterations or 'corrections' to my initial decisions, the new clef did sometimes overwrite until the end, so that I kept having to re-enter my clef changes to keep the number of ledger lines within bounds.

Note that I am using 1.2 which occasionally hangs on me at other times, so it may just be an occasional bug. Closing the program and then reopening (when it recovers the file successfully) solves the problem for a time, and then the clef changes behave themselves.

So basically, no worries.

Meanwhile I have managed to get 2.0 beta running on Wine and am looking forward to exploring that. I particularly like all the extra features which will be useful for early music editing, and the ability to enter figured bass.

My congratulations and heartiest thanks to all those who have developed this wonderful program and who provide support on this forum.

Salut!

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