-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add invisible way to split chords for better playback #23843
Comments
I have the opposite problem - at least for string sections, I can't hear any difference between chords (double-stops) and notes in multiple voices (implying divisi). And of course if it's a solo instrument two notes at the same time (regardless of whether you use chords or separate voices) can only be played via double-stopping. |
Is the request here to be able to hear different notes in a chord at different volume levels? If it is about dynamic levels, then it is currently possible to use the velocity controls in Properties to "voice" individual notes within a chord. This property, however, currently only works for MS Basic/VST (Something we'd need to look at fixing for Muse Sounds in the future). |
Different volume levels would of course be great but what I'm talking about is that when the chords are split into single-note melody lines in separate voices they are played more smoothly. The notes connect to each other more and it sounds more like several instruments playing the melodies that form the chords and not just chords played with a soundfont The issue is that getting the legato sound with the block chord look can be fiddly as you have to manually set all the stem directions or sometimes extend the stems, and these things can change if you change the notes (so maybe a stem now needs to be longer to cover a new gap or you have to notice that the stems should now point up because the lowest note got lower). The default way that block chords look already takes care of all these things, so my suggestion is to have some way to change the sound without affecting how it looks |
That's just a bug - legato vs non-legato should be determined by the use of legato slurs (or sound flags), not whether notes are in chords. |
I just checked and slurs don't change the playback at all, at least in this case, so I guess that's the bug |
It does with classic phrasing, which is currently only available for Muse Brass, and with at least some of the paid libraries.
In the sense it's a regression compared to V3 where slurs did always affect playback, yes, I would consider it a bug.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Yoav Shati ***@***.***>
Sent: Sunday, August 4, 2024 4:29:56 AM
To: musescore/MuseScore ***@***.***>
Cc: wizofaus ***@***.***>; Comment ***@***.***>
Subject: Re: [musescore/MuseScore] Add invisible way to split chords for better playback (Issue #23843)
I just checked and slurs don't change the playback at all, at least in this case, so I guess that's the bug
—
Reply to this email directly, view it on GitHub<#23843 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABI5UAJU74FPLYK42XRRCA3ZPUOSJAVCNFSM6AAAAABLXHVCUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGA4TKNBTGY>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Slurs did not affect playback in MU3 (or any previous release), except for piano and flute and in a really silly way: absence of a slur shortened the duration by 5%, so that slurring would make things seem smoother. But attacks were never altered, and again, it was only implemented (as kind of an experiment that was never followed up on) on those two instruments. |
I tweaked my scores so that it did for all instruments, and that 95% vs 100% thing actually made a big difference between in sounding "free of re-articulations" vs "would obviously require being re-articulated on a real instrument", even the quality of the samples wasn't enough to hear those articulations (I'm primarily talking strings and winds obviously). The main problem is that 95% is too short for very long notes - really it should be a fixed time gap between notes in ms. |
BTW, the reason with MS 4.3 you can't really hear a difference between slurred and unslurred notes with MS Basic is because of this, e.g. in general_wind_articulations_profile.json:
If you change it to 9500 (95%) you can definitely hear the difference, esp. if you also change "Legato" to durationFactor of 10000. However this on its own only affects playback via the fluidsynth/MIDI-based engine, not through Muse Sampler. Example score: https://musescore.com/user/7209246/scores/20010427/s/8UPdf3 (seems not to load? exported audio here: https://audio.com/dylan-nicholson-1/audio/slur-test) Even better, with a tiny tweak to the code in musesamplersequencer.cpp you can get this for Muse Sounds too! Proof here: https://musescore.com/user/7209246/scores/20014687/s/vjgpvP |
Your idea
Add a way to split chords into voices for playback purposes without separating them visually
This could mostly be done automatically by just assigning all the top notes to voice 1, the notes below that to 2 and so on. This automatic mode could maybe be applied using an "interpret chords as melodies" sound flag (similar to "classical phrasing" on brass, which as I understand it isn't triggering a different sound but a different way of interpreting the written notes)
Problem to be solved
The playback of wind/brass/voice chords (and maybe string divisi) can sound quite different if the chords are written in one voice or split up into single note melodies in separate voices, but doing that can become messy and take up more space than is necessary
This is the same problem as #15969
Prior art
No response
Additional context
My current workaround has been to split the chords into voices and make all the stems go the same direction so it looks like nothing has changed
Another solution could be to have another staff for playback that will be invisible in the final score. Both solutions require extra work to get Muse Sounds to give its best result, which is worth it but could be made easier
Checklist
The text was updated successfully, but these errors were encountered: