Is there a way to change note duration later?

• Oct 13, 2012 - 16:09

I just want to enter in all my notes as quarter notes for now and worry about rhythm and duration later. The problem is that Musescore always deletes notes and automatically adds rest when you attempt to change anything.
Is there a way to make musescore just move everything to the right or left even moving notes into the next/previous measure if it needs too?

I dont wont to spend who knows how many hours redoing the whole score or copying and pasting each measure into a new score as I get each measure correct.

thanks, I am using 1.2


Comments

No there is no way to do that. You must fill the measure with actual rythm. You could change the duration of a note but MuseScore will automatically remove the notes after it or add rests if you shorten the note.
I can understand your workflow, but it looks very weird to me as a drummer, thinking rythm first, or at least thinking music as rythm and melody together and not quarter notes melodies...
Your best bet with the current tool is to create a score with quarter notes, print it or display it side by side with another score where you will put the notes and the rythm.

In reply to by lasconic

Hello MuseScore developpers,

I would like to back up the request in the message above: changing note duration should be possible in a flexible way. Could you consider improving this in MuseScore?

I work the following way (probably quite standard):
1) I play the MIDI keyboard and the notes (pitches) are recorded in MuseScore.
2) Since MuseScore doesn't recognize the length of the notes, I need to adjust their duration manually.

However, currently, it is nearly impossible to work that way because MuseScore does not allow to change the duration of a note without affecting the nearby notes (removing them or adding unwanted rests). Such situation is a real need. I hope this can be improved, so that MuseScore can be used by everybody.

Thank you.

In reply to by OCLC

I can understand you might like to work that way, but it is really an very unusual way to work, andn ot at all how most notation software is designed to work. While it's certainly possible that someday Musescore will be extended to support that type of working method, it would be a pretty big undertaking, and I certainly wouldn't be expecting it any time soon. Much better to simply learn to use MuseScore the way it - and virtually all other notation software - is designed to be used

In reply to by Marc Sabatella

I'm a bit puzzled this is regarded as an unusual workflow. When thinking in terms of melodies, tones or rhythms are both important - why favor one of them? If indeed this feature is not a part of any notation software, I'm sure it would be beneficial for Musescore to be the first to implement it (remember how browsers used to be without tabs for many years until Opera came along? ;)

My workflow right now is to copy all notes to the right, add a rest and paste everything after that rest. Could this be automated in any way?

In reply to by haugeto

In "most" cases (eg, people not trying to use MuseScore in this unusual way), just because someone changes the length of note doesn't mean he'd want the start times of the rest of the notes automatically changed, any more than changing the pitch of one note should automatically change the pitch of othernotes. So in this sense, MuseScore *is* treating rhythm the same as pitch. What you're asking for is for MuseScore to actually treat tome very differently from pitch - for changing the duration of one note to automatically alter the start times of other notes. I'm sure it is could be done if someone interested in this type of workflow were also a programmer and were willing to volunteer their services to implement it - this is open source software, after all. But anyhow, I'd say simplicity and consistency is probably why things are as they are - changing pitch of one note doesn't affect other notes, so neither does changing duration.

In reply to by Marc Sabatella

I see your point, and I certainly wouldn't want this to be default behavior. What I'm asking for is an insert feature for notes (as is already present for measures). This would not violate the simplicity principle you describe, and it would come in handy for those who think in terms of notes (as opposed to rhythms) first. There are already shortcuts for changing the duration of a note (W for doubling the duration): In my dream scenario, holding down the option key with this shortcut would double the duration but not overwrite adjacent notes.

In reply to by haugeto

If you search the forums, you'll find quite a bit of prior discussion of how an "insert mode" might work. This seems to be a reasonably popular request, and I certainly wouldn't mind seeing such an option myself, but I am not sure if the specifics of how this might would would exactly fit this "note first" style of entry. For instance, some people would want subsewuent s notes altered nly up until the end of the measure. Some would want only the very note affected. But in order for what is being discussed here to work, it would really require more - perhaps even every note all the way the end of the piece should be shifted. But that would be disastrous if you started working on the rhythms somewhere other than at the beginning - work you did in the middle would be messed up by changes made at the beginning.

The more I think about it, the more I see a measure-based insert mode being an easy thing but the "note first" method you describe being an impossibility to get right. There's simply no way MuseScore could guess how many subsequent notes you want altered each time you chnge a note duration. But if it stopped at the end of the measure, it really wouldn't work for what you are describing unless you only worked exactly one measure at a time, getting each measure right before entering the next.

In reply to by Marc Sabatella

Hello, here is a proposal:

* A stave would comprise two classes of stave fragments, "measured" and "non measured". The traditional MuseScore would be just one single "measured" fragment. On the contrary, a short educational piece without measure could be one single "non measured" fragment. In any case, both types of fragment would be allowed to appear in a piece. For reworking a part of a piece, it should be possible to change a selection from class "measured" to "non measured" and then back to "measured".

* Changing the stave fragment class:
- The user should be able to select a part of the stave and turn it to "non measured". This operation would remove the notion of measure from the chosen fragment and thus erase the mesure bars.
- The user should be able to select a part of a "non measured" fragment and turn it to a "measured" fragment. This operation would add measures to that fragment. Ideally, a preview should be provided in order to highlight where the measure bars will be inserted by the operation.

* Editing:
- In "measured" fragments, change of note duration would work as it currently works in MuseScore (when one note is modified, the time position of the other notes is not changed, as a side effect the next note may be deleted or a rest may be added, the total time does not change)
- In "non measured" fragments, change of a note duration would happen without affecting neighboring notes (the total time of the "non measured" fragment would thus change). It would also be possible to insert (or delete) notes, which would increase (or decrease) the duration of the "non measured" fragment.

What do you think?

In reply to by OCLC

Igor Engraver allows you to work that way. One can input only quarter notes and then select some of those notes with the usual word processor commands Shift+Left/Right and Ctrl+Shift+Left/Right and after that press the desired note value key. However, the user must take care of bars getting over-full or not full enough. It is also often necessary to cut and paste using Ctrl+X and Ctrl+V and delete superfluous bars.

In reply to by OCLC

I'm late to this post, but wanted to respond. I'm a Jazz Trumpet Player who enjoys music for fun. I doubt I'll ever write a real score (for a performance), but it's nice to know that MuseScore supports this. I'm not a music major and I have limited time that I can devote to music because of my job (software developer).

Instead, I've gotten tired of writing things in pencil and paper on blank staff paper and I want to use MuseScore to help me transcribe a solo, or something else. When I'm doing this, I'm using MuseScore like others have discussed; namely 3djake, OCLC, haugeto, and SouLcRusaDer_kA .

When transcribing a melody, I almost always simply write the notes down. Trying to figure out the rhythm and the notes and getting the notes in a measure (for me) is too much. Perhaps others can do this in one fell swoop. I would like to first enter the notes, and then change them apply the rhythm next. Let's face it, if I'm trying to save time and practice for a performance, I don't really care about a polished score, I'm just trying to get notes and I can (in my mind) know what the rhythm is. This is how I do it, and I'm not saying it's "right or wrong" just to share my perspective. I will use MuseScore to do this because it's better and more helpful than writing things with pencil and paper!

I would speculate that the reason the majority of users do not use MuseScore this way is because MuseScore doesn't support it, not because people don't want it. But ask Marc said (in a post) some tasks are easier in temporal mode, and others are easier in graphical mode. My gut feeling is graphical mode would appeal to the people who just want to write a single staff and melody more for personal use.

I've done many hours/weeks/months of video editing with a product named Sony Vegas which is a semi-pro to professional video editing package. It has the concept of "Ripple" editing mode. This mode lets you insert and easily decide what to do with the rest of the video. The link explains it http://www.guidingtech.com/54497/ripple-video-editing-in-sony-vegas/. It's the first link I found that looked OK, so forgive me if there are better ones. I won't repeat how it could work because others have already described the approach. I primarily wanted to let Music folks know that a similar problem occurs with Video Editing and the solutions used in Video Editing might be applicable to a musical score.

While I don't know MuseScore's code base, I've done some Qt programming and in a few years might understand MuseScore's design well enough to try and tackle this, or more likely realize why this has never been implemented. :-)

It's a pleasure to be part of the forum and learn from others perspectives and comments.
As always, thanks for the wonderful work everyone does to support this.
And Marc's book is still (in 2017) very relevant and helpful for anyone who really wants to learn MuseScore.

In reply to by PatS2265

Something that might be helpful in overcoming the limitations of MuseScore is the ability to look at scores stacked (one on top of the screen, one on bottom). You can either open 2 different scores or the same score in 2 different spots for converting your notes to rhythms. You can look at the notes in the top score while changing the notes to possible rhythms in the other. I prefer what you are alluding to, but this seems to be the best solution for the time being.

In reply to by mike320

This could work and might fit the work flow which is to focus on pitch first and then ONLY on rhythm, and then create a combined score with both. I had not thought of this before your post, and this is a great way to continue using MuseScore the way it is currently designed. Mike thanks for the suggestion.

In reply to by PatS2265

FWIW, I have no doubt it is possible to create such an edit mode. It would be some work, but probably not more than one might guess - that is, nothing about MuseScore internals would be throwing up any major roadblocks I can think of.

But I also don't think it is fair/accurate to say people who just want a single melody line would prefer graphical mode in general. The majority of what I do is lead sheets, and having used both types of programs, I am 100% convinced the way MuseScore works is better overall. The one situation where I can see the value of a purely graphical mode would be for doing transcriptions where indeed sometimes it makes sense to get the pitches before the rhythms, rather than getting simultaneously as is the vase in practically every other musical situation. There are a few more isolated examples. And for the benefit of those cases I can see the value of such a mode. But don't discount the value of the existing model for *most* cases where you want a single melody line.

In reply to by Marc Sabatella

an idea:
Maybe, only for this kind of work, a helper-window can be open.
Pre-work is prepared in this section (in graphical edit mode), and then it can be pasted to the selected staff.
The number of measures of this part, may be fixed in advance. (8 or 16 enough, i think)
I suppose this kind of add-ons will not affect MS's internal work system.

yeah these automatic adjustments are really annoying and stupid
i abandoned Sibelius6 due to this problem
and i m now leaving MuseScore for the same reason
but i would like to see the development team add this OPTION in future
(yeah ! option, let the user choose to enable these automatic adjustments)

v1.3 user

In reply to by SouLcRusaDer_kA

Not sure what you mean about "automatic adjustments" - the whole point is that Sibelius and MuseScore do *not* change the time position of other notes automatically. So it seems you are requesting that MuseScore *should* automatically move notes. That is, every time you change the duration of a note, you want MuseScore to automatically change the time position of some unspecified number of subsequent notes - moving the subsequent notes later in time every time you lengthen a note, or moving them earlier every time you shorten a note. And yes, some day, an option to do that sort of automatic adjustment might be nice.

I realize that for people who come in expecting this sort of automatic adjustment, the way Sibelius and MuseScore work may seem surprising. But it's not stupid - it's actually quite logical, natural, and efficient - *once you get accustomed to it and change your expectations accordingly*. You might try actually giving it some time rather than giving up.

Speaking personally, coming from Finale (which does perform these sort of automatic adjustments - changing time position of notes later in a measure every time I change the length of a note earlier), it took about two or three of constant use to adjust my way of thinking to the MuseScore method. Once that happened, I found it very difficult to go back to Finale - so I didn't :-)

In reply to by Jojo-Schmitz

:-) Weeks.

Because it's relevant - both to this discussion and another current one regarding the nature of open source development - and maybe moderately interesting:

I had actually toyed around with MuseScore for several months since a student first turned me on to it, but, like many people accustomed to Finale, I found the basic note entry & editing paradigm confusing, and I just could not really get into it. But I recognized it was just like Sibelius, and I knew many people found Sibelius to be easier to use than Finale. So I realized it was just a matter of experience & expectations. I'd recommend it with little hesitation to others who didn't already have notation software, but for months I didn't use it myself.

Then, just as 1.0 was getting ready to release, an oppotunity came up for me in which I needed to create a composition for an eight-piece ensemble (mixed classical & jazz) for a concert a few weeks later, and the timing seemed perfect to try this in MuseScore. The idea of an open source alternative to Finale seemed so promising, and I *wanted* to be able to support it, get involved, and use it for myself. So I decided I'd force myself to use MuseScore for this project, both to help test the 1.0 prerelease and to see if I could make the adjustment myself.

For two or three weeks, I lived and breathed MuseScore. It was a gradual process of adjustment, but by the end of that time, I felt like I "got" it. Not just note entry and editing, but pretty much everything. And now the Finale method of note editing feels foreign and confusing, making it quite hard for me to go back and edit older pieces.

Meanwhile, I also identified what for me were the biggest problem areas that were *not* simply a matter of expectations, and I got involved with addressing them. At first, just contributing some templates and customizations to make writing jazz charts a little easier. Then eventually some actual code, implementing a new chord symbol parsing and rendering system for 2.0.

Bottom line: I am now quite convinced from actual experience that both methods work well and are perfectly natural and efficient - *if* your brain wraps itself around how things work. When I was attuned to Finale, it seemed natural, and MuseScore difficult. Now my brain is more attuned to MuseScore, so it seems natural, and Finale seems difficult. Objectively, there is really little difference - it's just a question of aligning your expectations with how the program works.

And I would definitely say the program is too good to abandon without really giving it a fair shot. So when I see someone saying MuseScore is automatically adjusting things, that is a dead giveaway that they have not really begun to make the adjustment - they aren't grasping the basic use model, in which the *time position* of a note is considered just as important as its pitch. MuseScore won't automatically change time positions of notes without being asked any more than it will automatically change pitches. Once you *get* that, things become very natural.

In reply to by Marc Sabatella

OK i tested Notion4 for about 2 weeks

i tried almost all commercial scorewriter in this list
http://en.wikipedia.org/wiki/Comparison_of_scorewriters
and found that it is the right one for me

i have to say Notion is not perfect at all
its a great pain if you dont have midi device
nonetheless, i would say the following quote from kvr forum is true:
"Sibelius and Finale are designed to write scores whereas Notion is designed to write music in score format."
try Notion if you re seeking an alternative of Sibelius/Finale

and IMO Capella is the next choice
they are both easy to change note-value later
(they wont remove 'extra' notes, or add notes/rests when you insert/change notes)

I understand you like the 'automatic adjustment' function
but for me, never the way to go
when i composing, arranging
i make many note-value adjustments in whole process
and 'automatic adjustment' just cause me pains

In reply to by Magnus Johansson

Hi Magnus
I had tried Igor(i saw yr comments above)
Its not bad, but .. it looks a bit old

im not sure about the release date of 1.7
since i cant find it on official website
another site says its 2002
And wiki says its now dead -_-
However the price is $295
But....
Notion4 $99
Capella $250

so..i think it pretty easy to choose

In reply to by SouLcRusaDer_kA

Thanks for your reply, SouLcRusaDer_kA.

kA: "it looks a bit old"

So do Stradivarius violins.

kA: "im not sure about the release date of 1.7 since i cant find it on official website another site says its 2002"

It's from December 2002. Noteheads "isn't dead, it just smells so". (Robert Broberg; http://www.youtube.com/watch?v=7BNMQ94be2c)

kA: "so..i think it pretty easy to choose"

The price is not written in stone. Contact Noteheads' company director Christer Sturmark (christer [at] sturmark.se) or the technical director Cons T Åhs (info [at] noteheads.com) and start negotiating.

In reply to by Magnus Johansson

A program who's last release is 11 years old is as dead as it can be. Computer programs are not violins, the latter get better with age, the former just fall behind.
I wonder whether it runs on the 64bit versions Windows 7 or 8. Their website only mention Windows up to XP (once you found that, as their main page shows basically nothing and doesn't even link to anything useful)

In reply to by Jojo-Schmitz

Ha, ha, ha! It's quite funny to see how angry you still are, Jojo, and you continue to get most things wrong. I did not say computer programs are violins -- which by the way not always become better with age -- but I wanted to bring attention to the fact that something old isn't automatically bad. Noteheads' new main page was set up by Cons T Åhs after some brouhaha regarding the earlier main page featuring images of Björn Ulvaeus, Per Gessle and Christer Sturmark. But you are right that it doesn't link to e.g. the download page, that's why I provided the link to the download page in a comment above.

In reply to by Jojo-Schmitz

Jojo: "I'm not angry at all, why do you think I am?"

Because of your often poor logic.

Jojo: "But why don't you just answer my question whether Igor runs on 64bit Windows 7 and 8?"

Before you ask for my further answers you should answer my earlier questions to you. It is no good discussion if I am the only one answering questions. If you can't or don't want to, you can perhaps download the demo version of Igor Engraver and test yourself, or write to Cons or Christer and ask.

In reply to by Magnus Johansson

relax guys just a easy discussion haha
Sorry Magnus if i didnt make it clear
i guess..
u are saying: old things are not always mean bad/negative, right ?

what i really mean is
i dont think Igor is bad in term of score-writing function
but as a customer, i have to consider a few aspects of the software
(in my place, even US$99 is not cheap)
its future, supported input/output formats, vst capacitability .etc
after considering these things
i dont think Igor worth buying

Notion's price is a great bonus
but for me, the main reason is its functions, design of interface, mixer .etc
'Sound on Sound' did a fair review, u can check it out

In reply to by SouLcRusaDer_kA

kA: "relax guys just a easy discussion haha"

It's cool, kA; I'm relaxed in an energetic way.

kA: "i dont think Igor is bad in term of score-writing function"

I actually think there is no other score writer that even comes close to Igor in that respect.

kA: "its future, supported input/output formats, vst capacitability etc; after considering these things i dont think Igor worth buying"

I understand; these are all important things to consider for many notators, and since Noteheads has been such a terrible company the last 11 years one may really wonder if there will be a version 1.8 of Igor Engraver (Cons made some efforts on a beta version the past spring) with many of the much needed bug fixes, translations and support for e.g. MusicXML export (Igor still does the MusicXML import better than any score writer I have tested). I have evaluated Notion quite accurately since version 1.0 but wasn't impressed by the user interface back then and no time later though the playback is really nice.

In reply to by SouLcRusaDer_kA

Just to clarify, again, MuseScore does *not* perform automatic adjustments in any musical sense. If you put a note on beat 4, it remains right there in beat 4 until you explicitly move it - shortening a note earlier in the measure won't automatically adjust the time position of the note on beat 4. It is programs like Notion that perform automatic adjustments in a musical sense - taking a note you originally entered on beat 4 and automatically moving it earlier if you shorten the duration of the preceeding note.

Thinking musically as MuseScore requires is different than thinking graphically as you apparently prefer. And MuseScore won't be efficient until you wrap your brain around what is actually happening. But certainly, the Notion method - automatically adjusting the time position of subsequent notes to accomodate changes in duration - works well too. Again, as someone with many years of experience in both styles, I can absolutely assure you that neither is more efficient overall - they just have different strengths and weaknesses. But you have to wrap your brain around how a program works in order to be efficient with it.

In reply to by Magnus Johansson

I am not speaking in general - just about this very specific issue. Either a note is a specific sound that occurs at a specific time position, or it is a specific shape that appears at a specific place on the paper relative to other shapes. The Sibelius/MuseScore method always preserves the sound & time position of a note and does what it is necessary to the notation to preserve this. The other method preserves the shape and relative placement of notes and does what is necessary to the sound and time position to preserve this.

Call it what you want, but that's the distinction: one preserves sound and time position, the other preserves shape and relative placement.

In reply to by SouLcRusaDer_kA

It's kind of hard to put into words, but here is an attempt:

First, terminology: I'll call the Sibelius/MuseScore method the "temporal" method, since it is based on preserving note start and stop times where possible, and calling this "musical" seems to ruffle feathers. I'll call the other method the "graphical" method, since it is based on preserving the graphical appearance of notes while allowing their time positions to change - working much like pencil and paper in this respect.

The temporal method (Sibelius/MuseScore) excels when you have a large number of small changes to make to music that has already been entered. That's because a great many changes can be made in a single keystroke - like changing the duration of a single note without affecting the time position of other notes. Or in the special case of lengthening the first note of a pair, the fact that the time is "stolen" from the second note is very often exactly what you want (eg, it takes only a single keystroke to change two eighths into dotted eighth sixteenth). In the case of the other method, any change to a note's duration requires you to explicitly change something else in response, assuming you don't actually want an underfull or overfull measure. In the majority of these simple cases, the temporal method ends up being fewer keystrokes, because the graphical method requires each action to be accompanied by a corresponding reaction in order to keep the measure the right length.

It's the somewhat more complex edits where this balance may change such that the approaches are more equal or where the graphical approach may win. But larger changes are less common than smaller ones. And even when making large scale changes to a melody where you change a lot about it (including pitches) but maybe keep a few passages intact here and there, the fact that you don't need to delete the old content first but can simply start overwriting with new content allows you to start entering the new stuff on top of the old then simply cursor over the stuff you want to keep. Thus, even these large scale changes to a melody can sometimes be simple rin the temporal method.

Where the graphical method definitely wins is two main cases I can think of: fixing certain types of note entry errors, and deciding to rewrite a melody where you keep all the same pitches but make drastic changes to their durations. I guess the latter is what you are focusing on here. You've written a melody as four quarters but you decide you want to rewrite it as half, two eighths, quarter, while keeping the same pitches. This can indeed be done in fewer keystrokes in the graphical method. I guess I don't find this as common as the smaller edits where the temporal approach wins, but since this particular case is a bigger win for the graphical approach, it pretty much evens out.

The certain types of errors that are easier to fix in the graphical method are ones where, say, you simply forgot to enter a given note or rest, or your finger slipped and you entered it twice, or you entered a single note with the wrong duration. Any of these errors result in all notes afterwards being entered at the wrong time position. So in those case, the automatic adjustment of time positions performed by programs using the graphical method can be good. You accidentally entered notes at the wrong time position, and the program might be able to fix that mistake for you automatically by moving some number of subsequent notes earlier or later in time. Of course, that automatic adjustment has to guess how many of those subsequent notes to move - everything to the end of the measure, everything subsequently entered during the last note entry session, everything to the end of the piece, etc. In my experience, whatever guess it makes is likely to be wrong often enough that it isn't really a win - you're going to have to manually shift things around anyhow. But no doubt, there are times when it does happen to work out in your favor. Again, I see it as a wash overall.

So bottom line, I see both methods as more or less equally efficient. But this is *only* true once you adjust your way of thinking to accommodate the program you are using. If you think one way but use a program that expects you to think the other way, it's not going to be efficient at all - you'll constantly do things the wrong way or in the wrong order for the program you are using.

It seems clear from your comments that your brain is successfully wrapped around the graphical approach. Because your brain "thinks" this way, you tend to perform editing operations in a way that works well with this approach, and sure enough, it does work well. So naturally, you find that the programs that use the graphical approach feel more "natural" right now.

For whatever reason, it seems you haven't yet really wrapped your brain around the "temporal" approach. Because you haven't wrapped your brain around this approach, you are doubtless not performing your editing operations in a way that works well with this approach, and thus unsurprisingly, you keep being surprised/frustrated by the results. I remember that feeling very well, as I felt it for the first few weeks I used MuseScore after many years with Finale. It was stubbornness that got me past this. I knew that a lot of others really liked Sibelius and that it has the reputation of being easier to use than Finale. So if others could "get" this method of note entry, I knew I could too. And when it finally clicked, it clicked big time. I almost immediately found it very to go back to Finale. Of course, I know all it would take me is some time with Finale and I'd get used to it again, but it was shocking to me how complete the mental shift became.

Now, from everything I can tell, Notion seems like a fine program. Some of the appeal it has for me is that it seems to take MusicXML seriously, that it has a good reputation for quality of playback, and it also has an iPad version. I have the iPad version but I almost never use it - not just of the graphical/temporal thing but because it feels too foreign to me in other respects as well. I'm sure with time I could get it, but I just don't have enough incentive to worry about it right now. If you feel it's worth the money, then of course you should go for it. But it does seem a shame to give up on MuseScore just on account of this difference between graphical and temporal editing methods, because I know it is quite *possible* to adjust to either.

In reply to by jim.weisgram

What I really want is what Guitar Pro does. When you insert a note into a measure, it only affects the current measure, even if that means extending the measure so that the time signature and notes don't equate correctly. It's up to the user to make sure everything adds up once they're done altering the measure. I get that a lot of people wouldn't like that workflow, but it perfectly fits how I like to work. Then again I use these programs more as a compositional aid than to build proper notation.

Is there anybody working on this feature? Why has it not been implemented a long time ago?
The question is not which is the better way to work - note entry based on the rhythm (and changing ptich later) or note entry based on the melody (and changing rhythm later) or doing both at the same time. Anybody should have the freedom to choose the method that fits his needs best.
The problem is, that musescore does not provide this freedom. And in my opinion this is one of the biggest lacks of musescore. It "forces" its users to use a method to enter notes that the developers think it is the best. But the "best" method for one user might not suit another.

Don't get me wrong, I think musescore is great and I like it, however, this should not keep people from improving things.

My suggestion was to simply add a new kind of measure (I would call it an "open measure") that has no time specification and can take any number of notes. Adding or removing notes to/from"open measures" would simply extend/shrink the measure and changing note durations would move all the subsequent notes of the "open measure".
Other than that the behaviour would be the same as for a normal measure.
Of course you should be able to convert any section of an "open" measure into "normal" measures and any "normal" measure into an "open" measure.

With this concept you could have both entry modes in one score and stuff like changeing time signature from one measure to the other would be no problem.

Thinking abut this stuff I can imagine that implementing it would be as simple as sub-classing the measure-object, allowing it a "undefined" time signature and giving it a "slightly" different behaviour in calculating note values and rendering of the subsequent notes.

WDYT?

In reply to by Botobi

I have a (possibly stupid) question about this project, which I obviously am in favor of.

If Botobi works on this for version 2.1, what is the possibility it will ever get implemented in a version 2.x (sounds like backward compatibility will have to be compromised). If I'm wrong about backward compatibility how will it transport to 3.0 which is apparently getting a different foundation for the scores. I realize there is still a lot of change going on in 3.0 development, so there will no doubt have to be some tweaking later on even if it is written specifically for 3.0. I would be content to wait for 3.0 for this feature rather than have Botobi write it for 2.x, then get frustrated because it crashes 3.0 and gets dropped. I'm not sure of Botobi's plan, but it sounds like your writing it for 2.x.

In reply to by mike320

I think there has been enough support for *something* along these line that I for one would support seeing it added. I would suggest, however, it would probably be better handled a little differently. Having different kinds of measures means pretty deep changes to the structure of the code and would necessitate an incompatible file format change as well. I think it would make more sense to think of this a separate mode of working. As in, a new note input mode in which entering a note increased measure length simultaneously (assuming enough people find that better than pushing notes to the next measure - which I'm sure others would prefer), and deleting one had the opposite effect, and the change duration commands also worked this way. That way measures can be what they always have been, so there is less change to the code or to the file format or to the way a user needs to think about his score.

Such a mode would not actually be especially *hard* to implement, and as I said, could be done without file format changes. But I think if it were to happen, it would almost certainly be for 3.0 because we all want 3.0 to come sooner rather than later and having another relatively big interim feature release like 2.1 would just push 3.0 later and later.

In reply to by Marc Sabatella

@Marc, sound like you and Botobi are talking about a similar implementation, growing and shrinking the measure while moving notes within the measure in this input mode. I think this would be the best way to implement it, rather than moving notes between measures later in the score. There would need to be an easy way to split this measure into smaller measures, perhaps something as simple as defining a short cut for the split measure command in the edit menu. I would suggest | as the shortcut.

In reply to by mike320

Similar use model yes, but internally different - my method doesn't require subclassing Measure at all. I mention this because I'd hate to see him start implementing something that wouldn't be as likely to be merged in the end.

Either way, I think before any coding begins, there should be a really clear consensus on exactly what the use model should be, worth starting a new thread. Only once there is widespread buy-in as to how the feature should *look* should anyone start to think about how to actually implement it. Maybe we're close to that point already, but then, we haven't heard from those who really do want every note to the end of the score moved.

In reply to by Isaac Weiss

Yes, I forgot to mention that. So if we added a similar variation on the change duration commands, we would have the required functionality. Still, I suspect most people would find it more convenient to have this more of a different mode of note input where you could just use the normal commands but they'd act differently. Now that we have multiple input modes, this wouldn't feel like so much of an inconsistency, which might have been a more valid objection before 2.1.

In reply to by Marc Sabatella

I would prefer having different "kinds" of measures over having to switch input mode.
This way you could (but you wouldn't have to) use both simultaneously:
- Passages that are determined rhythmically go to "fixed" or normal measures
- Rhythmically undetermined ones go to "open" measures

Once you have the fixed measures for a repeated theme you could copy them where ever they belong but still have open measures in between them.

In this case the only difference between "fixed" and "open" measures would be the input mode that is "linked" to them. To make the difference between "fixed" and "open" measures clear to the user you could e.g. use a different color for the notes or the background of the staff or whatever.

When adding or appending measures the user just needs to choose between "fixed" or "open".

The advantage would be that you can mix rhythmically determined passages with undetermined ones, you could still change time signature of any (fixed) measure wherever you want and the behaviour of shifting notes would be clear: deleting/inserting notes or changing ther values would always only affect the measure you are working on (adding notes or increasing their value would shift subsequent notes to the right and extend the open measures (no overflow to the next fixed measure), deleting or decreasing values would shift the subsequent notes to the left an shrink the open measure (no overflow from the next fixed measure).

In reply to by Botobi

So to me, it does not look like any other deep change to the code structure is required:

Already today you can bring any normal measure to take virtually any number of notes by changing its time signature to something like 9192/4. However, there is a bug in this area: musescore expects one measure to fit on one staff line and is not able to spread huge measures like these over several lines.
Once this bug is fixed, you could consider "very large" normal measures to be "open" measures.

The behaviour required for shifting notes in "open measures" already seems to be implemented as Posted by Isaac Weiss on May 26, 2017 - 4:02pm.

So the whole thing comes down to giving different measures different note input behaviour by default.

To be honest, I do not really care about HOW this behaviour would be implemented but I do really care THAT it is implemented at all.
Subclassing the measure object was my first idea without knowing anything about the internals of musescore.
But getting to know, that this would even impact the file format gives me the impression that object encapsulation in musescore is not driven as far as I would have expected.

In reply to by Botobi

Again, implementation-wise, what you propose is a *much* larger change, requiring code all throughout MuseScore to be aware of this new measure type. And yes, if you're talking about two different types of measures, then that requires changes to the file format to represent these two types of measures. that has nothing to do with the object hierarchy within MuseScore. It is a simple matter of us needing to know upon reading a file which measures are which. There would need to be a new tag to identify the new measure type, and older versions of MuseScore would not understand that tag. Not a huge deal in that such a change would almost certainly not come until 3.0, but still, the point is, the type of implementation you suggest is a much larger project than merely implementing a new input mode or some new editing commands.

Also, it is not a "bug" that a measure cannot be split across lines, it is by design. This too would require a large change in implementation to make it happen otherwise, but that might not be a bad idea, because even if we simply let MuseScore split measures automatically, we'd need a way for it to keep updating the split as you edited, which basically amounts to the same thing. Either way it would be a bit messy.

Making a separate inpuy mode, on the other hand, is almost trivial to implement in comparison, with basically no changes to the code required other than the new functions that would implement the mode, and no changes to the file format.

And nothing about the implementation I'm suggesting would prevent you from having a mixture of normal and "free" measures in the same score - you'd just want to use the appropriate editing mode for the appropriate measures. And in fact, it would also be trivially easy to allow the measure itself to determine which mode is the default - any measure for which actual duration = nominal duration could default to regular mode, any other could default to the new mode. If enough people thought this was desirable.

In reply to by Marc Sabatella

Hey Marc, that's just perfect! I r8 you 8/8 m8 and I can agree to a 100% to your proposal!
In fact, allowing to apply different (default) input modes to different measures would, give the user the impression to have different meaure types without having to add a new type implementation-wise.
And beyond, the behaviour of "normal" (fixed) measures would be kept as it always has been, avoiding to compromise users who don't want to use the "new input mode of undefined measures" with "unexpected behaviour".
However, I think there should be a way to "mark" measures with different input modes differently (e.g. using a different colour) to make it obvious to the user, which measures are using which input mode.

If I'm right, https://musescore.org/en/node/99036 is requesting a similar thing.
So probably you could add your proposal to this feature request (and give it a higher priority ;-) ).

Cheers,
Tob

In reply to by Botobi

The nightly builds for 3.0 already include a feature where measures that that have an actual duration different from nominal get marked. And in my proposal, this is the same thing that would optionally control the default input mode (although I still personally think it makes more sense to make that decision be explicit - I don't like the idea of the same exact command doing two different things depending on which measure I start in).

In reply to by Marc Sabatella

I agree, that the decision, which input mode to use, does not necessarily need to be done implicitly. If I could set different input modes for different measures explicitly, that would be pefectly fine (er.., how would you do that without adding any kind of mark to the measure practically making it a "different type"?).
To me it is much more important to have the possibility of using both imput modes on different measures simultaneusly to "mark" fixed measures (where notes should always stay at their position within the measure - the current musescore mode) and "open" measures (where subsequent notes would be shifted and the measure itself was "stretched" if a note was added or removed or a note value was changed, without affecting subseqent fixed measures.
IMHO it is part of the concept of different input modes, that the same commands behave differently depending on the input mode, which in fact can be confusing somtimes. However, this is usually not a problem as long as it is obvious to the user which input mode he is currently in.

I can see a value in this way of entering music, that is not immediately obvious. When entering a voice line with the same melody (i.e. a verse), it is often the case that the scansion of the words is different, and the durations need to be adjusted, when one is cutting and pasting.
Just my 2 cents worth,
D.

In reply to by abrogard

It might be implemented at some time in the future since the request shows up so often. I haven't heard of it being planned for version , but it's still a ways out.

Since you're using a Midi keyboard you should be using a real-time input mode that pays attention to how long you hold the keys in a chord. It still only inputs into one voice on one staff at a time, but there is no need to press the duration for each note.

See https://musescore.org/en/handbook/note-input-modes#realtime-auto for more info.

In reply to by mike320

Actually I didn't/don't know about the real-time input modes, apparently fairly newly added. I'm just about to learn about them.

I 'withdrew' from my post because I realised it wasn't hurting me much at all to input the duration before playing a chord on the midi.

A short while ago it did - because I didn't use the numerical keypad with my right hand to input durations.
That's how new I am.

But now that I do things go pretty quickly and smoothly. My post was thoughtlessly harking back to my bad old days (a week ago).

And now I learn there's realtime midi input with durations ( I think?) ! This amazing prog just gets better and better.....

:)

In reply to by abrogard

FWIW, the idea of entering notes first then durations later isn't bad, it's just more complicated because every times you change a duration we'd have to figure out how many subsequent notes you want moved, figure out how to handle cases where the change causes a note to cross a barline, etc. So it's something best dealt with in a separate "scratch pad" mode, I think, and I do hope to see that some day.

Meanwhile, between real-time entry, plus the abiltiy to enter durations using keybaord shortcuts or also assigning keys on your MIDI keyboard (see Edit / Preferences / I/O), it's really quite simple to enter durations already, assuming you know them :-). It's really the case where you haven't even figured out the durations yet where the scratch pad would be most beneficial.

In reply to by Marc Sabatella

That's interesting. From that I deduce that you're actually one of the programmers? Well if so you have my congratulations and admiration. I can't begin to imagine how on earth you've done it. Far beyond me.

For myself I was thinking originally (without actually doing any 'thinking') of merely inputting notes in sequence without durations simply because that's what my MIDI will do already, isn't it, if I don't change durations before each input.

And my reaction was that this would be okay if I could then go through the list from start to finish and input the durations.

And my assumption was that then the bar counter would run down the chain putting in the bars where appropriate.

And that'd be fairly easy (for the programmers who can do all this incredible stuff, that is).

But that's not so I think you're saying? I've misunderstood it all?

In reply to by abrogard

@abrogard... You wrote:
I was thinking... of merely inputting notes in sequence without durations simply because that's what my MIDI will do already, isn't it, if I don't change durations before each input.

If you can 'quantize' a song in your mind, you can enter all notes with equal durations.
Sometimes I find a technique like this (simple example) useful to enter notes prior to finalizing rhythms:
Equal_durations.mscz

Regards.

In reply to by abrogard

First - yes, I am one of the programmers (one of many!), and thanks for the kind words :-)

The "scratch pad" idea that is discussed periodically could indeed be more or less like you describe. You'd input notes and fiddle with durations with no barlines at first, then when done, the music would automatically be barred as appropriate. I think there is some widespread agreement on the general concept and that it would be useful and not unduly difficult. But it's still a significant amount of work, and so far no one has stepped forward to actually try designing and implementing it.

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