'Delete'

• Dec 27, 2011 - 01:14

An issue that I run across rather frequently is 'phantom' displays of material that I had specifically selected for deletion. As you can see in the attached screen cap (Delete.jpg), I have been able to select the whole rest 'behind' the C-sharp because the note really isn't there. Yet, try as I might, I cannot select it, much less delete it. (It had originally been selected as a part of the material I had wished to delete, but it refuses to go away.)

Even when I attempt to figure out just what is 'holding' the material, I'm not always successful in fixing the problem. In the example here, one might infer that the reason the phantom C-sharp is still around is because of the lyric 'We' underneath it (which indeed was paired with the note originally before I had chosen to delete). What is strange is that although the lyric 'We' should have gone along with the C-sharp when I pressed Delete, it too hung around. However, as you can see by Delete1.jpg, I *am* able to select the lyric and delete it. Yet...the phantom C-sharp remains.

This is a good example of what I was discussing in my original post about the inconsistencies of the base architecture. With these 'features' all being developed independently from one another (notes, accidentals, lyrics, Select tool, Delete function), it's no wonder that they will 'argue' with one another when the user attempts to force them to interact with one another in order to arrive at the planned condition in the score.

Architecture based upon WYSIWYG would force the tools to examine what the user sees on the screen and analyze what a command's intention is prior to execution. Then, when this standard has been firmly established, the instructions would be sent to each element of the desired function to carry out it's orders as commanded by the user. In my case, the C-sharp as well as the lyric was indeed selected for Delete. All of the other material in the range selection indeed deleted properly and completely - why this remnant?

Forcing the discussion into a specific tool's domain only addresses * that* particular issue in *that* particular case, then forces those coding the tools to have to deal with the issue all over again should it arise somewhere else. After all, which tool is to 'blame' for this phantom? Something ended up 'telling' the screen display not to delete the note and the lyric, but my guess is that since it wasn't held responsible in the first place to a base standard, then this 'display checker' will now have to be written into the tool.

It wasn't my original intention to get each of these tools to receive 'bug fixes,' but to ask: how could the original command of the user been ignored in the design of the tool in the first place?

Attachment Size
Delete.jpg 43.15 KB
Delete1.jpg 29.95 KB

Comments

Without the score, it is impossible to say, but if that rest is in voice 1, that is why you cannot delete it. This is by design: voice one must be full. If you want to mark the rest invisible, you can certainly do that.

As for the phantom C sharp, that sounds like a bug, plain and simple. Not sure you see this as something "architectural"; I can't see any basis for that. Bugs creep in one at a time, and they get fixed one at a time. Totally rewriting the interface would just lreplace lne set of bugs with another. If you want to get rid of bugs, you track them down one at a time and fix them; you don't rewrite the application. But in any case, steps to reproduce, as always, would be most useful.

In reply to by Marc Sabatella

First of all, my original post said nothing about deleting the rest in the bar. I selected the rest to show clearly that since it is a whole rest, it explains why the note cannot be selected. In 4/4 time, if there was indeed a quarter note (or whatever the note really was since it has no stem), then other rests would appear in the measure to mathematically resolve the existence of the note. The rest is in blue (selected) and the 'note' still appears.

1. Create a line of music and lyrics (I've attached the original to this reply that shows Line 1 before the contents were deleted).
2. Select C-sharp in first measure of first line.
3. Range-select (Shift-click) E in 3rd measure, 4th line (all four voices of first line are selected - all are showing in blue with blue border around all measures).
4. Press Delete key.
5. All notes are deleted with the exception of the piece remaining of the first C-sharp as well as the lyric which was associated with this 'note.'

That's it, really nothing to it. What I meant by standardizing things here is that if you think it's a bug associated with a specific tool, how can you tell which tool contains the bug? However, regardless of origin, if the Delete function checked its operation prior to exit of its routine against the display, it would see that it hasn't deleted everything. This check - included in testing - would always flesh out the inconsistencies because if "Selection to Delete" NOT EQUAL to results display, then the tool has malfunctioned. In this sense, ALL tools would be written to this same standard.

Barring this, the poor man's way of checking the routine is with a simple screen refresh - either performed automatically at the end of the routine, or by at least allowing this as a user-executed option in the Menu.

Attachment Size
OriginalB4Phantom.jpg 69.66 KB

In reply to by greg.winters.10

I can't reproduce... Can you explain what you mean by " Range-select (Shift-click) E in 3rd measure, 4th line (all four voices of first line are selected - all are showing in blue with blue border around all measures)." ?

Poor man solution is implemented... File -> Save. File -> Reload.

What you encounter is probably a refresh problem indeed and it would be great if we could reproduce it to fix it...

In reply to by [DELETED] 5

If you attempt to use Reload as Refresh, then MS wants to know what you wish to do with the changes you have made. This is not always a slam dunk. In fact, part of the issue you face with the unwanted material could have something to do with what you have been composing. Thus, if I save the changes, then I have to undo everything to the point where the unwanted material appeared. If I don't save the changes, then I lose everything I've done up until the last Save operation.

I didn't think that my explanation of range-select was too difficult to understand: select one point, hold down Shift key, select second point, range is selected. This is a standard Windows function and I'm glad that most of the tools in MuseScore conform to it. I provided the range points: initial C-sharp in top voice first measure, last E 4th voice 3rd measure. If there are easier ways to describe range-select in MuseScore, I would certainly appreciate learning what they are!

In reply to by greg.winters.10

I've created lines of lyrics like this many times and not seen this bug. If you can do this reproducibly with a specific score, posting that specific score - not just a screen shot of it - would help. That's usually the key to something being reproducible. What you are describing doesn't happen with all scores - just, apparently, this one. So posting that exact score would help.

In reply to by Marc Sabatella

I've only been able to reproduce this error one additional time. I know this is frustrating because it's not consistent. Believe me, I've worked many hours with this before posting to this forum. I had thought that these issues would be consistent enough to reproduce, but they seem to have dependencies upon some sort of sequence of events in addition to the refresh of the display. Thus, I resorted to screen caps so you would see that I'm not crazy.

What I had thought th approach would be is an examination of the code not from a 'debugging' standpoint, but from an overall investigative perspective which would ask: what makes the condition shown in the caps even possible? Maybe that's a stretch, but without consistent malfunction, I don't know of any other way to investigate.

Attachment Size
If We Are The Body (K-Synth).mscz 2.83 KB

In reply to by greg.winters.10

Sorry, I misunderstood what you meant by "it" in the first paragraph of your original post when you said you couldn't delete "it". I thought you meant the rest the picture showed as selected. You apparently meant the stemless note itself. Without knowing what that note is or how it got there, it's a little hard to figure out what might be going on - is that a note in a different voice, or a note in another measure that was nudged into this position, or a purely graphic element placed with the Symbols palette, etc. But in any case, assuming this is a regular note, then what you have here would seem to be a very straightforward bug - in some cases, notes aren't deleted, or leave artefects behnd. As always, specific steps to reproduce would help in tracking the. Ug down.

The idea of Delete performing an extra sanity check against what is being displayed seems like sound, but it's probably more complicated than that, because Delete does not nor should it necessarily delete everything being displayed. For instance, currently, it delees notes but leaves chords, and about half the time, that's exactly what I'd want - and the other half I wish it deleted the chords too. If I've added markings like voltas, repeat bars, segnos, codas, ec that are not attached to specific notes, I almost never want selecting the contents of a measure and htting Delete to delete those markings. For elements placed as graphics from the Symbols palette, it's probably about 50/50 as to I'd want them to be deleted. Same with dynamics, etc. Default whole rests are not deleted at all. Notes are replaced by rests, not deleted, etc. Anyhow, again, it seems like a nice idea to do this sort of sanity check against display, and there is prpobably a way to do something along those lines. But still, fixing the bugs that make such additional checks necessary is important too.

In reply to by Marc Sabatella

...but (again) I assumed that the default condition for Delete would be what someone would encounter when using paper. The score has it's basic layout (clefs, time and key signatures, measures and bars, etc.) and it has it's more 'unique' material (notes & rests, dynamic markings, etc.) - things which are dependent upon the music composition and their positioning.

Actually, MS does a pretty doggone good job of distinguishing between these when performing a standard Delete - very impressive. I have no quibble with its choices, but I can see your point: one person's 'fixed' value could be another person's variable. This is why I have attempted to use different types of range selection when performing deletes. Example: you can select ranges of measures, or you can select ranges of note or figures. This infers that there are indeed different types of deletes.

Good topic, though.

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