How to add rest?
In the score example attached, I have imported MIDI file MS2 output (latest version of the MS2). The challenge here is that MS2 can´t interpret the time signature change, which leads to the missing rest and wrong allocation of all the notes after that.
In the attachment there should be half rest in the beginning of the bar #78 - see the case in the bar #51.
In the bar #77 the time signature changes for a one bar which confuses the MS2.
Question: how to add a half rest to make all the following notes printed in their correct places.
| Attachment | Size |
|---|---|
| MS2_adding rest.pdf | 218.17 KB |
Comments
You actually don't 'add' the rest -- you 'cut' all contiguous notes (which begin on beat #1) from the wrong time positions, and then 'paste' them into the correct time positions (starting on beat #3).
Also, be advised that you must be very careful with copy/paste where there are time signature changes, not to mention the fact that midi import is risky to begin with.
Regards.
In reply to You actually don't 'add' the by Jm6stringer
Hi, Thank you for the help!
I´ve done this now in that way, it works although is rather time consuming.
I wonder why post-adding rest must be this complicated, could it be simpler?
Although the challenge above is a bit different, this all remains me of something I have considered time to time. Namely, why there seems to be a rather high threshold for some people to use the notation program. One reason, I believe, may be that many of us get easily frustrated to one feature in the most notation editor - this feature is the same in all of these programs, I would call it "strait-laced proactive guarding of the music-mathematical rules". I mean by that that the program is often not very user friendly. I don´t mean by this that the notation editors should allow the user to create illlogical, wrong scores. What I mean is, that there could be inbuilt utility to shorten the distance between the free editing and music editing.
One could call this tool "notation training wheels" which help the user over difficult things.
(BTW, the same thing concerns also many other software, not only notation.)
One way to implement this in notation, could be different modes.
In the future, if time to develop MS to that direction, there could be two different editing modes, "notation editor mode" and "graphical editor mode". The later would allow do freely all kind of editing like any graphical editor (Freehand, Draw, etc.), the notation editor mode would require following strictly those music theory rules and notation editor logic. There could be also a "proofreading" feature, which the user could run after making edits via the "graphical mode" to check the music-mathematical logic.
This would lower the bar for some people and activate thousands of potential users.
Please feel free to use this idea!
In reply to Hi, Thank you for the by Harry_
Cut and paste *is* simple, requires only a handful of keystrokes.
The problem with any sort of automatic mode that allows you to "isnert" a rest is that then MuseScore needs to *guess* how many notes you want moved to the right. Just the very next note? All notes in this measure? All notes up to the next empty measure? All notes to the end of the piece? Whatever MuseScore guesses is guaranteed to be wrong more often than not. That's why it is better to simply do the cut and paste yourself - you can guarantee you'll always get the right answer directly.
Not to say that it is impossible to create such a mode, and it might happen some day, but from experience with other programs that have it, I can say with some certainty that it ends up being *less* efficient on average because of the number of times whatever it guesses turns out to be wrong.
In reply to Cut and paste *is* simple, by Marc Sabatella
In my suggestion the "graphical mode" would be like any graphical editor, i.e. no need for MuseScore to "guess" anything. I would be free. Moving back to the notation mode, of course, would require proofreading. The program could give not of all the illogicalities and explain why those are incorrect.
In reply to In my suggestion the by Harry_
And there is the rub. A "graphics mode" (sometimes referred to as a "scratch pad mode" here in discussions) is all well and good, but it doesn't in any way actually solve the problem you started with - some unspecified number of notes are at the wrong time position, with some of them being in the wrong measures as result. If you simply added a rest with no further adjustment, you've actually made the problem worse, not better, as now you still have a bunch of notes in the wrong measures, but you *also* have the wrong number of beats in the measure you just added the rest to. So one way or another, those notes need to be moved. Either you do it yourself manually in the "graphics mode" - which could not possibly be any easier than how it is done now - or else MuseScore automatically guesses how many notes you want moved and moves them for you.
Your idea of a completely free graphics pasting system could be implemented by simply pasting all the marks into a graphics program, then trying to do musical image recognition on it. But this is fairly hopeless.
But anyway, your basic question about "inserting rests" is one that comes up again and again, and it represents a simple confusion which it is easier to sort out than to try and "implement". Consider again your general graphics program -- what is the analog of a "rest" there? It's called "space". Have you ever seen a function in a graphics program to "insert space"?? I think not -- because you make space by moving away (or deleting) any objects occupying it. Musescore works the same: you make a rest by moving away anything that would make it non-blank. HTH.
In reply to Your idea of a completely by Imaginatorium
Nicely described. Might this be added to the handbook discussion of rests?
In reply to Your idea of a completely by Imaginatorium
Actually, yes; that is a very useful (I would say, almost obligatory) function in a typography program. At the point where the Insert Space command is executed, all the unused space on that line would be inserted, enabling the typographer to flush text both left and right on the same line (as for a menu or table of contents, etc.). The lack of this function in word-processing programs is a tacit indication of the difference between them and real typesetting software.
As to the utility of such a function in a dedicated music-graphics program, I am hesitant to pronounce one way or another. I can't think of a use-case offhand, but that does not mean it doesn't exist. It only means I have not yet run across the need in my own work.
In reply to Your idea of a completely by Imaginatorium
I think this is a textbook example of the gap between an expert and (newbie) user.
Why many interfaces and especially software programs are not that user friendly as they could?
You say above: "...question about ´inserting rests´ is one that comes up again and again..."
I think that - no matter what genre or UI we are discussing - if some "same thing comes up again and again", the UI/software developer should think: "well, there seems to be a challenge, one thing which is difficult especially for the new/random users - how could we create UI which helps the user tackle this challenge easily without renounce any of the sophistication or accuracy of the program"?
If all the world developers - engineers, technicians, programmer, scientist and other expert - could time to time move their paradigm of their mindset from specialist-way "this is how it is correct way to do by-the-book", "this is the shortest way for us, i.e. it must be shortest way for everyone" and "this can´t be done - its not done before", towards user-oriented way, which includes different user groups with different starting points - many technical gear would gain many larger users/happier users. Read my idea of the "training wheels" above.
Too often the experts (all glory for them!) narrow way to think goes something like this: "this is the tradition, I have had to learn this thing, this means all people have to learn this way and understand the theory, before they are allowed to use this. Its their own fault if they will not use their time, I have used my time." (Does this sound familiar?) ;-)
I hope you got my point. My point was NOT that we should abjure the correct way to do things, or do some kind of "kindergarten" version of the MS.
But we should understand that the END RESULT is what counts. If more potential users reach the correct end result quicker, why not use "training wheels" (or give an option for training wheels) during the process, during the journey to that that goal. DESPITE this would mean that we have TEMPORARILY during the process give away some orthodox, pure science principles.
The whole idea is, that during this process, where these "training wheels" help the user get over the challenge, he/she LEARNS to do things in the "correct" way.
And finally - to put the above into perspective - note that I´m a big fan of the MuseScore.
My point is not to nag but give my humble input by giving some user-oriented comments.
I genuinely admire all the developers and people who give their time and knowledge help different users to use this free notation software. I will thank them all.
Cheers! Harry
In reply to I think this is a textbook by Harry_
For this reason, the idea of adding some sort of "insert note or rest" command is still being considered. But please read my responses again. As explained, the difficulty is that it would seldom actually have the effect one wants, because MuseScore would not be able to guess how many subsequent notes to move. People often think it would be as as easy as just inserting the rest and magically somehow the right things would happen, but once you really think through the issues involved, you see why it isn't. That said, some day we may well add the command anyhow, but be aware there is no way to avoid these issues, and that one way or another, one needs to make peace with cut and paste as a way of moving things, and that is why we have made this as easy as possible.
In reply to For this reason, the idea of by Marc Sabatella
@Marc Sabatella--I may be mistaken, but I think the OP is wondering about the possibility of telling MuseScore to input notes in a 'non-counting' mode. That is, the responsibility for placing the proper number of beats (and subdivisions, etc.) in each measure would be entirely the user's, just as it is for manual copyists using manuscript paper and Speedball pens.
While that 'non-counting mode' might not be something everyone would want, it COULD be useful for some users under specific conditions. (I have in mind a particular score I obtained from the Dresden Court Orchestra archive, the 'Schrank II' collection, wherein the copyist mistakenly placed six beats in a measure of 4:4. As a result, the entire rest of that movement was 'off' by those two beats, but someone wishing (for whatever reason) to reproduce that score as originally written might appreciate the ability to turn off automatic beat counting and simply place notes and barlines manually.)
There are a LOT of copyist's errors of this sort in old MSS; the ability to reproduce those as historical documents should be considered.
In reply to @Marc Sabatella--I may be by Recorder485
The specific use case he described originally (in the original post of this thread) was very different from what you are describing. I agree a mode that allows you to easily enter arbitrary numbers of beats in a measure could be useful occasionally, but it would *not* solve the original problem. The original case at hand required some unspecified number of notes to be moved forward in time, across measure boundaries. To do so currently, the user - the only one who knows how many notes should be moved - can simply select the passage, cut and paste it to the desired location. About 4 clicks total, depending on where you want to move it to, and you are guaranteed to get exactly the right results, since you know how many notes you want moved. MuseScore has no way of knowing, so there is very little chance it will just happen to guess correctly. meaning it will move too few or too many notes a good percentage of the time.
In reply to The specific use case he by Marc Sabatella
I saw his first post, but I got the impression I mentioned from his second one:
In the actual case at hand, you are correct to point out the way to solve this problem is to cut/copy everything after the error, insert the missing rest, then paste in the rest of the music starting on the proper beat (hoping, of course, there are no time signature changes to deal with).
In reply to I think this is a textbook by Harry_
Hi Harry,
As a newbie to MuseScore, I can relate to some of your points here. I started to provide some feedback in this forum to make the application more intuitive by suggesting enhancements to functions in the graphical interface.
Will an auto-fill feature address some of your needs?
See: https://musescore.org/en/node/105836
Cheers,
Dave
In reply to Your idea of a completely by Imaginatorium
A rest is a musical element like a note. (But, I know, in the current implementation you can't insert notes either)
EDIT: sorr, misplaced, was an answer to the message Posted by Imaginatorium on April 9, 2016 - 6:59pm
In reply to A rest is a musical element by frfancha
No problem, I expect.
In reply to No problem, I expect. by xavierjazz
"I may be mistaken, but I think the OP is wondering about the possibility of telling MuseScore to input notes in a 'non-counting' mode. That is, the responsibility for placing the proper number of beats (and subdivisions, etc.) in each measure would be entirely the user's, just as it is for manual copyists using manuscript paper and Speedball pens."
Yes, this is my idea of the "graphical editor mode" - a option of the free "manual copyist" way as you put it nicely. The user could choose either the whole score or activate the bar/area which he will edit freely. I wonder if this would be hard to execute?
As I wrote, an essential feature as a part of this optional mode is a proofreading, where the program check to music-mathematical logic of the freely entered scores.
As said before, I think this case is a textbook example how hard its to change a mindset for someone who is deeply involved expert in some area.
I remember reading some time ago an article about the research done in the 90´s among the (British) households concerning the VCR (video recorders) , the subject was "how many of the household members can program the timer of the VCR?".
The result was astonishing: the per cent of the people who were able to use the VCR timer, very essential part of that machine, was less than 50 %. When asked for the VCR manufacturer how they think they had succeeded with the development of the VCR timer, the common answer was "our research people have developed years this timer, they have tested it thousands of hours, its very logical, best of our experts have put their input to this. The user should read the manual included, its not our fault if they are too lazy to use some time with it to read and learn it".
Of course we all should learn things, study things. One can´t expect that you can´t evolve without hard work. But all kind of technology, in different areas around us will increase rapidly, you simply can´t be expert in everything. Therefore the development of the user oriented UI´s will be more and more relevant.
In reply to "I may be mistaken, but I by Harry_
Don't get me wrong - I definitely support the idea of such a mode. I think it would have many potential uses. So I don't think there is anything I am failing to understand here. What isn't clear, however, is if *you* understand that this mode would in no way whatsoever help with the actual case at hand - inserting a rest and moving some as-yet-unspecified number of notes later in time to compensate. If you think it would somehow help, then I think you need to explain more clearly exactly how you think ithis mode would work, because the way this sort of mode has been proposed and discussed in the past, it would definitely not have any bearing on this case.