It could be useful to allow different voices within a staff to have different sounds and dynamics if desired

• May 16, 2023 - 21:55

I'm not sure exactly how this could be implemented, but as an orchestral composer, I think it would be useful to allow different voices on one staff to have different sounds. A classic example is in choral music where sopranos and altos share a staff, and tenors and basses share another. Another fairly common example involving orchestral strings to put a non-dedicated solo part together with the ensemble part on one staff, with one voice for the soloist and another for the ensemble). An example is https://www.jwpepper.com/Incantations/2478662.item#.ZGPoRU_MKUk, which includes this on the very first page.

So far, this isn't possible without using a second instrument or instrument changes (which are cumbersome since I have to change to a completely different instrument and then change the clefs, sound, and range to match what I'm looking for).


Comments

Different sounds are possible, with certain instruments or a bit of trickery (and in 3.x, not sure this works in 4.0), for the closed score SATB templates that is possible without (much) trickery, there Soprano, Alto, Tenor and Bass do have their own channels in the Mixer, there you can assign different sounds.
Different dynamics had been requested long ago, I still hope they happen one day, until then only tricks help, like changing the notes' velocity one by one

In reply to by Jojo-Schmitz

"... for the closed score SATB templates that is possible without (much) trickery, there Soprano, Alto, Tenor and Bass do have their own channels in the Mixer, there you can assign different sounds"

I can't see how to do this in MS4. There is already a Github issue to remove the previous Text elements (S/A and T/B) :
https://github.com/musescore/MuseScore/issues/14903
What about my 300+ existing (unlisted) scores which rely on the use of those hidden S/A and T/B elements?

Nor does the MS4 Mixer allow the "expansion" of voices on a single staff into two separate channels, as is possible in MS3. This was highlighted in the article "MuseScore 3 features not implemented in MuseScore 4":
https://musescore.org/en/node/334701#Independent_control_of_subchannels

Until someone can explain to me how to implement these "lost" features in MS4, I will simply continue to use MS 3.6.2. And that is not because I am being a luddite - it's simply that MS4 currently breaks my workflow entirely. I have always used MuseScore to create closed-score SATB practice files for choirs, and that requires the ability to control separately the two voices on a single staff.

In reply to by Marc Sabatella

"This is all being re-designed to not require the sort of awkward workarounds needed previously"

Marc, I appreciate that you are trying to circle the waggons (US=wagons), but previously it just worked fine. And now it's broken. So you bet I "can stick to MU3 for now". ;-)

In reply to by DanielR

I think saying "previously it just worked fine" is a pretty enormous overstatement. Consider, it only worked for two specific instruments ("Men" and "Women"), and also required people to know about and add special text elements to their score, and also required people to discover and figure out the expand button in the mixer. Basically, if you didn't already know how to do it, there was essentially zero chance of figuring it out on your own, and even if you did you'd only ever be able to get it to work for those two specific instruments. It was an awkward undiscoverable hack at best. That's why the intent is to replace it with something that actually does works well.

So this is actually a pretty good example of something that really had to go to make room for a better system - continuing to support the old system forever really would not be a viable way to move forward. I too hate to see old features go, but sometimes it really is needed in order to make progress. I certainly share the wish that they would have replaced this one already for 4.0 rather than making people wait, but it is what it is. If sticking with MU3 weren't an option, then I'm sure the tradeoff would have been made differently. But luckily, sticking with MU3 is an option, so there was no harm - and quite a few very significant advantages - in allowing people who don't need that feature to start taking advantage of MU4 already.

In reply to by Jojo-Schmitz

Indeed, like I said, I personally wouldn't have made that choice for this feature, but of course the "replacement" is, just continue using MU3 a while longer for the cases where the feature in question is needed. Seems viable to me. Again, it allows the majority to start taking advantage of MU4 now rather than having to wait. And then by the time the remaining features get added back, the users who had been waiting for them will have the advantage of a more mature product with that much more testing and bug fixes for the basic features.

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