Grace notes don't playback properly
the acciaccatura plays 1/8 of the note previous to it. ex: note previous is a quarter note--plays like a 32nd note. note previous is a double-whole note--plays like a quarter note
the appoggiatura plays equivalent to an eighth note except for when the previous note is less than or equal to an eighth note
the rest do not play, even when the previous note is a longa.
i always input them in by either clicking and dragging them from the palette or selecting the note(s) first and double-click the grace note i want. i have seen this problem on all pieces using them on musescore.com and on all downloaded pieces from that web site, and i have heard a complaint from another person who has posted many pieces on musescore.com
Comments
Update: Sorry for not giving my operating system and version of MuseScore. I will post this on the forum as well.
Operating system Windows 7
Version of Musescore1.0
Some do, others don't.
I don't know much, but to me, it seems currently:
One acciaccatura: Plays on 1.1 like a 16th (?) grace note, whilst on 2.0, it plays similarly, but on the beat of the main note. However, the latter plays a little later (dislodged?), instead of playing on the beat.
Two acciaccatura: Plays on 1.1 like 16th (?) grace notes, whilst they play correctly on 2.0.
16th grace notes: They don't play on 1.1, but on 2.0, they play like acciaccaturas (all crushed).
Is there currently a problem with implementing a fix? Grace note playback might not be an issue compared to articulations and ornaments?
Using MuseScore 1.1 and 2.0 Nightly Build (4793) - Mac 10.6.8.
Although there should be better defaults, see this: #13811: Select playback method of Grace Notes, Arpeggio & Glissando and Articulations & Ornaments
I too have this problem my OS is Windows 7 Vista 64 bit and the version of Musescore is 1.3
And none of the grace notes play except for the eighth note. But when I listen to other peoples scores any other grace note plays. I dont know whats going on, so...yea.
please don't assign to yourself,unless you plan to provide a fix ;-)
I'd like to look at the playback of grace notes.
From the implementation perspective there are two kinds, chord->graceNotesBefore() and chord->graceNotesAfter().
From looking at the code, it appears the "before" grace-notes case notes have their duration calculated very strange. And the "after" grace-notes are not rendered at all in playback.
Can someone explain how this is supposed to work from a user perspective. How is the user supposed to indicate the starting time (tick) and duration of each note? Also what should the duration (and starting tick) of the main note be in the case of grace notes?
My opinion (which might be wrong, correct me if so) is that if there is a before note (or several) they total duration should be as if they were normal notes. E.g., if there are 3 before-16th grace notes, they should sound exactly like 3 16th notes, but the main note should start 3/16th after its normal starting tick and the main note duration should be shortened by the number of ticks corresponding to 3 16th notes. Likewise if there are 3 16th after grace notes, the main note duration should be shortened by that number of ticks. And the 3 16th notes should just play as if the normal notes were right justified before the following note.
I'm attaching a graphic of what I mean.
My suggestion is that the two measures should be rendered identically in the playback.
As far as I know, it might depend upon the style, the time and the performer.
But, at least for Baroque and early 'Classical' music, the face value of the grace note is largely irrelevant; an appoggiatura, i.e. a single, non-slashed before-grace, lasts indicatively half the value of the main note if the main note is not dotted, 2/3 of it if it is dotted, regardless of the notated value of the appoggiatura.
If there are several before-graces, they usually are not appoggiaturas, but stand for an ornament (either an ornament for which a specific sign would exist but for whatever reason has not been used, or even an ornament for which no specific sign exists) and then a rule of thumb is to play them with the speed of the notes making an ornament up (which is very vague, but generally quicker than appoggiaturas and unmeasured).
After-graces also are on the same level of ornaments and are 'quick' ad unmeasured; the standard case is a trill resolution, in which the final graces are usually played at approx. the same speed as trill repetitions; I believe that, from the perspective of a mechanical, automated playback, this could possibly be a reasonable rule of thumb for all after-graces.
To my ear, it sounds like when the before grace notes are played back, both the grace note AND the main note are placed together on the first tick, then the main note is played again after the grace notes.
Attached is the image of the mid-out-in file.
You can see that indeed the first beat of the measure contains both the C and the D,
and after the D-C-D grace note is played, the C is played again.
Furthermore, the D is sustained until the end of the measure.
I hope no one argues that this is correct behavior.
Hi Miwarre, I would still suggest that my proposal is far better the what is currently implemented which seems to be quite the mess.
@jim.newton.562 regarding #8: I cannot replicate your description in 2.0.2.
As I can test, in 2.0.2:
1) Single appoggiaturas are played back more or less as I described in #7; your example of an appoggiatura before a semibreve is played back as a minima long appoggiatura note followed by a minima long main note.
2) Multiple appoggiaturas have the total appoggiatura duration split among the individual appoggiaturas; in your example, a triplet of semiminimæ of appoggiaturas followed by a minima of main note. This is possibly not the better way to render it, but it is not really "a mess".
3) After-grace playback is simply not implemented. Implementing it would be surely a good thing.
If current master works otherwise (I didn't try it), it is a regression.
I think you are mistaken that the grace note and main note are played together. Or, rather, if you are seeing some special case where it is happening that way, it is a bug specific to that particular score, so posting that score might help us understand what went wrong in your particular example if you are in fact ever hearing two notes at once. I have never heard that in my testing.
The current algorithm for the grace notes should actually be quite good & correct in the usual cases. The grace note occurs on the beat, and is always very short regardless of notated value or tempo, and the main note starts immediately afterwards. This is a very standard interpretation of grace notes. Some sources say they should be struck together for piano specifically (and then the grace note immediately released), but this obviously nonsensical for most other instruments that cannot play two notes at once. Some sources say a grace note should be played *before* the beat, but that's a minority opinion according to my research. The norm is the grace note is very short and on the beat, the main note immeidately afterwards, and that is exactly what we do.
This is, of course, about acciaccaturas; appoggiaturas are always half or two-third the length of the main note.
Definitely you should *never* assume a sxiteenth note grace note actually takes the normal value of a sixteenth note. No source I have ever heard of would claim such a thing. Acciaccaturas are to be played extremely short regardless of notated value; the only question is whether it occurs before the beat, on the beat but before the main note, or on the beat and simultaneous with the main note. The second of these options is the most common interpretation for most instruments, and it is what MuseScore implements. Note lengths for appoggiaturas are also independent of notated length but depend instead on the main note, again this is pretty much universally agreed upon.
Hi Marc, it seems like if what you saying is correct, then there needs to be some way for the user to specify the time-slot the grace note receives. I have heard the same piece performed by different respected musicians where the grace notes were interpreted very different. In some cases (minority) in baroque music the grace note gets even more time than the main note. This is for special effect I think.
As far as the user interface is concerned, how might the user like to enter a time-slot for a grace note? (maybe as a percentage???) Normally time-slot is determined by the note type (half, quarter, 16th etc), but as you suggested a 16th grace and a 32nd grace have the same time-slot.
From the programmatic perspective, if there were a property on the chord->graceNotes() object which specified the total number of ticks, that could then be divided (almost) evenly among the notes. Unfortunately, I don't think there is a user interface for editing the chord->graceNotes() object.
Saying there "needs to be" a way to control this is a stretch. Certainly there is no more need than, for example, to be able to specify how fast a trill is played, or how short a staccato is, or how loud an accent is, etc. In fact, I'd suggest those are *much* more important to most people and more worth spending effort thinking about.
The long grace notes you are referring to are almost certainly appoggiaturas, not acciaccaturas, and as we have said, these are already played long. The interpretation of these is pretty much completely standard: 1/2 the main note except for dotted notes in compoiund meter where they get 2/3. The only respect in which MuseScore might get these wrong is dotted notes in *simple* meter, where apparently 2/3 might not be correct - 1/3 might be more appropriate accordng to some.
At this point I don't see any reason to think there is a bug - playback seems correct for all cases as far as I can tell. But of course, more customization is always nice, to allow for fine tuning or for non-0standard results like having appoggiaturas play as acciaccaturas, etc. As such, I would saay this is a duplicate of the feature request #13811: Select playback method of Grace Notes, Arpeggio & Glissando and Articulations & Ornaments.
Did I read this right Miwarrre after playback of grace notes is not implemented? I just went pro and have started up loading my teaching materials and I hit a basic notation problem on first day, that doesn't bode well.
Is there a way round this?
It is true there is no playback currently for grace notes after. That's just a playback issue, though, not a "basic notation" one - the notation itself works just fine. And MuseScore is first and foremost a notation program.
If for some reason you really need to hear those play back, you can add them instead as grace notes before the next note, or add notes in another voice t achieve the desired effect. You can make those notes invisible.
Thanks Marc, that is basically what I had tried to do, but the only way to get correct values is to forget the ornament and type the played values with double dotted smaller notes and or ties, but they then look a mess as I loose the correct layout aimed at teaching the student. The requirement is for singers to follow defined exercises on the live on-line player and see scales and training exercises with mordants and portamento routines as well as more complex ornaments. These are a basic requirement for classical singers.
So far I have been very happy with MuseScore and I think the team is doing a fantastic job, but I would disagree with you that you can use grace notes from the following note and add it to the previous note as the values and timings would be totally wrong. This is especially true when the beat must be on the base note not the ornament it's self! If you play around like that you are not helping a student learning to correctly sight read music.
The designers have deemed it important enough to add extremely easy ornament writing tools for this excellent notation software, but to include this function without correct playback appears to me to be fault in the current program. Sorry don't mean to sound ungrateful or awkward!
I was working on gracenotes after some time ago
But I abandoned it because there were some things in the data structures I didn't understand. It's not very difficult basically, there the change will cause several differences in a few things in the regression tests...not surprisingly.
Should I take another look into this?
If so, look at #13811: Select playback method of Grace Notes, Arpeggio & Glissando and Articulations & Ornaments ...
Well, sure, for *some* cases using a grace note on the following note would be wrong. In other cases, it is right. Depends on the case. But you can *always* use a hiddden voice, or an invisible staff, if having proper playback is important to you. A hidden staff doesn't affect layout at all.
Yes, you're right. It was a red herring. The problem was caused by something unrelated and uninteresting in my development code.
confirmed, it's not playing correctly, I found on my musescore.
The one I did is a Double appoggiatura, according to Wikipedia: https://en.wikipedia.org/wiki/Appoggiatura
it should be playing like:
but it's not.
There is no one single way to play this. Wikipedia's version is but I've option. This issue is about something different, though, and it has already been closed as a duplicate of another issue.
Sorry couldn't find the other one, just one more post here.
With Current Appoggiatura Implements, the score sounds so far away from it suppose to be, ref attached 'Spring' (L v Beethoven). With Wikipedia's version it sounds closer, and with most player playing version, it sounds best. compare both version for measures no: 38-40; 53; 55-60.
I know it's hard for programmers rewrite musescore code do the "most player playing version".
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.