If you delete a staff, its notes go into limbo

Seems like this is a bug, because I don’t see how it could be useful intended behavior.

I have a piano grand staff. The left hand was actually for electric bass and the right had was for piano. So I eventually added the electric bass player and copied all the material from the left hand.

I then removed the left hand staff. It seems to me that the notes (all MIDI events) should go away when I delete the staff. But instead, not only do they remain, but they are still included in the playback. Worse yet, because you can’t select any of those left hand notes (even with select-all), they do not participate in a mass transpose operation.

It seems to me that at minimum, when deleting a staff that contains material, Dorico should at least offer to delete all that material.

I am able to clean this up by adding the staff, which makes the original notes visible. Then I can delete them.

Whether this behaviour is intentional or not, it’s behaviour that people use to their advantage on a daily basis. See here, for instance.

It seems like a bug to me. A new user would certainly not expect this behavior. The fact that power users find this loophole helpful to work around other problems, doesn’t really justify it working this way by default, IMHO. I believe the default behavior should be to delete material when you delete a staff (or at least offer to do so.)

I would have thought it is quite easy to set up extra playback-only instruments. Simply exclude them from the score you want to print.

I agree with you and hope this is addressed so that it doesn’t come back to bite me someday.

And I agree that just because someone found a use for it, does not mean it should be expected behavior.

Our main console at our church allows us to assign or remove channel strips to the console surface. If you have an active channel that’s sending signal and you drag it off the surface, the sound doesn’t stop… you just lose the ability to control it. Yes, it has resulted in panic several times.

This seems the same sort of animal, and I agree it’s not preferable. If the staff is gone, there should be no “ghost” notes.

I have just recently discovered this hidden staff behavior and it is quite frankly a brilliant feature for those of us that use key switches on certain sample libraries and need a separate staff on which to program these key switches, and then have the ability to hide this visually redundant staff. The great thing about it is that it doesn’t mess with the formatting of your other staves when you remove and then show it again for editing purposes etc. I certainly hope it is not a bug, but intended behavior. It is a hidden gem. If you don’t want the music on the staff to play back before you remove the staff you can select it all very easily and either delete it or suppress the playback. The advantages far out weigh any possible disadvantages IMHO. I would be extremely disappointed to see this behavior change and I’m certain I am not alone.

It’s definitely not considered a bug. Whether or not we can guarantee to always maintain this behaviour, though, is another matter.

I’m voting with Dan here. If the staff is gone any playback from that staff should be gone too. One of the great features of Dorico is how easy it is to add “playback” staves that don’t appear in the finished score. For those of you using this “feature,” why not just have another staff that appears in the playback score but not in the printed score? You still retain all the editing controls of the playback staff, since it still exists, but it doesn’t appear in the printed score. I was unaware of the ghost staff note situation, but have created separate playback and display scores for many projects.

One practical reason is that if you override the playback configuration to assign two players (“notation” and “keyswitches”) to the same MIDI channel, you lose all automatic playback assignments from that time on.

With the new playback and expression map features in Dorico 3, that reason might be less important, but just reworking old projects “because you can” doesn’t add any value to them.

One of the reasons we chose to make the music persist is that it’s easy to make transitory edits that would then potentially delete a lot of music, e.g. moving a signpost corresponding to the start or end of an ossia or a divisi would then delete the music instantly, and that seemed too destructive.

Actually, you could make the opposite argument: sometimes it’s a pain that there is no way at all to make ossia staves play back, even when they are visible!

By who? Unexpected, illogical, and unintuitive behavior is the very definition of a bug in software.

By definition, it’s not a bug if the software is operating as designed. You may question the design, but it’s not a bug just because the software is designed in a way that you don’t like.

The Hacker’s Jargon File offers some clarity on the relationship between bugs, features, misfeatures, warts and miswarts.

I can see that argument, but I really believe the software should offer to delete the notes when the staff is being deleted. If a person really wants to keep the notes, it doesn’t seem like clicking a “Keep the notes - I know what I’m doing here” button is too much to ask of them. This is the sort of thing that can be a bit spooky/confusing for newer users.

This might be a parallel to when one deletes a player and the program asks whether to delete the layout for that player as well (IIRC).

Very good analogy, Derrek.

From a user experience perspective, having the program throw up an message box when you select a signpost and move it with Alt+right, or when you try to drag it with the mouse, would be pretty horrible.

IMO that’s a good example of an infuriating “are you sure you want to do this” message, because the way I use the program the answer is always the same.

If the Dorico team think it’s too risky to delete the layout when you delete the last player from it, just don’t delete it, and I’ll do it myself with one click - but don’t keep wasting my time asking me the same question over and over again!

Frankly, I’d just as soon do without the “Do you want to destroy the layout” mssg too. I’m just saying that this is a parallel situation.

(If you look at the Finale forum these days, you constantly see the “why can’t it do this automatically” question. My feeling there is, “that’s not why one uses Finale;” and I’m happy for Dorico to do what it does and to develop along the lines the Team has planned.)