Same note in different voices and lengths plays only the length of the shortest note
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
If two notes (first and second voice) share the same pitch and the longer duration is the second voice, the second voice will end when the first voice note ends. See the attached score as an example. This issue was brought forward in this posting: http://musescore.org/en/node/12965
I've personally had this happen but could never find the cause until Joe's sample. This bug affects both branch and trunk.
| Attachment | Size |
|---|---|
| hold.mscz | 1.93 KB |
Comments
I think this is still reproducible - also if you exchange the voices.
Hope the title is better?
Using MuseScore 2.0 Nightly Build (bd8b902) - Mac 10.7.5.
Yes, it's still reproducible.
I'm wondering why Musescore is sending a note off message here - doesn't it use Running Status?
It's not immediately obvious when using the piano instrument that things aren't working because the decay on the piano sound is too fast. When I switched the sound to rock organ or organ, the cutoff on the long notes became more obvious. I should have said that when I made the original report.
There's another issue with that: the velocity (not quite the right rterm here, I know) of the 2 notes don't add up, so in a 2 voice staff at the spot where the voices overlap it sounds softer than in places where it does not.
Two voices playing/singing the same pitch should be louder than just one voice
You cannot play overlapping notes of same pitch on most instruments but you can notate them. MuseScore emits a noteOn/noteOff event for every note which results in the observed behaviour.
It is expected that you set the play property of one of the notes to off.
.
can't MuseScre do this automagically on the shorter one?
Confirmed for me, running 4c859d8 on Ubuntu 13.04.
I think this should definitely be resolved programatically - couldn't we overwrite an end-note event in the synth if the current note's end is longer, or suppress adding the end-note event if the current note's end is shorter? Just getting started contributing to the project, but I feel like this is an important feature.
By the way, the notes don't even have to be at the same time - just overlapping, as in the attached file.
bump, just stumbled across this again today, in MuseScore 2.0
Even on instruments that can't play multiple notes in unison, the longest one should play, and at the velocity of that note (in case they differ).
It gets more difficult, but also more important, when notating more than one instrument in a single staff, like closed score SATB, or flute or violin 1 and 2, there not only both notes should play, but also the velocity should increase. Not sure by how much, maybe 50%? And not sure how to tell the 2 situation apart (single vs. multiple instruments)...
Just came up again in http://musescore.org/en/node/52816
Double post, sorry
Other example: watch and listen this score: Etude 3 standard + TAB.mscz
In particular, the notes of the voice 4 (bass) - quarter note, half note, half dotted note- which are in unison with the voice 2 are systematically cut (they have the value of the note of the Voice 2)
Attached is a trivial example which illustrates the issue. The behaviour is not WYSIWYG because what plays is not what's written. Unfortunately the workaround doesn't help me either because I post-process the MIDI output to split it into practice files with different parts/voices emphasised, so every note is needed. Version 1.3 revision 5702.
I'm not quite understanding. If you are doing post-procesisng of the MIDI, that would seem to imply you are saving the MIDI fil.e and playing it through some other sequencer. If so, isn't it the job of your post-processing, or of the external sequencer you are using, to figure out how to handle to conflicting note on/off events/ MuseScore's playback isn't involved, so a fix involving MuseScore's playback engine would not necessarily help you. MuseScore is, as far as I know, correctly writing two note-on events and two note-off events. If we fixed this by only sending one note-on and one note-off event - which strikes me as the most natural fix - you wouldn't be any better off than if you turned off playback of the shorter note manually. Or were expecting a different solution? I guess if MuseScore sent two note-on events and only one note-off - the later one - that would be another possibility, but your MIDI processing algorithm could do that just as easily, no?
Also, I'm not sure I get the point of your post-processing. What is it doing that you couldn't do just by selecting the notes of each voice one by one and increasing the velocity within MuseScore (eg, using Note Properties in 1.3, or Inspector in 2.0)?
Hello Marc. Apologies - having examined the output of the sample above and played it with Timidity, you're indeed correct that two note-off events are produced corresponding with the timing in the score, so it is a playback issue and the post-processing would be unaffected. It may still be impossible to work out which notes correspond to which voices in certain circumstances, but unless there could be some sort of hinting with meta events, that's not going to change!
I guess the fact that playing the unadulterated MIDI output produces a different result from playing back within MuseScore lends more weight to the argument that there's something wrong with the playback engine though. :-)
For interest, what the post-processing does is speed up the creation of a separate practice file for each choir voice from a score which is SATB, SATB + piano, or fewer parts. The practice files have the relevant part panned to the centre and all the others reduced in volume. It just mimics what I used to do with the mixer, which is a tedious manual operation. The complication of voices (S1, S2, etc) would be even more tedious to do manually as every note would have to be edited. To avoid this, the divisi could be represented on separate staves, but that can double the size of the score; especially frustrating if there are only a few notes where it happens.
You might consider having two separate versions of the score - one for print / display, one for playback. Have the playback version put each part on a separate staff for simplicity.
But even with parts combined on a staff, you don't need to edit velocities manually. Just do as I said - select the contents of a single voice, then change the velocity all at once. Including the mixer adjustments, I can't imagine it taking more than a couple of minutes to generate the customized MIDi tracks for any given score.
Many thanks - I will try that. And thank you to you and the other developers for such an amazing piece of software.
Unfortunately I've found a situation where the MIDI output is affected. In this example, the second bar has both voices at the same pitch, and the second voice's last note (semibreve on C) is omitted from the MIDI output.
I don't understand - the comment in the score mentions 1.3, but 2.0 plays it back just fine as far as I can tell.
Yes, the version is as per the comment. The "2" in the filename does not refer to the version of MuseScore but the version of the file (compared with comment #12).
OK, but my point is, it does not make sense to report problems that are already fixed. As I said, it plays back just fine in 2.0. As for MIDI export, there is no reason to export the exact same note twice.
Ah OK. I shall download 2.0 beta before reporting anything else (though note that there was that little display oddity also mentioned in the comment in the score, which I guess could be quickly confirmed doesn't happen with 2.0).
My main point was that this example affects the MIDI output, unlike the other one. I understand your response, which is fine but only if you're ignoring the contribution that different voices make to the overall volume of the output. However, I have seen this can of worms being discussed elsewhere and here is not the place to complicate matters!
Just for interest, regarding your earlier helpful suggestion of selecting all the notes in a voice and changing their parameters at once, the slightly lazy method of inputting the scores so far has been to only have one voice except where the divisi occur. If my post-processing software finds an entire note which is not overlapped by another, it assumes it belongs to both voices. This practice contradicts my previous paragraph! Best to bite the bullet and have a playback version with one voice per stave as you suggest.
Not 2.0 beta, but 2.0.1
Ah so it is - the Google still brings up the beta as the top result for Musescore 2.0. I didn't look very far as I assumed had it been released it would have updated itself via Ubuntu's package management system, but it hasn't. Packages are available but 2.0 is not in the Software Centre. I'm sure I can find out why with a bit of digging.
I didn't see any display oddity in 2.0. There were definitely quite a lot of fixes betwene 1.3 and 2.0 having to do with handling of conflicts between voices.
As for export to MIDI, this is as good a place as any to at least mention that unfortunately, sending the same note twice and the same to the same MIDI channel does *not* normally / necessarily result in increased volume. Instead, it often leaves to unpleasant "phasing" effects, which is why it's normally desirable to suppress overlapping notes. But indeed, as this issue makes clear, our algoirthms for figuring out what to suppress and when leave something to be desired. This is the one case where I'd say it actually works well; it will be interesting to check the code and see how the check is performed and whether it can be improved.
Odd that Google's showing you that result at the top. Possibly because you've visited that page a few times before? http://dontbubble.us
Yes possibly, though I use the Self-destructing Cookies Firefox plug-in so it's not tracking me by the most obvious methods.
I have used DuckDuckGo a few times but found it a bit US-centric. I should try it again.
Same thing here (2.0 on Windows 7 x64). whole notes held for three of four measures are only played for one measure. Quite disturbing on playback.
I take it back—Google's genuinely getting it wrong.
http://www.google.com/#safe=active&q=musescore+2
https://duckduckgo.com/?q=musescore+2
EDIT: Of course, as of yet neither of them is aware that 2.0.1 has been released…
see also https://musescore.org/en/node/64796, here with the same note in 2 staves of the same instrument, slightly different, but probably related
EDIT : oops, crossed messages, and I withdraw what I said before. This seemed worked due to the resonant character of the banjo...:)
Interestingly the workaround to mark the earlier ending note to not playback doesn't solve the issue in this case, here the 2nd whole note's playback is disabled, as well as the 1st half note, the latter results in 'correct' playback, the former does not.
see also #87586: 1st tied note of voice does not play
Brought up again at https://musescore.org/en/node/93751.
This vicious bug is so pervasive and absolute in its effect that I have had to include its URL, description, and clumsy workaround in rules for continuo realization on MuseScore. https://musescore.com/user/1831606/scores/1745621 . This is out of hand, as it were.
If you don't mind I'm taking this.
I looked at the code and thought about it a bit, I *think* there is a neat solution in linear space and logarithmic time using a Hashmap and interval trees (https://en.wikipedia.org/wiki/Interval_tree).
I'll try to implement it.
I'm confused here; why is a complex data structure and time-careful search needed? There are a maximum of 4 voices in each staff. Also please see my UI suggestion at https://musescore.org/en/node/93751 . Thanks.
This is how I understand it: to fix the problem, when playNote() is called (which adds a NOTEON, NOTEOFF pair on the event map), it is necessary first to see if there is an overlapping note of the same pitch on the event map.
If so,
- If one is entirely contained in the other (hence, they have the same starting time), you simply keep the longest and keep a single NOTEON, NOTEOFF pair.
- If they only partially overlap, you discard the "tail" of the one who starts earlier and generate a NOTEON, NOTEOFF, NOTEON, NOTEOFF sequence.
The most efficient general way to "see if there is an overlapping note" is, I believe, an interval tree, which allows for searching in logarithmic time. Readily available, efficient implementations of it are 10 a penny.
Of course, I'm completely unfamiliar with the code base, so looking at it from a per-voice perspective didn't occur to me, thanks for pointing that out.
Let me mull over it for a while.
While I am hardly advocting we not consider performance at all, the code involved here is not all that time-critical - it's called only when you press the Play button, not on every layout. Actually, not even every time you press Play - just every time you press play after a change to the score. Well, depending on how the fix is implemented I guess it could be called on every edit [ and our posts crossed, I guess this is indeed how you were envisioning it ], and that would be bad if it weren't pretty darned quick. FWIW, note we already use an implementation of interval trees, so if you go that way, be sure to investigate reusing that code rather that writing your own. [ But I think I'd personally rather see an implementation that did the check only as necessary when hitting Play, not on every edit ].
As for the UI suggestion, I am not opposed to it, but I'd say its far more important we get the playback working well automatically than to provide extra tweaks most users will never use. That can come later.
You need a data structure with 256 slots, one for each possible MIDI note, to wit, a count of active playings in each slot; no tree or search is needed. As I said in the UI discussion, the model of "just collapse the notes" is appropriate for keyboard instruments (I'd be grateful for that) but not for stringed instruments or "oboe 1 and 2 on the same staff." But I'd sure be grateful for "just collapse" for a start.
I agree, that was exactly my original thinking as well, as Marc probably remembers - but (if I am understanding correctly) I think it requires iterating over the entire generated event list, post-facto; granted, it's not exponential complexity, but still I was rather wary of the idea.
You know, since it's, I believe, rather trivial, I'll start implementing it and see how bad it is.
Classical and fingerstyle guitarists use shared noteheads in virtually every score, so this would be a much-appreciated fix.
As far as I am concerned, anything that is run once on a full render of the MIDI can afford to be a bit slow (within reason, of course). Anything that is run on every edit, on the other hand, needs to be as fast as possible.
Came up again: https://musescore.com/groups/improving-musescore-com/discuss/3341396
@tobiatesan: Are you still planning on working on this?
Last activity of @tobiatesan is more than 30 weeks ago, so I think it is relativly save to assume that we can unassign this issue...
If, as seems to be the case, there is no interest in fixing this, the need and technique of silencing coincident notes should be documented in the user manual.
It is a bug and needs fixing. Whether to document the workaround for time being in the handbook, I'm not sure, we usually don't. This is not the only bug that has a workaround but isn't yet fixed for 2.1 or in master, and as far as I'm aware workarounds are not documented in the handbook usually
MuseScore's "How to make notes in unison overlapping" (https://musescore.org/en/node/24622) solves the playback problem by using a different notational style. Is this the only way to solve the problem? I would rather see a half note juxtaposed to an eighth note than to have the head of the half note cover the head of the eighth.
I'm not quite sure what you are asking. The article you cite is not about playback but about notation - how to get the note heads to overlap *if that is what you want* (this is common in guitar music, for example). If you don't want overlapping noteheads, then don't do what it says in that article. Either way, the plyback will have the issue described in this thread - the note is cut off according to the shorter duration. The workaround to that has nothing to do with altering the appearance of the score - it is to turn of the Play property of the shorter note using the Inspector. You can use that workaround regardless of which notational style you prefer.
Came up again in https://musescore.org/en/node/185601
Serious? It is playback, and am easy workaround is available, so I'd rather make it minor
It hobbles virtually every user of this program, particularly first-time users, who attempt to render keyboard music or hymnbook-disposition choral music, and the workaround, although simple, is not at all obvious, nor how to find it. It quacks like a bug and walks like a bug, to mix metaphors.
Before hitting the "Reply---musescore is a score tool, not a performance platform!" button, please note that this behavior trips up those trying to use MuseScore-produced MIDI for serious performance tools and MIDI instruments. See my dissertation on it here: https://musescore.com/groups/3642106/discuss/3663846 .
"easy workaround is available". Serious?
For a large part of the instruments, probably minor or normal, but for guitar, which is the most impacted, definitely major. I speak for my parish, no doubt, but it is an evil that affects systematically all the scores.
This is irrevocably related to the writing of the guitar. Should I remind you that this instrument is written on a single staff, and has two voices almost systematically, three voices most often, and four voices, is not uncommon.
And of course, with shared noteheads quasi systematically, on various voices ... all along the score, and all the time ... (look at the scores published for guitar, there is only this : from the most basic pedagogical collections, to the most complex concert pieces)
Would you accept, for example, that on a piece of piano, a bass line in half notes, be systematically cut, chopped, by another voice that would be in sixteenth notes? I do not think so.
Go to musescore.com, type guitar, and you'll see, "hear", what I mean. Not a score escapes to this behavior.
So for the priority, I leave you to your judgment.
Came up again in https://musescore.org/en/node/196296
See also #197641: Staccato dots are being transferred to other staves, thus cutting of long notes in upper staff
.
Came up again in #211351: short note cuts off long note in other voice on same staff and was mentioned in #207346: MIDI export: the first track should not contain note events
Jojo-Schmitz, thanks for noticing my issue describes the same problem, but I see from this discussion that nobody has hit on the solution. I explained the solution in my post, i.e. the way to fix this is to assign separate MIDI channels to separate voices on the same staff. Then the MIDI output is correct, and the problem goes away. This is not just a playback issue; it's a basic problem with .mid file output which I had listed in https://musescore.org/en/node/207346 (thanks also for noting that)
This is a typical rookie MIDI software problem, and there is a widely known industry standard MIDI software solution for the problem. To summarise:
PROBLEM:
MuseScore cuts off duplicated notes in different voices on the same staff. Why? Because all the notes are assigned to the same MIDI channel.
SOLUTION:
Allow users to assign MIDI channels to different voices.
That is the industry-wide standard solution to this problem. All other music notation software supports this solution. They all allow the user to assign MIDI channels to voices regardless of where they appear on any given staff. MuseScore doesn't have this feature, and *the behaviour above is a direct result of lack of this feature*.
NOTE: Implementing this solution can lead to the following situation, that doubled notes from different channels _may_ "stick out" (it depends on the playback device), but that is a very well known issue to anyone who works with MIDI software, which also has a very well-known user workaround: simply change the velocity value of one of the doubled notes to 1. Problem solved. More verbiage does not need to be wasted on this issue. The solution simply needs to be implemented. ( For details about how this issue affects MIDI files and why the industry-standard solution is obviously what should be implemented, see https://musescore.org/en/node/207346
I would prefer we not require users to employ a workaround. If you are OK with a workaround, one already exists - simply silence the shorter overlapping note. I feel we should implement a solution that requires no workaround. Offering the option of separate channels could well be part of that solution, but it shouldn't be all we do. MuseScore isn't only used by MIDI experts - it is mostly used by musicians with little or no MIDI experience.
I encourage discussion on the forum to get input from more end users.
That's jumping to a conclusion within the problem statement. The problem itself does not include your why, and I don't agree with your why in most of my use cases. So let's retry that one, shall we?
Problem:
MuseScore cuts off duplicated overlapping notes in different voices on the same staff (arguably instrument). [end of problem]
Why 1?:
Because MuseScore doesn't correctly track the note overlapping.
Solution 1:
Have MuseScore track the correct nesting of note start/end points so that it can perform playback as if it is one longer note, starting at the earliest start point and ending at the latest endpoint
Why 2?:
Because MuseScore can't handle multiple instruments on the same staff? (which seems to be AaronAndrewHunt's use case, and is sometimes mine as well)
Solution 2:
Allow assigning different instruments (and thus channels) to the different voices within a staff.
So there are two different originating reasons for encountering a single perceived problem. But both root causes require a different solution to me.
"Solution 1:
Have MuseScore track the correct nesting of note start/end points so that it can perform playback as if it is one longer note, starting at the earliest start point and ending at the latest endpoint"
The first person who tried to do it gave up, no surprise there. Fiddling with the MIDI data to try and solve this is an obvious fool's errand if ever there was one, and it goes against all existing examples of solid software dealing with this problem. If you want to try to program that, go ahead and prove me wrong. I'm telling you now that you will be wasting your time.
It's not "fiddling with the MIDI data" in some ex post facto, ad hoc or kludgey way. It's generating it correctly in the first place. How come human keyboard players can render such keyboard scores correctly, on "one channel" instruments such as "acoustic" pianos, yet, you claim, it is a "fool's errand", beyond the state of the art of computer science, to program it?
One midi channel models one keyboard exactly, which is why it cannot be used for multiple orchestral "desks" on one staff. But one keyboard is exactly what it thinks it is.
"It's not "fiddling with the MIDI data" in some ex post facto, ad hoc or kludgey way."
It is exactly that, BSG: kludgy, ad hoc, ex post facto fiddling. It's a foolish strategy that won't work. But since you are a programmer and you are convinced that you're right, then how about stop going on about it and instead implement the function(s) yourself? I'd be happy for you to prove me wrong and make MuseScore the first software on planet earth that solves this problem without separating channels. Until you can write the code that does that, sorry but your words are just a big smokescreen.
There is absolutely no reason it cannot work. The data structures we have in place are more than sufficient to allow an algorithm to detect the overlap and remove the unnecessary MIDI messages. The only question is how to do so most efficiently. As I pointed out before, it does not have to be in real time - playback data is completely generated in place before any of it is actually played. Writing code to make the necessary prepass is not difficult, but it would be nice to not require something like n^2 time.
"There is absolutely no reason it cannot work."
Then please write the code to prove it, preprocessing thread and all, handling every possible situation (of which there will be some you will not have thought of, causing the algorithm to go haywire), not to mention that MIDI file output will be non-standard, but no matter. Please prove me wrong. I'll be glad if you succeed.
Sorry, a midi file that contains the exact events that would be (or were) produced by a compliant midi keyboard under control of a competent human playing that score is not "nonstandard". A midi file in which certain notes don't appear (or are deeply truncated for performance/interpretation reasons) is not "nonstandard", any more than a midi file with performance errors, or no notes played at all. I can (and do) silence colliding notes myself with the inspector (yes, there are some hard cases). Does that make the midi file "nonstandard"? Why would it be "nonstandard" if code did that instead of me?
If I could've spared the time to look at this issue, which to me (personally) is rather minor as I don't use MuseScore for it's MIDI-export capabilities at all and the workaround (silencing a note) is a very trivial workaround (one that your software seems to use as well if I have skimmed to all your previous posts well enough), I would gladly work this out.
That might very well be; however I would not ever try to solve this by fiddling with MIDI data, but by correcting the vastly better information captured in the score notation. Then have that generate the desired playback events: which is the first point at which that information is transformed/exported into MIDI.
While I'm convinced that you are way better informed about the MIDI specification than myself, you seem very pertinent about overlooking that MIDI *is* playback data, not notation information.
And whilst, yes, one can capture the necessary notation (more or less) into MIDI in this specific scenarios using the separate voices/channels approach; there is a bunch of notation information (articulations for example) that MIDI simply doesn't have the data model for.
And as you, yourself, have stated; it would *not* solve my situation one, as indeed in your program I'd still have to manually filter through the overlapping notes and silence where needed to get the correct playback in that situation; the exact same workaround as now already existing within MuseScore…
Again; no one in here has told you that being able to set a separate channel for each voice is undesired; even more so everyone has agreed and stood by you in saying that it would be an extremely useful addition to MuseScore.
However, many have also pointed out that it does not solve the mentioned issue, but merely shifts it to an eventual different program (if a program even is where the MIDI data is sent to) in the situation where the different voices within a staff should be processed into the same channel, because in some scenarios that is the correct thing to do. Why are you then so hellbent on trying to minimize and ignore that this other problem still stands?
As BSG says, there would be nothing non-standard at all about the resulting file. It would be indistinguishable from the file that would result if the overlapping notes were removed from the score and replaced by a single note of the combined duration, which is in effect exactly what we would be doing.
As for the difficulty, it's a linear stream of note on and off messages, not some arbitrarily complex hierarchical data structure. We don't need an existence proof of a solution to understand that the problem is not particularly hard to solve. It doesn't happen to be a super high priority for me, but FWIW, I did just add this to our 2.2 "hit list" of bugs to consider fixing for the next update. Actually adding the capability of assigning different channels to different voices is something that I think should be considered for 3.0
Hi jeetee. You wrote: "Why are you then so hellbent on trying to minimize and ignore that this other problem still stands?"
I haven't ignored this other problem; I outlined it clearly and stated the workaround which those using MIDI software have been employing for the past 20 years. I don't consider it a problem for MuseScore to behave as expected according to the existing example of all other serious music notation software. The problem is exactly that MuseScore does not behave as expected here. Once channel separation is a feature of MuseScore, users can deal with the problem of polyphonic overlap in the standard way = closed issue.
Marc Sabatella, you wrote: "We don't need an existence proof of a solution to understand that the problem is not particularly hard to solve. It doesn't happen to be a super high priority for me, but FWIW, I did just add this to our 2.2 "hit list" of bugs to consider fixing for the next update. Actually adding the capability of assigning different channels to different voices is something that I think should be considered for 3.0"
Glad to hear it, but by separating the "hit list" from the channel assignment feature, you've made it clear that you want (someone else) to pursue an alternate solution, not the industry-standard solution I've given (separate the channels). Fair enough. My warning stands, that dealing with this issue without separating channels is not the simple problem you claim it is. As I've said, I'll be happy to see anyone here prove me wrong. That will be all from me on this topic. My sincere thanks to everyone. MuseScore is an already excellent and endlessly improving application. Thank you again, and goodnight.
I should have been more clear. The solution where we remove the overlapping messages is easily implementable with no changes required to the GUi or file format, that is why I prioritize it the way I do. Adding a new feature to allow voices to be assigned their own channels would require GUI and file format changes and thus would have to wait. I suppose simply assigning voices to sequential channels automatically would also address the problem without the need for GUI and/or file format changes, but it would also break things for people who rely on the current channel assignments. So again, we would only consider a change like that for a major release. I think it makes more sense to make it optional anyhow, and to allow user selection of the specific channels, just as we now (in master/3.0) do for the instrument as a whole.
Allow me a last attempt at once again responding to why you've just now killed off compatibility with a whole set of use cases once again; because you've mentioned me specifically.
Simply not true.
If channel separation is the only solution (which as you've been told by different people already that it isn't) you've just broken(/made incorrect) the playback on most MIDI devices.
By using different channels the problem of overlapping notes playback for single-voices instruments (which is a reality; piano's do exist in the real world), you've not only simply moved the problem from MuseScore to a different MIDI software package; but you've also just ignored the whole universe of MIDI capable hardware (such as piano's; they *do* exist in the real world).
You have a stated very good hammer as solution and it is welcomed and will work marvelous for all nails; just don't go and ignore the fact that it is not the correct way of putting in screws.
While the standard allows for multiple channels (and as proven and agreed upon many times now, is a real necessity) it doesn't say anywhere that that should be enforced. Simply because at the very core MIDI still is a playback format and the information in a MIDI file should result in correct (intended) playback, without any further software postprocessing logic requirements!
Marc, not requiring UI is why I said in the initial post that MuseScore should do it automatically. If the user needs to change it, that is very easy to do in any editor, while the reverse is not easy (if that doesn't make sense, see below).
jeetee, "If channel separation is the only solution (which as you've been told by different people already that it isn't) you've just broken(/made incorrect) the playback on most MIDI devices."
Nonsense. First of all, the majority of MIDI synths include a standard MIDI receive mode called OMNI in which incoming MIDI data from any channel gets sent to the same destination, and in which this doubled note problem in fact vanishes *when multi-channel polyphonic MIDI as I describe is sent to the instrument in this mode* (on most devices, not all). Secondly, I said that ideally multiple channel assignment would be *up to the user*, so even if what you claim were true, you would still have no case - nothing would be "broken". Thirdly, if the software were to assign channels automatically (as I suggested as the easiest implementation in https://musescore.org/en/node/207346 where I brought up this issue) it is the work of a moment to reassign notes in a MIDI editor (1. select all from channel A, 2. assign to channel B), whereas when all the data is on one channel, and the user wants it separated, trying to select the notes to assign to separate channels in an editor is a mind-numbing, time wasting annoyance. Human beings have better things to do with their time. Speaking of which, the time I've spent here would be much better spent on my own work, so I wish you farewell for a second time. But lastly, as for what I've "been told" about alternate solutions to this problem - for the last time, trying to deal with this issue without separating channels 1. ignores all professional precedent, and 2. is tilting at windmills; knock yourself out. Sorry for all this bloody repetition. I promise to ignore all further nonsense. Please have a lovely day, everyone.
Why would you have to put your device in a special mode that (you admit) not all MIDI devices have (or warn others using your file that they must) if your proposed solution is "standard"? And "respond to all channels" would work really well (not) if you have more than one instrument (or manual, for VPO's). Hauptwerk (very reasonably) assigns one channel per manual (or pedal) and has no optional channel routings, and leaves nothing to be desired as a showcase powerful MIDI-based platform.
As you're leaving the conversation, I'm unsure whether you'll still read this. If so, consider this an answer out of courtesy:
Ignoring reality isn't helping your case; I have a very nice MIDI-capable organ in my garage, it handles either single-channel or 3-channel MIDI. It does not have an OMNI mode. This is a very real use case you are trying to dismiss.
So do we, ever from the start of this whole overly-pedantic topic
Again, incorrect! Nothing would break additionally; but the output produced for overlapping notes in a single channel, if the user chooses to (because backwards compatibility and hardware) would be equally broken as it is now. You would get this exact same bug report as you have now.
Almost, except that you (as a user) would also still have the same overlapping notes velocity/volume bug; which you'd *still* have to solve, but now in a different program (the MIDI editor vs MuseScore). This is simply shifting the bug out to other software to deal with it; not fixing it.
Entirely agreed, nobody ever claimed that attempting to restore sensible notation out of MIDI data (which is *a lot* more than simple polyphony) is a fun nor an easy task.
It very well could be, after all you are the only one who can value your own time. But do bear in mind that the same hold true for all of us. Everyone taking part in this discussion so far has done so in their own time; even more so they have done so in the intention of helping you with your problem to come up with a more complete solution that would handle all use cases, not just your own.
For the equally last time, as elaborated in this answer once again. Your solution only solves 1 of the root causes of this bug appearing and does *nothing* at all to fix the 2nd part of this very bug report. As to the root cause you're attempting to address, nobody (again nobody) has contested the usefulness nor the professionalism of it. As to the (even after the separate channels) other reason this bug then would still exist, the solution is indeed rather trivial in approach; keeping track of notes currently sounding within a channel. Far from rocket science. So yes, we will get to fixing that (even without having to knock myself out), but as you so eloquently stated; when the value of our own time permits.
The reason an automatic assigent of channels for voices is less than ideal for MuseScore is that we already (in master) allow the user to select their own channels for instruments. A user who cares enough about channel assignment to do that wouldn't necessary want his carefully crafterld channel scheme messed up. So we'd need to support that use case as well. And in any event as I said it would require a file format change. That's why it seems to me anynsuhnew feature would need to wait for 3.0.
On the flip side, also remember again our typical user is not a MIDI expert and probably owns no MIDI hardware or editing software of any kind. That is why it is important we support solutions that do not rely on MIDI editors as well. Many different use cases to consider and support, and that is why we are trying to look at the bigger picture.
So again, allowing for different channels for different voices is a fine idea, but it needs to be considered in this broader context.
Came up again in https://musescore.org/en/node/223116
https://musescore.org/en/node/207346#comment-759786 contains information for a script I just wrote that, as a stopgap measure (until fixed in MuseScore itself), checks scores for note collisions, so users can correct their playback with the “mute shorter note or, if the shorter one begins before the longer, mute both and insert a hidden one with playback” method iff the score uses the “keyboard model” (BSG), not the “multi-instrument model” (.function_).
I fully agree with this though:
17:52⎜«lasconic:#musescore» cool, but it will just delay the actual fix even more :)
17:52⎜«lasconic:#musescore» since there is a workaround for hackers
17:53⎜«lasconic:#musescore» the entry point for rendering MIDI is here
⎜ https://github.com/musescore/MuseScore/blob/master/libmscore/rendermidi…
17:53⎜«lasconic:#musescore» at the end we have a map of "ticks -> Event()"
17:54⎜«lasconic:#musescore» it would probably be more effective to do it while generating events though
Noting it here until someone gets time to hack the proper fix. See also https://musescore.org/en/node/207346#comment-759316 for why three mostly-independent fixes are required.
Came up again in https://musescore.org/en/node/267841
Came up again in https://musescore.org/en/node/269343
And in: https://musescore.org/fr/node/269342
Having lived with this for years now, and thought about MIDI, unisons, and the meaning of "keyboard" deeply for a year, I am convinced that both the problem and adequate solutions to it are deeper than an overview might indicate. However, the flood of correctly-entered polyphonic keyboard, mainly piano, scores I see entered (that I care about -- there must be hundreds daily that I don't) manifest this clobbering on unwary users, often new, who don't even know that the sound of their score is corrupt (with respect to the composer's intent), is unceasing. I hear "unison-clipped" scores from both new users and experienced hands every day. (I have so forced myself to be on the lookout for it that it calls out to me when playing the organ!) The "first approximation" solution, even as a default, would be a vast improvement: discard note-on's for notes on (on a given channel), and note-off's for notes continuing. An extremely obscure option can say "don't do this." My MIDI postprocessing code (for virtual pipe organs) does exactly this.
Or just count note-on's (++) and note off's (--) and stop playback when the counter is 0
Something like you mentioned in https://musescore.org/en/node/12971#comment-453976 already (only that 127 slots are enough, as there are only that many pitches)
There are many cases to consider, which would need to be handled differently. First, tracks and channels:
The third case may seem like it doesn't need handling, but it does in cases where the destination disregards channel info per track.
For the 4th case, Notes on different tracks on different channels, nothing would normally need to be done (although some may disagree, since both Track and Channel info may be disregarded by the destination).
Then there are several cases of Notes overlapping which have to be considered and handled differently.
For the fourth case, where the same note begins together and ends together, nothing needs to be done (although some may disagree, since sometimes a doubled Note ON can cause a choke at the destination).
This gives us 3 x 3 = 9 different possible cases to consider. 12, if you want to also handle Tack/Channel case 4 above, or the 4th notes case. 16 if all cases are considered.
So how would each case be handled?
Let's take a look at just one of these cases:
****** Example case ****** – Notes on different tracks on the same channel begin and end at different times.
I'll make a diagram for this. Say a note usually looks like this, where + is Note ON and | is Note OFF, and T and C are Track and Channel.
+T1C1---|
Above represents Note ON and Note OFF for a note on Track 1, Channel 1.
Beginning and ending at different times means we have a shorter note inside of a longer note, so it will look something like this:
+T1C1--------+T2C1---|--------|
A note on Track 2, Channel 1, begins in the middle and ends before the other note ends.
In this case, to reproduce the behaviour of a keyboard player (a stated goal of other participants in this discussion), we would need to to the following:
The result would look like this:
+T1C1-------|+T2C1------------|
This would be correct: both tracks maintain Note ON, Note OFF, and the MIDI data still parses independently per Track.
I leave it to you to work out the other cases. A subset will emerge, but there is no way to handle all cases the same while maintaining MIDI that will parse correctly.
Cheers.
In reply to There are many cases to… by neo-barock
Oh, yes, I wanted to work at this bug. Sorry, had a bit of lack of real-life time. But, soon. I dare promise. This got moved somewhat high up on my TODO, with very few above it.
One question though: if I put, in your last example, a note-off on T1 before the note-on on T2, wouldn’t that be the equivalent of restriking?
I have created a testcase setting for most common MuseScore output, and I’ll try to fix that one first, we can see whether the other cases will need handling afterwards.
In reply to There are many cases to… by neo-barock
Although, as we have discussed, a feature where different "voices" in the MuseScore sense route to different channels would be welcome, it doesn't now exist, and AFAIK it is not possible to produce simultaneous notes for different channels on the same track in MuseScore. Please correct me if I'm wrong.
Modifying the behavior of notes on different channels because of the possibility that you might want to feed it to a device which ignores channels would defeat the purpose of having channels, sort of like reducing a painting to black and white because some of your viewers might not have color vision. This would be very, very wrong.
This is about the behavior of MIDI channels as defined and notes on one channel, indeed, regardless of on which staff (staves and tracks are 1/1 in MuseScore) they appear (multi-staff ("grand staff") instruments evidence this misbehavior between "hands" (or organ pedal if you use MuseScore 3-staff "organ", and this is a reason not to). Consideration of same channel, different staff/track is indeed required.
While re-striking is certainly a possible behavior and more appropriate in some circumstances than others, it must, in my view, be optional. For instance, when an organ pedal is coupled to a manual, as happens everyday, and the manual part intersects the pedal part mid-note, no restriking is heard or possible (and this has been so as long as organs have been built, i.e., for fully-mechanical organs). Consider also multiple choral voices on a staff, as in a hymnal; re-striking would be wrong.
In reply to Although, as we have… by [DELETED] 1831606
OK, so we have same-track-same-channel and different-track-same-channel to worry about for now.
An intuïtive approach at the latter would be to hoist the entire duration to the track in which it was started first, so…
… becomes …
Intuitive, sure (I have an actual idea of how to implement this), but does handling it like this break anything? Remember, we’re still thinking about the “no re-stroke” scenario, so you couldn’t have a different sound for the last part or so anyway.
!@#$#$@# (Excuse my language!) We didn't think about "What track should contain the altered result?" I think that would tax the wisdom of Solomon. I can't envision a clean answer (but this case most certainly does arise for "grand staves"). (Nonetheless, I'd be grateful for that, as would countless users who don't know a track from a railroad station).
Don’t worry, I understand ☺
But I think that, for the majority of users (not use cases; the majority has the use case of “make this score play somehow”) this would fix the most pressing issue, and it’d likely be better than nothing.
By the way, you’re cordially invited to discuss this on IRC; that has a faster response turnaround time, and I’ve got easier access to that than to a webbrowser (while web-based IRC exists).
In reply to Don’t worry, I understand ☺… by mirabilos
I don't have an IRC presence. Different track, same channel presents this problem we hadn't thought of. The proposed solution could mess up on some platform that had controls to ignore specified tracks for playback.
I think a conservative approach would be to do this (as proposed) whenn (when and only when :) output is to the MS synthesizer, where it is guaranteed to work; that would rescue the user community. External-target Midi files could be declared "somebody else's problem" and left as today.
In reply to I don't have an IRC presence… by [DELETED] 1831606
MuseScore has an IRC presence, but okay.
I’ll have to check how other “simple” MIDI players (like the ones that come with Windows and BSD, and the often-used ones like timidity) deal with this… hmm.
@ MuseScore core team: any preference?
This is about MIDI generating, not midi playing. A midi player has no choice but to emit events to its hardware at the time for which each is indicated, without "lookahead", thereby clipping unisons. Although I suppose a MIDI player indeed could "keep count" per channel ... as could MS', perhaps....
In reply to This is about midi… by [DELETED] 1831606
Perhaps the possible solution is:
if there is two sequential (consecutive) note-off messages for the same pitch:
ignore the early one.
In reply to Perhaps the possible… by Ziya Mete Demircan
Sounds like Jojo had the best solution. Count the ons and offs and send an off only when they are equal.
different "voices" in the MuseScore sense route to different channels would be welcome, it doesn't now exist, and AFAIK it is not possible to produce simultaneous notes for different channels on the same track in MuseScore.
If by track you mean staff, sure it is. See https://musescore.com/nicolas/scores/2223116
Well, that's terrific, there's capability in the data structure with no UI for accessing it short of "hacking" its xml representation. Hoping for accessibility to capability soon! At any rate, voices on different channels are not subject to the unison collision problem; the bass should not silence the tenor in a well-run chorus. Re: your "you mean", do you know of any case in MuseScore when visible staves are not represented one-for-one by MIDI tracks in exported midi output (although the question of whether the discussion is about exported midi output in addition to MS rendering behavior seems open, and as I said, I vote against).
https://github.com/musescore/MuseScore/pull/3513 fixes this for the cases
I ask that, at the very least, this one commit makes the hit list for 2.2
https://github.com/musescore/MuseScore/pull/3514 fixes it for most other cases, I still get the one or other collision detected by my script though and will work on improving this.
3513 is more important to land in 2.2
3514 is more intrusive, would be nice if it could also make it, though
In reply to https://github.com/musescore… by mirabilos
I'm sufficiently unfamiliar with the code base that I think it fair and most efficient to ask you to post here a description of exactly what policy you've implemented rather the decode what you did, ... if you would. This is "one giant step for mankind" if this really does it ...
In reply to I'm sufficiently unfamiliar… by [DELETED] 1831606
OK, let me try… had to get half a night’s worth of sleep first, and then $dayjob.
The first commit introduces a “fixupMIDI” step. The first problem I encountered was that I could not do refcounting while the events were created because the staves were done individually, although into the same list of events, so I had to create this as a separate step.
Except for the *.mid file export, all callers used a function that already did “foreach staff: export events; then export pedals, etc. and metronome”, so I could simply call the fixupMIDI step after the for-each-stuff export had run.
The fixupMIDI step itself tracks whether a note was already playing or not, and removes all note_on events that should not be there (note_off is never emitted by MuseScore, just note_on with velocity 0). I keep track by each of the 128 (0‥127) MIDI notes, per channel.
Now this “channel” is not the MIDI channel (0‥15) but rather a combination of “MIDI port * 16 + MIDI channel inside that port” so we can have more than 15+percussion simultaneously-playing instruments. But that’s fine.
This also made me learn about that the collision is not affected by which track a note_on event is on, just which channel on what port.
All was fine, especially for playback. However, *.mid file export assigns a stave to a MIDI track, and so exported them individually. (It also does pedals etc. but not the metronome.) So all I could do was to fix in-the-same-track collisions (between voices on the same stave), but grand-staff or cross-instrument collisions would still be there.
I’ve also had to fixup a few testcases whose reference data had collisions. I manually verified these changes.
Still a MASSIVE improvement. That was the first commit, and the one I would like to get into 2.2 at all costs.
Then I tackled MIDI file export. I changed the NPlayEvent class (an object of which is basically a single MIDI event) to have an additional field, to keep track of the originating stave. (Pedal logic was a bit tricker, but I was able to pass the stave number through.)
Then I made the metronome in the export function optional, made the MIDI export call the regular export function, and then just filter the event list by originating stave.
Finally, I changed the fixupMIDI step to also keep track, for any playing (channel, note) tuple, which stave the “on” event originated on, so I could hoist the corresponding “off” event to the same stave. (Imagine half-note C then something else in track 1, and quarter-rest then half-note C in track 2. This must be played as a dotted half-note C in track 1, and nothing in track 2 at all. Yes, this makes the MIDI export match the sheet music a bit less, but not doing so would confuse players, and after all, MuseScore is about notation first, playback second, and MIDI last.)
This works surprisingly well, even though the code is more intrusive. I’ve kept it as several individual, separate commits, to ease review.
There are still a few collisions I get in some scores of mine, see https://github.com/musescore/MuseScore/pull/3514#issuecomment-370301906 for an example, but I believe this to not be a problem of the code I touched, but rather, why the soprano solo is assigned to the same channel as the harpsichord. But I needed some rest, and I’ve proposed both changes to the MuseScore dev team and uploaded them to Debian experimental, for people to play with. I’ll send them to Debian unstable after some more testing (and I hope I find the remaining issues first; help welcome).
I figured out the remaining collisions I got were from a bug in my check script (it did not take different MIDI ports into account).
Even after removing the “make one of the notes silent” workaround from all my scores, they are now collision-free, with the patches I submitted applied. So this is indeed a big first step (of course, MIDI export can still be improved, but playback — both in MuseScore itself and using external MIDI players like timidity — is now largely fixed; the first track issue needs to be resolved, and MIDI experts like BSG need to have a look at the *.mid files generated after this patch, but that’s beyond my skillset).
In reply to I figured out the remaining… by mirabilos
Did you test cases of non-cleanly overlapped notes, i.e., alpha starts ... some time.... beta starts .... some time .... alpha finishes .... beta finishes? There was one of those I encountered in a Bach 4-voice chorale today .... let me know when there's a mac executable I can try (I can use others, but much more work)...
Thanks for your work on this, it's long time due ....
In reply to Did you test cases of non… by [DELETED] 1831606
I’ve tested with the attached score (second measure is where the difference between 2.1 and 2.2-with-this-patch-applied is, first measure has the second C4 silent), so I think it’s correct as well.
In MIDI, it exports as if there were a single whole C4 note in the upper staff. (For some probably-funny reason, it’s got a dot and is marked as staccato. Perhaps someone can fix this up later.) It plays right in timidity for me, though.
Edit: sorry, can’t help with Macintosh binaries, but Debian experimental has Linux binaries of it.
In reply to I’ve tested with the… by mirabilos
Will the Debian binary work on Ubuntu? If so, where are instructions for grabbing it?
In reply to Will the Debian binary work… by [DELETED] 1831606
No, but if you tell me your Ubuntu version I’ll build one for you.
In reply to No, but if you tell me your… by mirabilos
16.04.3 LTS -- Send me site mail rather than annoying all these thread followers.
In reply to 16.04.3 LTS -- Send me… by [DELETED] 1831606
I have obtained the .deb's from @mirabilos and installed it on 64-bit Ubuntu, and it surely seems to fix the "note truncation problem" on playback. I will continue with testing including detailed MIDI inspection and report any issues found. This is a giant step for MuseScore.
Fixed in branch 2.2, commit c2f0b8b330
fix #12971: note collisions in playback
Also adjust MIDI testcases: the reference output did
hardcode the old behaviour of not refcounting.
WOW, I can not believe that this issue is solved.
So good, so great! :) I did not expect it much anymore.
Big thanks to Mirabilos for this.
Reopening for master, see https://github.com/musescore/MuseScore/pull/3548
See https://musescore.org/en/node/270783, I suspect this is a result of the fix for this issue?
In reply to See https://musescore.org/en… by Jojo-Schmitz
No, it was a result of the merged fix for #270408.
We have a fix for the fix (besides switching to my fix for #270408 and reopening #270562) though: https://musescore.org/en/node/270878#comment-827502
See my comments here. Sorry I didn't discuss this earlier. Finer control is needed; performance techniques vary between different keyboard instruments. Please read.
https://musescore.com/groups/3642106/discuss/5016741
@BSG: Restriking is only a temporary workaround for 2.2 until we have an easy method to assign different voices to different MIDI channels (I have a manual method for up to eight(!) MIDI channels for a Grand Staff, four per hand); lasconic has already said that he agrees and restriking will not survive for the long term.
We’ll get finer control, it’s just not easy. It was hard enough getting the current improvements, however incomplete they may be, to work in the first place, especially just in time for the release.
In reply to @BSG: Restriking is only a… by mirabilos
Well, then bravo again. 3-channel (not 12!) organs necessary; as per the old discussion, "interfering" behavior is expected and correct for a single keyboard/manual -- if/when "channel per voice" is implemented, multiple voices to the same channel, with coincidence management as now, must be an option.
I think I would want "no restriking" as an option. Restriking is reasonable for harpsichord, but questionable for organ (on one channel).
In reply to Well, then bravo again. 3… by [DELETED] 1831606
As I said, “no restriking” will be the only behaviour in… some future version of MuseScore that supports channel assignment in a user-friendlier way (perhaps 2.3, perhaps 2.4 or 3.0).
The timing was too tight to allow for an option, and 2.2 is out of the door by now.
In reply to As I said, “no restriking”… by mirabilos
"Make haste to help, and tarry not!" The restrikes are pretty jarring for hymn-book-disposition choral scores, whereby the soprano hiccups as the alto passes her, but surely better than the clipping heretofore. Surely, user management (silencing the collider as in yesterversion) remains an option. People will figure it out. Channel per voice is the obvious future solution.
As per https://musescore.com/groups/improving-musescore-com/discuss/5020402 and https://musescore.com/groups/improving-musescore-com/discuss/5020455 this issue still/again exists on musescore.com
In reply to As per https://musescore.com… by Jojo-Schmitz
How could it be? The fix in the 2.3.1 release and in the backend of .com
Good question! Next one please ;-)
The discussion on MS.Com list sample scores:
https://musescore.com/user/23292276/scores/5155303
measures 1268-1269 and 1284-1285.
and
https://musescore.com/user/18902116/scores/5158391
measure 58
I can't reproduce it though, not the latter at least, it just sounds as it should, a long C3 spanning several measures
In reply to Good question! Newt one… by Jojo-Schmitz
He kludged his score after I told him. Here's a brand new minimal test case:
https://musescore.com/user/1831606/scores/5159462
OK, confirmed, sound OK in MuseScore, not OK on MueScore.com (in IE11)
It has nothing to do with MuseScore.com since MuseScore.com just runs MuseScore 2.3.1. The problem is not fixed in MuseScore audio export. You can download the score from @BSG, play it and it sounds ok, export it to MP3 and it doesn't sound right. MuseScore.com does exactly that, export to MP3, and so it doesn't work. It seems nobody tested audio export so far...
In reply to It has nothing to do with… by [DELETED] 5
That's a mighty serious problem, which affects everyone who posts scores, with no way to reach them or explain the problem or work-around (manage unison collisions manually as pre-2.2) until a fix is propagated.
In reply to It has nothing to do with… by [DELETED] 5
I can confirm that.
This is a bug in lasconic’s restriking patch; I just installed into a chroot a version of MuseScore from where my patch for this issue was applied instead (Debian’s 2.1.0+dfsg3-3 version), and its audio export went just fine.
Since the restriking patch is a temporary band-aid anyway…
Fixed in branch musescore_backend_231, commit fd3f882f16
fix #12971: restriking in audio export
So fixed (soon?) on musescore.com, but not yet in master, and won't get fixed in 2.3.x (unless being a) on Windows and b) brave enough to grab and install the AppVeyor artefact)?
The change basically applies the same fix to export that was previously applied to playback? If so, that seems fine. But does it seem concerning to anyone that the paths are different enough that this sort of thing keeps happening? Is there a way to refactor things to prevent issues like this (a fix that is applied to playback but not export, or vice versa) in the future?
It was a quick hot fix but indeed, the export audio code should be factorized a bit more. In the meantime, the bug is fixed on musescore.com.
Fixed in branch 2.3.2, commit d5a81add16
fix #12971: restriking in audio export
Interesting 2.3.2...
Still need to reopen for master
In reply to Interesting 2.3.2… by Jojo-Schmitz
No; after all, https://github.com/musescore/MuseScore/pull/3548 was never applied to master. (It does also lack the latest changes from 2.x, although I could update the PR if needed. That said, restriking should be eventually gone anyway…)
+1 on the refactoring from me, but please only after PR3548 was applied and restriking reverted, otherwise maintaining the two different kinds of fixes for the unison problem is going to be a nightmare.
If I may be so bold as to propose we do so now, i.e. merge only the first commit of PR3548 (which is basically the entirety of the no-restriking version, although I’d have to recheck against https://github.com/musescore/MuseScore/pull/3797 and update to latest master), then 3.0 will already sound as desired without the restriking, and we’ll “just” need some UI for channel assignment (for which I still have some idea but no code yet… it’s only slowly getting closer, and perhaps I need to talk to other devs and/or do this in pair programming…).
Fixed in branch master, commit d741d5055f
fix #12971, #270408, #270783: note collisions in playback
Also adjust MIDI testcases: the reference output did
hardcode the old behaviour of not refcounting.
Automatically closed -- issue fixed for 2 weeks with no activity.