Question for people who use microtonal accidentals
There is still no support for correct playback of microtonal accidentals in the development builds, although actually, there are some hooks in place that should make this possible in the not too distant future (maybe 2.1?)
Meanwhile, though, I would love it if people who use microtonal accidentals could give their opinions on the following:
http://musescore.org/en/node/22205#comment-103636
I probably should have posted this here rather than to the issue tracker in the first place. So maybe read the comment there, but post your responses here? Actually, I'll just restate the issue here, and perhaps having this second explanation will make it clearer.
It has to do with the following:
In 1.3, the third note would play as G# - the microtonal accidental on the second note has no effect on the rest of the measure. But the second note plays as G natural, and had the second note actually had a natural instead of a microtonal accidental, we of course would have expected the third note to play as G natural as well. Really, I expect the second note to play as whatever that accidental means, and the third to play the same. But for now, given that microtonal accidentals are not supported for playback, I'd expect the second and third notes to both play as naturals.
This is easy to "fix" (so the third note plays the same as the second), but in so doing, I'd break scores that rely on the current behavior. Consider, you might have written the above expecting a human musician to play the third note the same as the second and accepting for now that the computer playback will be wrong. But that means your score actually contains G# as the third note. That means when your score is read, it will either render as G# (meaning there would now be an explicit sharp sign there), or else I could maybe try to remove the sharp to make it render as it did in 1.3 (meaning it will now play back differently). Either way, I break something for existing scores.
I'm not sure it's worth breaking existing scores for no good reason. If I'm going to break existing scores, I'd offer something to make it worth the pain of people needing to manually fix them: actually playing back the microtonal accidentals. So my inclination is not to change the behavior for now and wait until we do implement microtonal accidental playback. On the other hand, the longer we leave things as they are, the more people will create scores that break later.
Not being a user of microtonal accidentals myself, it's hard for me to guess what people might actually want or expect here. Comments?
| Attachment | Size |
|---|---|
| microtonal.png | 3.02 KB |
Comments
I don't really understand your concerns here, and I've read the GIT code comments as well. Unless the rules governing microtonal accidentals are different, it is MS that is "breaking" the score because MS playback is wrong. Any human player would follow the rules of accidentals, so should MS, and the third note should be played at the same pitch as the second. I can't see _anything_ that would break by implementing this and it would correct the wrong playback. Am I missing something?
In reply to I don't really understand by schepers
OK, I've whipped up some measures to see what microtonals do:
Each measure is 4 F's added without keysig, then having the accidentals applied. In the first measure, the sharp on the first F will generate the natural on the second F, the flat on the third F will generate the natural on the fourth F. This is as it should be.
The second measure was approached the same way. But the microtonal on the third F didn't force the generation of the natural on the fourth F. Therefore I would expect the fourth F to be played as the third one. Correcting that playback mistake would not break anything.
Are you concerned that with your fix, MS will auto-generate a natural like I simulated in the third measure, fourth note? Indeed that would break things. The fix would have to work like the second measure.
In reply to OK, I've whipped up some by schepers
Sorry, our posts crossed. Responding to your example above, my concern has nothing to do with what happens while you enter notes into a new score in 2.0. It's true my change would alter the sequence of keystrokes you need to create any given rendered result, but people will get over that, and will probably be happier with the new system.
My concern is solely about scores created in 1.3 would now render differently in 2.0 (or whenever the change is made). Because microtonals are treated internally like naturals, your example would actually render example the same. The microtonal accidental on beat 3 of measure 2 would be the same as a natural, so the note on beat 4 would not need a natural. I am not proposing changing that.
But change the first note of the second measure to a half note, so now it's an F# in effect when you get to the fourth beat. If you make that change and do nothing else in 1.3, a natural sign will appear on the fourth beat. Now hit up arrow to raise it to F#. The natural sign goes away. It's now an F#, but with no explicit sharp sign displayed because 1.3 thinks the sharp sign from the beginning of the measure is still in effect. The score will record the last note has a pitch of F#, but with no explicit accidental.
Load that same score into 2.0 with the fix in place, and MsueScore will display a sharp sign on the last note of the second measure, because the sharp from the beginning of the measure is no longer in effect. That's the break I am talking about.
In reply to I don't really understand by schepers
Well, yes, I agree, 1.3 was wrong to do what it does. But if people have been relying on this and creating scores that either render or playback as they expect (depending on which is more important to them), then a change to 'fix" this behavior in general will "break" scores that depend on it.
The example I gave above was meant to illustrate this, but let me be more explicit, then. Go ahead and try to create the above score in 1.3. You'll see that the only way to create it is to enter the third note as G#. That is, type G, which enters a G natural and displays an explicit natural sign, then hit up arrow to raise its pitch to G#, at which point the accidental disappears, because MuseScore thinks the sharp is still in effect. That third note at this point *is* G#. It plays as G# within MuseScore, it exports to MIDI as G#, it exports to MusicXML as G#, and most importantly, it is stored in the MSCZ file as G#.
If I "fix" this for 2.0, then upon reading your 1.3 score, or import the MIDI or MusicXML you exported, it will now suddenly render with an explicit sharp sign on the G - not how it looked in 1.3 at all. Maybe (OK, almost definitely) 1.3 was wrong to render it that way, but I'm guessing people are depending on that behavior, And I'd now be breaking it. Scores that were carefully constructed to render as the author wanted will now render quite differently in this respect - and that difference means they will be played differently (the human player would now play G# for the third note instead of G),
It *might* be possible to work around this by hacking the code to detect this situation and actually convert that third note - stored very explicitly in the MSCZ as G# - into a G natural. This would be a non-trivial hack, though, and it would be the wrong answer if the user actually *wanted* it to be G# (maybe he cared more about playback than appearance; maybe he was planning on using the MIDI or MusicXML).
Also, I am not ruling out the possibility that rules for scope of microtonal accidentals *are* different. Ther convention that says accidentals last the duration of the measure is relatively new - only a couple of centuries old or so - and over the past century, many modern composers have already decided not to use it, instead adopting the convention that accidentals affect only the note they are attached to (which makes more sense for much aotnal music).
What we used to say in 1.3 was, microtonal accidents are decorative only; they don't affect the pitch of subsequent notes. Even if it was not the right answer, it was a good story. What I'd be doing is breaking that story, but still not playing them back correctly either.
In reply to Well, yes, I agree, 1.3 was by Marc Sabatella
Two things come to mind.
1. To software, there can't be two rules governing accidentals. Either they modify everything after the note where they are placed, or they only affect the note. Regardless of the "wild west" attitude some composers have, I agree with the present-day rule. After all, a few centuries of establishment can't be wrong.
2. I can't see any other solution except to fix it so that the remaining notes are modified to be the same pitch following the modified note. That's how it looks visually, is how it would be played, and follows the "rules".
In reply to Two things come to mind. 1. by schepers
1. I agree the present-day rule makes sense for ordinary accidentals and if a composer wishes to adopt a different rule, he can do so manually. But microtonal accidentals don't have centuries of establishment - or, to the extent they do, it's in India or Turkey or other places using a totally different notation system. It's possible that in fact the norm is for microtonal accidentals to not last the duration. I can't find any explicit info on this, which is one reason for wanting feedback.
2. Yes, I agree that #2 is the best "fix". It preserves the *appearance* of scores from 1.3 while changing the actual pitches. So it's still going to break people who were more concerned with playback than appearance, but MuseScore, as we often remind people, is a notation program, not a playback program. I'm a bit concerned with import of MIDI and MusicXML, but mostly, I'm concerned that changing the pitch of the notes on read is actually easier said than done. And I remain concerned about the timing of this - whether it is better to do this now or wait until microtonal accidentals are fully implemented, as opposed to basically being treated as aliases for natural, which is mostly what happens now.
Hi guys,
I join the discussion to expose the way i'm using microtonal. So, first, I want to precise some stuff :
1- lots of traditionnal musics (arabian, turkish, armenian, pygmy, britain...) are microtonal musics, but not microtonal like european could understand. I mean, an half sharp isn't really 50% of a sharp. It mainly depends on the melody and on the original culture where it comes from. Those musics are mainly teach by oral tradition, notation comes really later, and, as you mentionned, european notation aren't sometimes precise enough to transcribe those musics. The awareness about this is quite recent in our civilisation. So, we have to understand we are in the experimental domain !
2-As we are in experimental domain, we have to understand we are occidentals trying to note the most precisely possible with our system, some musics that use other systems, even not using any notation systems. And I think this is the point of view we should keep in mind, otherwise, we would have to change the fundamental approach of musescore. For example, here is an armenian notation system i'm working on : http://silpayamanant.wordpress.com/alt-strings/resources/scores/near-ea… really far from our world :-)
3-In 1932 a big congress took place in cairo (http://en.wikipedia.org/wiki/Cairo_Congress_of_Arab_Music) and some decisions/conventions were decided about music notation. Honestly, every musicians I worked with just said me this is bullshit. The notation decided in this congress can't retranscribe the real music muscians learn from their teachers throught oral tradition.
4- Few years ago (thks to lasconic) i wrote this plugins : http://musescore.org/en/project/autotuneselection still works fine for musescore 1.3. So, I still use microtonals as explain in the example part, entering notes, changing the key signature with microtonal symbols (or just changing some notes in the score), and then modify the note pitch with the plugin. Because some microtonal pitches are some times only 30% even 22% of a semitone, we have to dissociate playback from notation.
5- When I use JACK midi out to render the score throught VSTi, the sound I ear is exactly the sound I see. and pitch/note accidental are saved in the musescore file. So, the real problems come with MIDI / Music XML export as Marc metionned, but it's another subject I guess.
So, in my opinion, and if I take your example with the three G, the third G should play like the second one (with micro tonal pitch). Barlines should also work like we are using them in occidental music. There is no reason to create exceptions to our already existing rules. A good point could be to find a way to note precisely the number of cents for each note/scale. I actually use ossia measure with text notation.
If you can't keep the microtonal symbol AND the sound (remember i use the plugin) I think the third note should be a natural G but it should be precise with the natural symbol. I don't think keeping a G# is a good idea.
And I really think this problem should be treated as soon as possible. Another solution could be to write a plugin that will do the same job as mine no ?
I hope i'm clear enough about my point of view.
In reply to the way I use microtonal by Daeavelwyn
Thanks for the feedback! Would still love to hear from others.
Please excuse my late answer, but I was discovering this thread right now after again searching for solutions for composing microtonal music with Musescore in a comfortable way.
I'm playing lots of oriental music, Persian, Turkish, Arab for example, and each of the three is using a different notation system. They are using different kinds of accidentals with different pitches (actually the same accidental can be stlightly different in pitch depending on the context) and the actuall sound can be different than the notation. This can be in smaller degree like you see an C which can be slightly lower or even sound like B or Bb, but you would still write C because of the position of your finger on the instrument (which is just tuned lower). Certain scales (or Makam/Maqam, Dastgah...) do have certain starting points/tonal centres whch you write or name, but in performance it can be any sound. If you compose using an instrument, it would be nice if the sound of the instrument matches the sound of the notation software. This would make a playback transposition feedback necessary which will change the playback of all notes together but not the notation.
While in Persian music notation the choice of tonal center is more flexibel (you can write from C, D...) in Turkish music notation one certain makam is usually written from a certain tonal center. For example on the instrument Oud you read an A, put your finger on the position of D (in Arabic Oud where notation and sound mostly matches), but you hear an E. This may sound very awkward and in fact it is, but this is the musical practice and even westerners like me can get used to it.
So what seems necessary to me (as a user of oriental microtonal accidentals and not western ones) is this playback transposition feature and a feature where you can enter the pitches of each accidentals and key signature symbols (fine adjustments have to be done to the cetain notes, of course). By the way, as in western music the accidentals count for the following notes of a bar.