Accidental lasts whole bar?

• May 7, 2011 - 20:29

So relieved i have found musescore!!

Trying out some easy piano pieces first....but am having trouble with accidentals. It's easy enough to insert them, but the next time note of same pitch as accidental is written in same bar, it has a natural next to it?
How can i make the accidental last whole bar?

Also, can't seem to drag and drop the articulation sign for tenuto?


Comments

Currently, the accidental only lasts for the current note - you just have to re-enter it if you want to enter another note of the same pitch. MuseScore is smart enough to not actually draw the accidental the next time.

As for moving articulations and other similar elements, double click to enter Edit Mode, then use the arrow keys.

In reply to by Marc Sabatella

thanks
i have a triplet of 3 C's. i want the first one to be sharp ( this requires an accidental ) and the rest to be left alone so it is assumed the accidental lasts the whole bar. ie. nothing is added to these subsequent C's.
but what happens is i put a sharp onto first C and the next automatically has a natural sign, i cannot get it to have nothing.

also with articulations, i am still clicking onto the sign from the palette and dragging it. and it does move into position with a little box and plus sign, but as soon as i release mouse, it disappears!
how do i get the sign into position in the first place as i assume your instructions are about moving it once it's in position on the score?

thanks for your help!

In reply to by Marc Sabatella

Hi Marc, and thanks for your great and hard work, as I really appreciate how Musescore (despite free) is keeping up with Sibelius and Finale!

I am a contemporary classical composer and would find useful
I was wondering whether there is any chance to make Musescore automatically write accidentals to all notes of the same pitches even if they are within the same bar and the first already has that accidental.
I try to explain it better by an example. Let's say we want to enter four times a E flat within the same bar. The result on the score would be:
Eb E E E
Those three Es after the E flat would still be flat according to theory (and of course Musescore has to follow theory by default...) But is there a way - or a plugin - to let Musescore write Eb Eb Eb Eb, instead?

Thanks in advance for your kind help

In reply to by wavygirl

I've just encountered the same issue with accidentals. In key of G, I changed F# to F natural using the keyboard accidentals command, and the program automatically inserted a # at the F note immediately following, inside the same measure.

I understand that the program is defaulting back to the key signature with each new note, but it runs counter to standard music notation, and will get your score bounced back by publishing editors. It also requires more data entry work from the user. If this is going to remain the default, it would be helpful to provide a toggle switch allowing the user to specify that an inserted accidental controls through a measure unless the user sets it otherwise.

In reply to by rasmith

FWIW, I would never want it to be the case that changing one note from F# to F natural affected any other notes *already entered* - that would be entirely non-intuitive to me. If I had wanted to change all the F#, I'd have *selected* all the F#'s. And what if I didn't *want* all the F#'s changed? However, I would sometimes like to have it so that changing one F# to F would "stick" for the rest of the measure when entering *new* notes, so that pressing the "F" key would enter an F natural and then I would have to explicitly change it back to F# if I wanted.

In reply to by rasmith

it's an assumption that the user is most likely to want accidentals for one note only rather than the remainder of the measure. You can select and delete the automatic natural, sharp or flat. A new one will pop in ahead of the next note of the same pitch, if there are any more in the bar. That's a pain if you have a long run of them. So, making it a selectable user preference would be a good thing.

-- J.S.

In reply to by chen lung

are trained to treat any accidental as holding for that note through the measure, unless another accidental intervenes, and that the note reverts back to key signature at the beginning of the next measure. This has been standard notation practice going back at least to Bach & Handel. I don't know if other musical genre's work otherwise. If so, it would be helpful to those of us who produce orchestral and choral scores to make this a user-defined default setting, to avoid a lot of extra editing.

In reply to by rasmith

I don't think any genres exist that have different rules for *reading* music,. That wouldn't be a reason to have multiple options. The reason to have multiple options would be in that some situations, you would be more likely to have an F# and an F in the same measure - and in that case, the current behavior is slightly less work - and in other situations, it would be the other way around. Either way, you can get the results you want; it's just a question of one method requiring more keystrokes in one situation and the other method requiring more keystrokes in the other situation.

In reply to by chen lung

I also think most accidentals on entered notes should continue on new notes until the end of the measure or cancelled, perhaps by using shift while clicking as another suggested. A preference selection should be available for those of the other opinion. At least, it is easy to modify the note immediately after entering it by using the appropriate up or down arrow key. Editing should remain as it is, although I would like an easier way to select numerous notes or lyrics than by control-clicking each.

This topic reappears periodically; there are several threads in the forums and at least one issue in the issue tracker about it.

In all occasions, most of the complexities were cleared by distinguishing between "entering new notes" and "editing already entered notes" and a general consensus was reached along this guide lines:

A) While entering new notes, the current MuseScore behaviour is sub-optimal: it should default to a more immediate adherence to current "spelling conventions"; in particular, entering a note which already occurs in the same measure with an accidental should by default produce a note of the same pitch (i.e. sharpened or flattened or 'naturalized'; the accident is not written as implicit), mostly like MuseScore currently does for accidentals in the key signature.

B) While editing existing notes, the current MuseScore behaviour should be kept: only the note(s) on which the user acts should be changed, without carrying the change on other following notes of the same pitch.

As this is a rather recurring topic, probably is something to push somewhat higher on the priority scale... In the meantime, I have bumped the issue quoted above.

M.

I think MuseScore is a fantastic project! I find it extremely capable and useful at ironing out problems in understanding scores and pieces of music. I've followed the project from around version 0.9, and stuck with it through some extremely quirky and buggy behaviour. I would like to recommend this software to others as a replacement for other music notation software but I'm still of the opinion, that while massive progress has been made, there are significant issues which prevent it being used more widely, especially for those who are learning music. The treatment of accidentals is a particular instance of some of the behaviour which concerns me and for those who are learning music, it would cause more confusion than is necessary

The behaviour of the software in accidental application is against standard music notation. When an accidental is applied to a note in a bar, it lasts for the whole bar (until cancelled) and applies to every instance of that note in the bar (regardless of octave), again until cancelled. If you want to do something different from that, then it is up to the composer to properly specify the accidentals in the score. As has been pointed out this behaviour would lead to the score being rejected by publishers, it would also lead to a score being rejected by those assessing compositions - so by definition it cannot be used by anyone learning music. I would strongly recommend that this issue is a significant one and that it should be addressed as soon as possible. Departure from standard music notation will seriously limit the software's user base and surely we would like that user base to be as wide as possible? If I'm not wrong, I think the behaviour has been in line with standard music notation in the past?

I look forward to seeing this problem corrected. Thanks for all the hard work and please keep it up!!!

In reply to by rlnicol

I think it is vastly overstating the case to say the current behavior would lead to scores being rejected. The current system does not prevent you from creating correct score. It doesn't even make it harder on average, at least once you get used to it. It's still the case that about half the time, an accidental would be followed by another similarly altered net, and about half the time, it wouldn't. I absolutely agree the option should exist to have accidentals "stick" in note entry, but it is also absolutely not a big deal either way. It's about the same number of key presses to create music either way on average. Either system would lead to fewer key presses in some cases, more in others, but neither system would ever make it impossible to get what you want. It is incorrect and unfair to say MuseScore cannot be used by people learning music. They simply have to be aware of how the program works. And the behavior will be plain the moment they enter a second note of an altered pitch.

It's also fallacy to suggest that just because the rules for reading music go one way, that this should automatically apply to writing it. If you think about it, it isn't how instruments are actually played. When you see a sharp sign in front of an F, you have to reach for a different key on your instrument to play it. If you then see another F in the same measure, you can't simply play an F and expect the instrument to sharp it for you - the instrument doesn't follow rules of notation, either. You the instrumentalist have to manually make the adjustment and play the F sharp. So it really it isn't that different to ask the composer to do the same.

In reply to by Marc Sabatella

Dear Marc, Thanks for your reply. Other contries might well be a bit more relaxed but in the UK, music schools and the ABRSM are extremely strict in the application of standard music notation. I understand that France is even more strict. My argument is that scores written by students must be readily understandable by all trained musicians who are presented with the score. Part of the rules are to avoid excessive clutter in the score.

I fully agree with you in that it is still possible to create a correct score, ie. a score which will play correctly, and in fact is understandable. And that the "work done" in using the software is not much different either way. But say, for example, I'm constructing a piece in a minor key. I will by definition always have the same notes marked by accidentals in every measure they appear - but they are not represented in the key signature. Therefore, to get a correct playing score, I need an accidental on every instance of the note - every note, every octave. So, what I have at the moment is an extremely cluttered score which I am finding difficult to check against the original notation. Yes I can get the score correct, yes I can get it to play correctly and yes I, personally, will continue working with this software in order to suit my ends. However (having discussed this with a UK music teacher) I can confirm to you that if I was to submit the score notated the way it is at the moment as part of an exam piece, I would have substantial marks deducted (equivalent to droping two grades!) because I demonstrated a fundamental mis-understanding of standard music notation. So that would suggest that my argument is not fallacious, and that this behaviour of the software will limit the user base of it.

Personally - I don't care. I'm not taking the exams. For me this is a hobby, but I can see that this project will be limited to that type of environment unless it is accepted that standard music notation is there for a reason and really ought to be followed - or at least it should be possible to switch between "explicit" and "implicit" notation modes. Implicit being "standard".

From the tone of your reply, I fear a nerve has been touched. May I please say (again) that, I think this is a great project and has the possibility of opening up music composition to lots of people that would normally be prohibited by the very high (and over inflated) cost of music notation software which works properly. That is the reason I am keen to see this project improve and continue and be able to access as large a user base as possible. Please accept these comments as they are intented. Constructive and helpful criticism meant for the overall improvement and benefit of the project in continuing credit to the very obviously competent and very hard work which has been spent on this project!

In reply to by rlnicol

I think you have misunderstood. Of course it is important to get the notation correct. You seemed to have been to been saying it is not possible, but is possible, and indeed, quit easy once you get accustomed to how it works, and that is my point. It is simply wrong to say you cannot produce correct scores in MuseScore because of this. You definitely can. You just have to "play" MuseScore like an instrument, as I described - explicitly putting in F sharps where you want them, just as you would do when playing an instrument. As as I said, in some cases that might turn into more keypresses, but in other cases, it will be fewer. It will average out the same.

You still seem to believe you cannot get your score to look correct, and therefore it would be looked down upon. I assure you this is NOT the case. You still seem to be misunderstanding something about how MuseScore works if you think there is any difference whatsoever in he results produced or in the effort required to achieve those results on average. Perhaps if you posted a sample of a passage you are having trouble getting to look correct, we could help clear up that misunderstanding. Once more, it is absolutely possible to get correct results, both for playback and for appearance. So you must be doing something wrong. If you post an example, I'd be happy to show you how to do it correctly.

Btw, minor key scores are not produced using accidentals In major keys. If you use the correct minor key signature, then the only accidentals you would need are for the occasional raised seventh and sixth scale degree. And that is a case where the current behavior is likely to result in fewer, not more, keystrokes, since these accidentals are likely to not last the entire bar but instead be cancelled when the line changes direction.

As for touching a nerve, my concern is only that newcomers not be given the wrong impression. Your post made it sound like there was an actual problem that would prevent MuseScore from working for them, when really, it's just a "six of one, half dozen of the other" personal preference in terms of what specific keys you need to press to get the desired results.

In reply to by Marc Sabatella

Hi Marc, Hopefully attached is an example. Bar 1 is an example of the problem I'm having. First a natural note, then it's sharpened. The following 2 notes should also be sharp according to the notation - with the sharp cancelled at the bar transition. Bar 2 shows what I have to put in to MusScore to get the correct "playing". The additional two sharps are not necessary (in notation), but MuseScore is playing correctly in Bar 2 what is intended in the notation of bar 1. I hope this clearly illustrates the problem.

It's more than likely that I'm misunderstanding a great many things - so your help is very much appreciated.

Attachment Size
Test2.mscz 1.51 KB

In reply to by rlnicol

Your example shows a simple misunderstanding on your part. An accidental only applies to the exact note where you placed it, not any other note including any octaves up/down. The third and fourth note in your first bar (octave F's) are not the same note as the second (F) where you placed your accidental and therefore you would have to place an accidental in front of each one if needed.

In reply to by schepers

Yes, indeed. Accidentals only apply to notes *on the same staff line/space" within the measure. the second measure is absolutely correct notation - in any genre or country - if you want all three notes to be F#. the first measure would correctly be read as an F# followed by two F naturals.

Before seeing the example, I was prepared to guess the problem would be a different but equally simple thing: using the wrong type of accidental. Accidentls on notes would normally be placed by simply hitting the arrow key (up or down) after entering the note. These accidentals would behave according to standard notation rules. However, if you place an accidental by dragging one from the palette, that's a different / special kind of accidental - one that you want to show up even though it's not necessary. Usually called "courtesy" accidentals. these are typically used to remind people people that an accidental in the previous bar have expired. Not strictly necessary, but if you examine any professionally typeset m music, you'll see they tend to be very generous with these, often putting courtesy accidentals to remind you the note has reverted to its original state according tot he key signature even several measures after they were last altered.

In reply to by rlnicol

music notation. If you put an accidental sharp on an F, for instance, and then cancel it with a natural on the next F in the measure, that's standard notation as I understand it, and will be read as an F sharp and an F. If you write an accidental sharp on an F and don't cancel it for the next one, that's also standard notation, and will be read as two F sharps.

The program produces standard notation in both cases, just with different meanings. The question is whether you want it to assume that you always want your accidentals cancelled automatically, or if you'd rather cancel or not by hand.

As it stands, if you don't want the accidentals cancelled immediately, in our F sharp example, you'd have to go down the rest of the measure swatting those pesky naturals like flies, one by one by hand. But a lot of times, you do want to write an accidental for one note only. So, I'd like to be able to turn auto-cancelling of accidentals on or off.

Oh, and I agree with Marc's previous observation that this should be for entry of new notes. In editing existing notation, it ought not to eff with F's that are already there.... ;-)

-- J.S.

Could I suggest something:

As you click for a note in Note Entry, you can hold down shift to create a natural (or the opposite if this proposed method is implemented - the original note according to the key signature)?

I am a little-bit confused by this thread.

When you enter notes, as far as I can tell, MuseScore remembers absolute note-values ("what the sequence of sounds should be"), then it creates on-the-fly a sheet music representation of that underlying note-sequence. It does not, as a human player would do, "take the written page and determine what the corresponding sequence of sounds should be." So, to the software, the horse drives the cart, whereas, when humans play a printed score, the cart drives the horse. C'est la vie.

Therefore, if you have entered a sequence of notes (say, F) in a single measure, and you then sharpen one of those notes, you will see "F#" followed by a natural-sign for the next "F," because the sequence of note-values as entered contains only one sharpened "F" followed by one or more notes that are not. The notation reflects that.

Furthermore, I am not able to reproduce the claim that "MuseScore doesn't know about measure lines." To test this, I entered a string of eight consecutive F's in two measures (key of C), then sharpened the first and the last one in the first measure. The second F in the first measure was preceded by a natural-sign. The fourth F is sharped. The first F in the second measure was not preceded by a natural. This is correct, and it seems to affirm the notion that MuseScore does, indeed recognize measure lines. (But of course, maybe I just didn't stumble upon some existing bug.)

Therefore, my suggestion you need to listen to the playback of the piece and verify that the underlying note values ... as captured by the software as absolute note-values ... represent the actual sequence of sounds that you want the ensemble of human players to produce as they read the same music when printed. If you intended to sharpen a series of notes, select all of the notes and sharpen them all. The resulting notation will be, AFAIK, as you expected.

In reply to by mrobinson

MuseScore is first and foremost a notation processing program. Its data structure "remembers" everything it needs to display and print the score. It's all there, not figured out on the fly.

Playback is sort of a secondary afterthought. That's what it produces on the fly. There are some things, repeats and voltas for instance, for which it has to store some add-on data for playback purposes, because that's easier than making it interpret the written score like a live musician would.

-- J.S.

In reply to by John Sprung

Agreed.

And my interpretation of the phrase, "everything it needs to display and print the score" is ... "a time-delimited stream of absolute numerical 'note values,' accompanied by also-time-delimited metadata."

And here, I realize, is where the software designers faced a forced-decision point: either "the way it sounds, as it was entered note-by-note" must take precedence, determining the emitted notation, or "the way it is written" must govern the way that it sounds. And my intuition (admittedly, as a professional software designer, not a professional composer) is both that the first approach seems to have been the one that was selected, and that the latter approach might have wound up with a much less agreeable set of technical compromises. (If the software had been built that way, you might well not like it nearly as much...)

Furthermore, if we pressed upon the designers, "let us have our cake and eat it too... give us an option..." well, we have just demanded a thing known as "a Highly Pervasive Change, this being a rude code-name for "a change that 'ripples' all over the source code and causes software engineers to say, in truest Charlie Brown fashion, "AAUUGGHH!!!" My instinct is that the only acceptable reply to that would be, "No." (But I am not a designer on this project.)

To my way of thinking, "once you understand how MuseScore's designers chose to approach the problem, whether you think it "rightly" or "wrongly," you can accomplish your objective of writing or transcribing great music. You can do it quickly and reliably.

Every software program requires that of you, more or less. To a certain extent, in order to obtain value from any software program, you have to understand where the designers were coming from, and to adapt your own workflows and perspectives to it. (Or, as the case may be, choose to use something else, whose idiosyncrasies and quirks are more in lunar-alignment to yours.) That's just the hard realities of a digital computing machine.

In reply to by mrobinson

Well, there has been a fair amount of confusion in this thread where people have misunderstood each other, and in at least one case, someone was simply mistaken about how the rules of notation actually work. But I think I can summarize the actual issue here (and it has *nothing* to do with playback):

If you are entering music, say, in the key of C, and you enter an F sharp at the beginning of a measure (by typing an F followed by the up arrow), then later in the same measure you type F again, many people (myself included) would expect that typing an F would automatically create an F sharp in this situation - that is, the accidental you entered previously would carry through while entering notes in that same measure. Instead, typing an F enters an F natura (with an explicit natural sign)l, and you'll have to explicitly hit the up arrow to make it an F sharp (thus removing the natural sign).

So it's not actually a question of MuseScore doing anything "wrong", but more one of requiring an extra keystroke that you would often feel you shouldn't need. Furthermore, it feels counterintuitive, becasue when writing music by hand, you wouldn't actually need to write a sharp sign to get that second F to be considered an F sharp You'd need to write in an explicit natural sign to get an F natural, so it feels like that is what shoukd take the extea keystroke in MuseScore too.

It's that disconnect between how you would write music by hand versus how you need to do it in MuseScore that leads some to describe the problem in terms of MuseScore not properly following the rules of notation, but that's not really accurate.

In reply to by Marc Sabatella

To play just a little devil's advocate, I should point out that the current system does have certain advantages for certain types of situations if you have a certain type of mindset. When composing, for instance, as opposed to transcribing existing music, one might be more likely to actually think of each of those F#'s as being altered, although probably not if you're entering a whole bunch in a row. In addition, there is a certain consistency in the fact that hitting "F" enters the same note all the time, instead of being dependent on whether or not you happened to have entered an F# earlier in the measure (perhaps so much earlier you've forgotten it was there!). This feels more consistent with the experience of playing an instrument, where the F# key on your saxophone (for example) doesn't magically play itself just because you played an F# earlier in the measure. And BTW, if you do want to enter a long string of F#'s, one way would be to enter them all as F's, then select them all and hit the up arrow just once. So it need not be *that* much extra work. And in music where you really wanted only the one F# (eg, it was just a passing tone, not an altered tone to fit a non-diatonic harmony), it's actually fewer keystrokes the current way.

But still, all things considered, even though I've more or less come to peace with the current scheme, I am still pretty sure I'd prefer the current accidental state in the measure to be remembered. It just feels right. Even after six months of regular usage, this remains one of the few things that still kind of catches me by surprise every so often.

I've read the whole thread (leaving my head spinning), and I can enter "usual" accidentals with no problem. But now I have three E# accidentals in one bar: I can only make an E# by entering an E natural, then dropping a # accidental onto it. But for the following E# notes, there should be unadorned E notes, and this I cannot achieve. Arrowing up and down still goes from E natural (shown with a natural sign) to F, and if I drop a sharp on the note, it again appears as an accidental sign, which I don't want. And there doesn't seem to be a "no accidental" element to drop on the note. And there isn't a context menu on every note that lists its properties, which (ISTM) would really be the answer to Almost Everything.

Perhaps I am missing something in the explanation of how to get the right thing to show?

It would also surely be a good idea to have a customisable 'accidental range'. I guess that the current system gives five sharps on up, and five flats on down; to change this to include E# by default would add extra burden on people using only "moderate" key signatures. But if you were typesetting Scriabin, who likes having E-double-sharps, it would be handy to have about 12 sharps and no flats in the range.

In reply to by Marc Sabatella

We certainly need to improve the way MuseScore handles enharmonic sharps and flats.

Working in certain keys is intensely frustrating when the relative keys contain notes such as E#, Cb etc.

Maybe something could be worked out along the lines of - if there is are more than 3 flats in the key signature MuseScore will automatically enter Cb and not B natural.

I'm going to start a new thread on this I think.

After you have written F and added accidental sharp on it then add two more F.
Then click natural sign in front of the second F and delete it.
Repeat same for the last natural sign.

Musescore plays all these three notes as F# and what you see is what you want as a trained musician: #F F F

Same in a videoclip
http://youtu.be/W5f_i1es7KA

BR, tahaavi #

In reply to by tahaavi

This works, but it's a kind of indirect way of doing it. If you want to enter three F sharp, it's simpler to just enter them directly. An F sharp is entered by typing "F" then pressing the up arrow to raise the pitch. Do this three times and you will have three F sharps, and MuseScore knows to only display the sharp sign on the first if they are all in the same measure.

Your method works (I just tried it), but I discovered that the same result can be achieved in a different way:

1. enter all of the notes as naturals (no accidents at all)
2. sharpen or flatten the first note of the group; a natural automagically appears to the left of the second note
3. select the natural (the accident, not the note head) and delete it; a further natural appears to the left of the third note
4. select the new natural (again, the accident, not the note head) and delete it; a further natural appears to the left of the fourth note
5. go on until you reach the last note in the group - that's it!

Ah! Until now, I never incurred in the situation you described. So many thank for having given me the opportunity to discover a feature of MuseScore I wasn't aware of. Let MuseScore rule!

I have to state that the feature described in this page is not a relevant one. Managing accidentals in MuseScore is easy and straightforward, no need for any update. I feel like saying that, should one make any mistake in entering accidentals, he couldn't blame the software at all. Using a software does not make studying the theory an optional -- would an engineer use a CAD to design a car engine without a sound knowledge of physics and other theoric fundamentals? Come on! Music is not engineering, but the example is ok => poor theory? poor results.

There's a little bit easier way, provided that you're starting fresh with nothing else happening at the same time on the same staff:

Enter the repeated notes as naturals, then exit note entry mode. Click on the first one to begin selection, then shift-click on the last one to select them all. Now all you have to do is up arrow to sharp the whole bunch, or likewise down arrow to flat them all.

The reason you have to start fresh is that if there are chords happening at the same time, the selection grabs everything, not just the one voice or line you want. At least it's a little easier than going down the line swatting out naturals. ;-)

-- J.S.

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