Maximum number of parts (or notes?) using same instrument?
Hello all,
Is there a limit to the maximum number of parts or notes that can use the same instrument? If so, is this a limit of musescore, the synthesizer it uses, or the MIDI standard?
I have a choral piece that I've transcribed for my mother's choir while they are short a pianist. My intent is to use a digital keyboard for both practice and playing in the interim.
I transcribed a piece with the four vocal lines (SATB) as separate parts, and the piano as a fifth. The piano part looks complicated to me (I normally just sing one bass note at a time), and has a lot of chords, dynamics, etc.
When I listen to with the four SATB parts in Ahh choir and piano at the default grand, it seems to play fine. I hear the piano part clearly, and the SATB Ahhs blending together. However, for practice I want to have the SATB parts play as piano, with the piano parts played at reduced volume. When I set the mixer to play as Piano, however... notes get cut off. Especially those of the piano bass clef.
I'm not sure if there's a limit I'm reaching in Musecore, or the synthesizer, or MIDI standard or... I'm just doing this the hard way.
For actual practice / play, I'm exporting this as a MIDI file with parts, saving to USB, and loading on the DP that the choir has never used (a Roland 300GX). It plays the piano part beautifully, so what I'm doing in general seems to work... just don't know why I'm losing some notes in playback in Musescore.
The DP isn't local to me, so I can't readily export to MIDI and see if it plays fine on the DP.
FWIW, I'm running this on a Mac if that's relevant.
Thoughts?
Thank you,
G.B.
Comments
There is no such limit. Can you share the score?
There is a known bug in 2.0.3 where unison notes are cut off when the shorter note is played. So if you have a 1/8 note G in one piano and a whole note G on another piano you will only get the 1/8 note.
In reply to There is a known bug in 2.0.3 by mike320
see #12971: Same note in different voices and lengths plays only the length of the shortest note
Workaround is to silence the shorter note
In reply to see #12971: Same note in by Jojo-Schmitz
Thanks for referencing this in the bug trail. Didn't realize I'd have such an impact with my first post.
This is an issue only with playback in Musecore, though, and not with the MIDI export? That's what I seemed to gather from reading the bug reports.
I agree with other posters that the workaround is... complicated. With the four SATB lines separate from the piano, and the piano has the shorter notes, I can't rewrite the piano part.
Can I workaround this by playing the SATB as a different instrument? A slightly different piano?
Playing the SATB lines is only for practice... although as the SATB parts aren't as clearly in the piano parts as other pieces the choir has done, I did mention to the choir director that we could insert them at some points for the more difficult transitions.
Thank you,
G.B.
In reply to Thanks for referencing this by gwapobass
The SATB should definitely be a separate instrument from the accompaniment - should eb set up that way by default if you are using one of the supplied templates. The problem only occurs when there is overlap within a single MIDI channel, which means a single instrument. Having separate instruments / channels also allows independent volume control in the Mixer, etc. A good idea all around.
If you need further assistance, feel free to attach the score you are having trouble with and we can advise better.
In reply to There is a known bug in 2.0.3 by mike320
Not really a bug, but a behavior. (Maybe change in upcoming releases, or may be an option.)
There is the very similar problem in other software. And they try different solutions (see attachment).
Note: the attached file is not related to MuseScore. This indicates that: another software has a very similar problem.
In reply to Not really a bug, but a by Ziya Mete Demircan
Your picture indicates that this can be fixed through software and the fact there is an option to override this in that software is just silly - it should be automatic.
In reply to Your picture indicates that by mike320
I don't know why the software is put as an option.
Some ideas:
Maybe he thinks, "As long as you hold down the same key, you can not play the same note again". Because there is "sustain-pedal" for this.
And if midi files written for piano (or mono instruments) are used, they want to block some mistakes.
But the same thing doesn't apply to the guitar.
If the developer doesn't know which one is right, he may want to put it as an option.
And maybe: some earlier midi files may no longer work as desired.
These are all speculative ideas. I don't know.
Maybe like me, the software guy didn't know. :D
In reply to There is a known bug in 2.0.3 by mike320
Thank you for replies, all.
Is this a limit only in the synthesizer part of Musecscore, or is it a bug in how it renders the export to MIDI as well. I can live with a synthesizer only issue.
As I think about this, I suppose I could verify if it affects the MIDI output by exporting to MIDI and opening it in an app that understands it.
In reply to Thank you for replies, by gwapobass
My assumption is it will export exactly what your score contains: note on, note on, note off, note off. How any given program or device chooses to handle that is up to that program or device. It's probably pretty common that many would see the first note off and shut the sound off then, thus chopping the sound off early just as MuseScore. Other programs/device might be smart enough to realize there are two notes sounding and not shut the sound off until the second note off is received.
In reply to Thank you for replies, by gwapobass
Almost all older software (including MIDI keyboards) behaves as MuseScore does right now.
For example: MIDI file says:
1. time 01, channel1, key 63, velocity 80,
2. time 24, channel 1, key 63, velocity 80,
3. time 36, channel 1, key 63, velocity 0, (*)
4. time 54, channel 1, key 63, velocity 0,
(*) What does the software do when it comes to "3rd step"?
Option 1: #63 key is off. (So all # 63s are off / General) //just send same message to DSP; no more programming required. :/
Option 2: just off the first #63. The other continues. (Rare) //more programming required :)
Every software has its own behavior.
I prefer option 1. : polyphonic++
:D
In reply to Almost all older software by Ziya Mete Demircan
All,
Thank you for prompt feedback and analysis of the issue. I worked around it by setting the SATB parts to a different piano, and it plays as I want it to.
WRT to the discussion as to if this is a bug / feature / working as expected / has to work this way... here's my thoughts, and I'm putting on my hat as a network consultant and analyst now (Hey, we're talking protocols now!).
I acknowledge that keyboards, as a MIDI receiver, don't have a good answer for _receiving_ poorly formed instructions like the example above: turning the same key on twice, then turning it off.... okay, now what do I do. I agree with that.
What I don't agree with is that this is a good reason to sweep it under the rug for Musescore. It is not a MIDI receiver, it is the MIDI generator. It knows all the notes that will be played, by all parts, on all instruments, and on all staves. It could and IMHO should be able to see the potential conflict before it happens, select a method to resolve it (possibly a recommended method depending on instrument, and/or other options a user could select), and generate MIDI with good instructions that a receiver can follow.
Whatever that default recommended action may be... clipping the notes to the shortest on the piano seems wrong to me.
The recommended action may vary depending on when the duplicated note is received, i.e.,
If same note is played twice and begin at same time, then set duration to that of longest note. For extra credit, if combing two voices or parts, increase volume (velocity?) to account for convergence.
If same note is repeated partway through duration of first note, I'd suggest repeating it (note off/note on) and maintaining the longer duration. (More extra credit... if there's a velocity difference... can that be diminished after the higher velocity note ends if lower velocity note continues?)
MIDI may be an old protocol, but its still effective and as far as I know, still the standard for interfacing with digital music devices. I don't expect any revisions to it to add intelligence for the MIDI protocol or the receiver to figure out the intent of ambiguous instructions, but I can expect the software generating the MIDI to figure out the best course of action, whether that action is an intelligent default recommendation, or a user selection.
Peace,
G.B.
In reply to All, Thank you for prompt by gwapobass
FWIW, while it is open to interpretation as to what the correct behavior might be from a purely MIDI perspective, there is no doubt in my mind that this should be considered a bug for the playback feature of a notation program. That is, the playback features of a notation program shouldn't be hampered unnecessarily by limitations of MIDI if there is any way to avoid it. And in this case, there is a way for MsueScore to avoid it - we just need to detect this situation and avoid sending the problematic MIDI messages.
Unfortunately, this is easier said than done, and as with all bugs, we need to prioritize it to decide which bugs to work on first. And the fact that MuseScore is a notation program first means that bugs that affect notation tend to be prioritized higher than bugs that affect playback only. That is not to say playback bugs never get fixed - they do. This one just hasn't quite risen to the top yet. Maybe someone reading this will take it upon themselves to give it a shot...