Time signature change should not destroy notes
Currently, when editing an existing score, inserting a time signature with fewer beats per measure will discard the additional notes in each affected measure. This is not desirable. Usually I will either
- Plan to insert a different time signature within a few bars, restoring the later section to the original time signature, and thus those extra notes wind up being unaffected, or
- Preserve those extra notes either by a) changing their durations to make them fit, or b) spreading them into later measures.
Whenever reducing the time signature would cause notes to be 'surplus', MuseScore should probably do one of the following, preferably under control of some global setting:
- insert additional measures wherever needed to accommodate extra notes
- change the affected measure's settings so that their nominal and actual metric lengths are different (perhaps put the extra notes in red?)
- spill over notes into successive measures until a barline or long enough rest is encountered
- ask me how to handle it
Comments
MuseScore is a very cool music scoring tool. But it can be very frustrating for someone transcribing work, or a new student working on something.
We make a lot of changes. changes do not always flow in strict musical rules, AS WE MAKE those changes. I may want to change a standard 4count measure to a pickup beat, and shift notes to the left. or realize that I needed to change a quarter note to a dotted eighth note and 16th note, Doing this requires one change at a time, and this is changing the way the rhythm is written, and as i make the first of three changes, MuseScore now adds rests, deletes notes and otherwise messes up my work.
I would love if we could have an EDIT mode, where we can turn off the strict measures, be able to do any and all edits we want. Then do something like a "rules check" where measures are highlighted when the strict rules don't match,
This would be a toggle on /off switch, probably in menu or preferences, that can turn on free edit, or turn on strict rules.
a drop down would also show up for the rules check.
That way, we have traditional strict rules for those that are experienced and know what they are writing (every do your entire symphony in pen?) and those of us that tend to use a bit of pencil and a lot of eraser, and need to make more massive corrections.
In reply to Time changes should not alter score by jodarc
It can take a minute to learn how to use MuseScore, but once you get used to how it works, I think you'll find that everything you describe is actually quite easy. Not that there aren't occasions when being able to delete or insert a note and have things automatically shifted around wouldn't also be handy, but again, once you get used to how things actually work, it's never any more difficult than making the same change with pencil and paper, and usually a lot easier. If you need help, try asking some specific questions: how to accomplish some specific task, with a specific example - and people here will be happy to help.
In reply to It can take a minute to learn by Marc Sabatella
I have been using muse score for over a year. I understand how it works. I get that it shifts things around. but what I am saying is that an improvement might be to be able to turn off that feature. As it gets very difficult, when you realize you had the rhythm wrong in a song, to go back after it is all written out, and change the rhythm.
Try writing out an entire 12 measures in 4/4 quarter note time. Now go back to the beginning, and change it so that the 3rd and 4th notes are now a swing style. Make the 3rd note in the rhythm a dotted quarter note. Now your other note is wiped out and an 8th rest appears. wonder-fucking-ful. can you instead change my quarter note to an 8th note/ rather than wiping it out and putting in rests?
I don't want you to do that while i am making massive rewrites. I tend to copy a song I have written, then alter it to a new rhythm. it seriously sucks doing that in musescore. it is easier to rewrite the entire thing by scratch. which is what i now do, pulling out a pencil and paper. and walking away from the program.
so you are suggesting that is the solution? throw away the program because it is so rigid in its rules, it is not adaptable? Seriously, it is not hard to find times when I would like to alter things, maybe even just slide the rest to the other side of the note. but no, i have to reset that rest to a note, then change the next note to a rest. it is not like i have not learned out to work around your product, but really, if Microsoft word deleted an entire paragraph in your essay because you chose to change the sentence structure, and you change the first word, it sees it does not grammatically fit, so it wipes it out? that is really a program that i would want.... saves so much time rewriting everything. the reason we have these programs is to make things faster, and cleaner. but yours makes writing music so much slower. it is cleaner, but i am working to learn lillypad, cause i think coding might be easier than working within your strict rules.
and in the future, when users suggest ideas, don't blow them off cause you find your product easy to use. not everyone has crystalized ideas as they write, or write the rhythm before the notes. we all work differently
In reply to I have been using musescore by jodarc
For the record, MuseScore is not my product; I'm just a user offer to help you, since it appears you still do have some confusion over how MuseScore works (your examples, for instance, are cases that MuseScore actually handles well - see below). Anyhow, rather than get mad and swear at me because you don't like the help I am freely offering, you could try being more gracious that fellow users are trying to help, and then discussing the solutions rationally.
So, returning to your examples: if you have a two quarters you want to change into a dotted quarter followed by an eighth, simply click the first eighth and then hit the dot (icon in toolbar or on your keyboard). The note you had clicked will be lengthened, and the next note shorted accordingly. Two clicks and you've accomplished exactly what you want, and the rest of your measure remains unchanged. I am not sure what you are doing that causes the second note to be deleted, but if you describe what you are in doing in more detail, perhaps I can help you see why it has the effect it does. But simply clicking the note then the dot does exactly what I think you are saying you want, with no deletions.
Or perhaps I am misunderstanding something about what you are trying to do, but if so, simply ask again and explain more clearly what you are trying to do. Again, no need to get mad at me for trying to help you.
As for how to "slide the rest to the other side of the note", you need to think about what effect that has *musically*, not graphically. You are talking about keeping the note the same length but having it play earlier in the measure - at the time the rest currently occupies. So, simply cut the note from its current location, then paste it where the rest is. Again, perfectly simple.
You made the analogy to Word, but comparing to a desktop publishing program is more apt. If you increae the size of one object, a DTP does not move other elements around to accomodate, nor should it. An enlarged element with cover an adjacent element. If you don't want that, you need to move the adjactent element first to make room. It's not really clear exactly how you got the impression that MuseScore "shifts things around", but actually, it's rather the opposite - it tries hard to change as *little* as possible. It makes the change you ask it to while keeping the rest of the measure from changing at all except as absolutely necessary. That is, if you change the length of one note at one point in the measure, it may need to pad it with a rest or steal time from the next note, but the rest of the measure will be unchanged. Normally, that's exactly what you want - you want a change to one note to affect that note and leave as much of the rest of the measure unchanged as possible.
I recognize that you'd rather have such a mode in which you are allowed to create incorrect measures temporarily - lengthening a note doesn't steal from the next note, but rather creates an incorrect measure, that will correct later. That's more or less how Finale works. Having used both extensively, I can tell you the Finale way is neither better nor worse overall, just different. On average, any given edit generally takes about the same number of clicks. Anyhow, I can see how a Finale-like mode would ocasionally be useful, but as far as I can, it's actually not needed in the examples you describe.
In reply to For the record, MuseScore is by Marc Sabatella
I am sorry i got angry. I assumed I had posted in Features, so that someone from MS would answer. And it sounded as if you were just brushing aside my request.
I have seen MS remove notes, perhaps i gave a bad example, as i was not near the program that i was working on. but i have found not just myself, but others in my musical group give up on the program due to the strictness of the measure rule, while you are doing a wide spread edit. It is very frustrating. I have learned to use it, and often, i make a copy and keep an eye on what is getting deleted, or how it is shifting. I am fairly new to music, so it is not as easy as reading letters and seeing it slid a bit. It is very very confusing.
If you have a DTP, it may cover what you resized, but you can send it to the back and pull the hidden object out, move it where you want after you resize the first. it does not drop anything within your page... it just hides it from view. I do not see how MS hides things from view, well at least not in a retrievable way....
:-)
In reply to sorry by jodarc
Don't get me wrong - again, there are indeed some cases where an edit mode such as you describe might save a keystroke or two on occasion. But your examples are actually very good at showing how something that seems very difficult at first can often turn out to be very easy once you see how it works.
BTW, it is true a DTP just hides elements rather than deleting them. MuseScore is not *exactly* like a DTP, and doesn't have "layers" in this sense. So instead of uncovering the hidden object after the fact and then moving it, you do have to move the object *first*. Still, what MuseScore shares with a DTP is the basic idea that when you place an object, it should to stay in that position until you move it. And this basic thinking is how either MuseScore or a DTP differents from a word processor. Once you get your head fully wrapped around this, lots of things that seem surprising at first end up seeming very straightforward. Being new to music might make it difficult at first to get used to the idea of notes having specific time positions rather than sliding around without touching them, but that really should become more comfortable with time.
Anyhow, MuseScore does *not* delete notes for no reason - the only time notes woild normally disappear is if you lengthen a note so much that it completely takes up the entire duration of the following note as well. And the solution is very simple - you just have to realize that what you want is to *move* the note to a different time position. So do that before lengthening the previous note and all is well, with no more effort on average than it would take to lengthen the note in a word-processng style editor and then do whatever else you would need to do to shorten the measure again so it has the correct number of beats.
Again, yes, there are some occasions where you might save a single keystroke or two in the other mode - but just as many where the MuseScore model ends up being faster. As someone with extensive experience using both types of programs, I can say with absolutely confidence that on average, they are about the same, with if anything a slight advantage to the MuseScore method.
In reply to I have been using musescore by jodarc
I think the problem here is that what you are proposing will mean extensive redesign and programming at a low level in MuseScore.
This doesn't mean that it will never happen.
But it is unlikeley to be included in version 2.0 as the devs are beginning to get near to releasing it.
Personally I agree that it would be a good feature to have - I have just arranged one of the plainsong Mass Propers, and having finished realised I had written it in quavers with a crotchet main beat instead of crotchets with a minim main beat.
It is going to stay that way for the time being as I don't have the time right now to do a complete rewrite, which is what is going to have to be done - unless I can wangle something with MIDI export and then importing back in.
In reply to I think the problem here is by ChurchOrganist
I think what you are talking about in your example is a different type of transformation - an automatic expansion or compression (augmentation / diminution) of note durations within a selection. That would be useful too, I agree, but I don't think that would require any major rearchitecting at all. That's actually something I have long thought belongs in MuseScore, and that too has been the subject or several other threads. I even started trying to write a plugin to do this shortly after getting into MuseScore, as I had done exactly the same as you and wanted a way to fix it.
But the subject that was being discussed by the previous poster is something a bit more hands on - not just selecting a region and running a simple command to expand or compress durations, but rather a hands-on editing mode that let you drag notes around, add new notes, change lengths of note individually, etc.
Actually, even that probably doesn't need to require an extensive redesign either, if it is implemented as a new mode that operates just on a single measure at a time. In fact, it could almost even be a plugin, if the plugin framework were more sophisticated. There was a previous thead that went along similar lines, and what I took from hat discussion was the idea that you might select a measure, hit a button to enter this new mode, and the current measure would then be displayed, either in a separate window or just kind of zoomed in within a frame in the current window (I'm basically describing how Finale shows the current measure in its editing modes). While in that mode, you could then drag notes around like in a graphics program, and also insert and delete notes or change their duration purely garphically. MuseScore would not be thinking in terms of time positions at all while in this mode - it,s just providing you some symbol manulation tools.
When you were done, MuseScore would look at the symbols and only then recompute the necessary pitch and time position values. If the measure turned out to be overfull or underfull, MuseScore would truncate or pad as necessary, perhaps popping up a dialog asking how you want it done.
I could also see this mode also being the mechanism to move a note from one voice to another as discussed in other threads, although now you're introducing all sorts of possibilities for creating measures that are underfull in one voice, overfull in another, etc.
Anyhow, as long as you see this as a new mode that sits on top of the more usual Sinelius-like note entry method, I think these could co-exist without requring any chanes to the underlying architecture or to anything about how regular note entry works. In fact, since it could be done more or less completely independently from the rest of MuseScore, it seems like this could make an interesting project for a motivated programmer looking to get his feet wet in MuseScore coding. A single menu item (with icon and/or keyboard shortcut) that would load the contents of the current measure into this special window, provide the editing controls in that window, parse the results, and replace the original conents of the measure with the new contents.
But still, it is important to keep some perspective and realize that many of the things that people at first might think would require a brand new mode like this to accomplish, are actually achievable easily enough in the current note entry node once you realize how, as in my suggestions above for turning two quarters into dotted quarter eighth, or moving a rest after a note.
In reply to I think what you are talking by Marc Sabatella
I agree, this is a good way to look at the problem. Many of the points raised in these feature requests are really UI issues -- "We need a front-end way to complete THIS task before turning over a completed measure/phrase to MS". Kind of like the way little Ajax mini-editors let you complete various front-end tasks on blogs and similar sites. This is the sort of stuff that falls out of paradigms like model/view/controller. Most of my own difficulties with MS have to do with rapid/repeated editing tasks rather than dealing with the underlying notation and final-quality printed score; they're related but distinct problem spaces.
In reply to Good analysis by spinality
Thank you, this is exactly what I am talking about. whether it operates on a single measure, or if you can freeze the whole score, at least a single measure would allow some human thought and work, without the computer second guessing you.
I do apologize to everyone for being angry, but I posted in a "feature change" area, and felt that my request was being dropped. I just find computers that try to fix the creative mind are always asking for a disagreement.
Thank you for your responses.
I would still love an edit mode tho, as it would relive alot of tap dancing to get my scores correct.
Thanks again
In reply to Exactly what I am talking about by jodarc
I still think you are misinterpreting what Musescore is doing, though. It isn't trying to second guess you at all. It simply trying to let you make a change to a note *without also changing anything more than is absolutely necessary*. Consider, if you lengthened a note *without* stealing time form the next note, this has the effect of *changing the start time of every subsequent note in the measure*. That's exactly the sort of unintended side effect MuseScore is trying to avoid - you didn't touch the other notes, so MuseScore does everything it can to keep them from moving unnecessarily. Instead, it leaves all other notes exactly where they were. That way, if *want* to move the reat of the notes, you can, but MuseScore doesn't force this decision on you.
Again, the analogy to a desktop publishing program is apt. Enlarging one element doesn't autmoatically push other elements around - if you want to move them, you move them. Desktop publishing programs aren't in the business of moving your elements around without your asking it to, and similar, MuseScore is not in the business of moving your notes around without your asking it to. If you place a note on beat 4, MuseScore leaves it on beat 4 even if you subsequently make chanes to beas 1-3. That's the whole point - notes stay at the tome position where they were entered. If you want them to change time position, then you move them.
It is different, obviously, than a word processor, but that makes sense when you think about it. Words entered into a word processor are not entered at specific time position, or a specific position on the page. So it makes sense that lengthening a word somewhere woild automaitcally move everything else in the entire document to the right in order to make room for your lengthened word. That makes sense because words are not thought of as having a specific time or page position. While it would be *possible* to implement a mode like this in MuseScore, the point is, more often than not, it is *not* what you,d want. If you place a note on beat 4, you normally want it to stay there until you decide to move it. You don,t want edits to beats 1-3 changing that nite you placed on 4.
There are of course times when this is not the case - like if you were transcribing something and accidentally left out a note. Then you do indeed want everything moved over to accomodate it when you later onsert the missing note. But here again, there is nothing particularly difficult about doing this in MuseScore as is. You just have to realize that the effect you want is moving a bunch of notes. If an edit mode were added, it might save a single keystroke or two at most over doing it the current way where you move the notes yourself (via cut and paste). So yes, a small convenience on those particular occasions. But things really do work quite well already *once you understand how they work and how to get he effct you want*. it,s just different than a word processor, for a good reason.
In reply to I still think you are by Marc Sabatella
"MuseScore is not in the business of moving your notes around without your asking it to. If you place a note on beat 4, MuseScore leaves it on beat 4 even if you subsequently make chanes to beas 1-3. That's the whole point - notes stay at the tome position where they were entered."
You correctly describe how MuseScore operates today. However I don't think the purpose of MuseScore is to impose a particular usage paradigm on the user (as if it were saying "if you want this to operate like MSWord then you should use a different tool"). The mission is to make it easy to enter, edit, and publish beautiful scores. For me, this goal requires a number of different editing interface modes that correspond to what a naive user might intuitively expect to find (according to the "Law of Least Astonishment"). I should ideally be able to find ways to:
These are specific use case examples; and I've run across various other tasks where it seems the MS UI is working against me. As a tool user, I expect to find usage modes that correspond to the main tasks I am likely to need to complete. I feel that, at present, MuseScore omits several desirable usage modes. I don't think these would require fundamental changes in the MuseScore paradigm. They are just examples of UI sugaring that would make certain common or repetitive tasks easier.
And again, I understand and agree that MS doesn't currently work that way, and that many of these tasks can already be addressed with different techniques. So what? This is a place to discuss feature enhancement. Our goal, or at least my goal, is a tool that's as "easy as licking a stamp" -- where obvious usage methods, addressing the full range of likely user objectives, manifest themselves through a clear set of user interface elements.
In reply to "MuseScore is not in the by spinality
I think we are on the same wavelength here, but perhaos saying things differently. Yes, MuseScore currently works as I described, nit as some wish. But no, I'm not saying that if you wish it to work otherwise, you need a different "tool" - at least, not if by that you think I mean, something other than MuseScore. I think such a tool can and should be provided *within MuseScore* - as I described earlier, just another mode, separate from Note Input (aka Note Entry) mode. And indeed, this is a great forum for discussing such matters.
But stepping back a moment, there are two different things going on here. One is discussing how such a mode could possibly look and behave. The the other is helping the person to whom I was responding understand how to more effectively use MuseScore as it exists today. While that is perhaps a more appropriate discussion for the Support forum, he didn't ask there, and since he is obviously frustrated with how MuseScore works today, I do think there is value in having a discussion of how to alleviate that frustration *now*, rather than waiting two or three years (best case scenario; reality could be longer, or never) for a new editing mode to be implemented.
So when I go on and on (yes, I know I do that :-) about how things work currently, the intent is not to belittle the value of new features in the long term or to cut off discussion of how such a feature could work in the future. It is merely to try to help people get the most out of MuseScore in the present, by showing them how they *can* get the desired results in the program as it stands, even if sometimes it might take an extra click or two over what might be ideal for those specific situations. Sometimes it seems like it might be more than just a click or two different, but as the examples posted here show, sometimes that initial impression can be inaccurate. A lot of the operations we are discussing are not entirely obvious (like, how to "slide the rest to the other side of the note") at first, but become simple enough once you understand them. It's perfectly natural that some - myself included - are going to be a bit mystified at first by how things work. That would be true no matter what model were provided as the default editing model. There is no shame in needing a little help sometimes in finding the most efficient way to get things done, and it can only be a good thing when we help each other out in this way.
I would agree that this aspect of the discussion is best conducted in the support forum, though, not the feature forum. So if anyone has any other specific examples of edits you would like to make are but are having trouble figuring out how to do most effectively, or are running into any cases where you don't understand why MuseScore is behavior as it does - I encourage you to post about it in the support forum, and I remain happy to be among those offering help.
I wondered about this too - maybe it could be a plug-in.
I think there was a discussion recently, but is it related to quantisation ?
I used Guitar Pro in the past. I wanted to try a free alternative. The problem described in the original post is a nuisance. It is NOT simply a "Need to Get Used To". I've been developing computer softwares for years and working with Human Factors professionals, and this is a major user interface flaw that will drag people away from the application. The developers should get some inspiration from Guitar Pro. It handles the same situation like a boss, and allows the user to enforce correct beats by the use of simple visual indicators.
In reply to 100% Agreed by alexandre_thib
The problem describe in the original post - time signature changes not reflowing the notes - has already been addressed for 2.0, so no worries. Although really, changing time signatures on an existing passage after already entering it is not that common of an operation.