Strange dynamic behaviour regarding sfz marking

• Feb 10, 2021 - 15:29

In this selection, extracted from a score created under MS 3.02, the first note of M3 is marked sfz, followed by p on the second beat. The playback of the dynamics do not change, however, until the hidden p marking under the crescendo in M6. The first note of M7 is marked sfz, followed by mp. Once again, after the sfz, the playback volume does not appear to change.

My understanding of sfz is that it should apply only to a specific note or chord, not a series of notes.

If I remove the sfz, or if I place the p and mp markings on the third beat instead of beat 2, the dynamics are respected. This however also removes the desired effect in the music.

What am I doing wrong? (Yes, I know there is a sfp marking, but that is not technically a percussion dynamic, and would not help in the case of sfz followed by mp.)

Attachment Size
Drum dynamics.mscz 12.17 KB

Comments

Just a couple of observations following a few tests... MS does not appear to respect dynamic changes if they are inserted in the beat directly following any of the sf-family of markings. (sfz, sfp, rfz, etc.) Changes such as ff to pp, however, CAN be applied successfully to directly adjacent beats.

Technically, subsequent notes should not require a dynamic marking at all, as any notes following a sfz-marked note should play at the volume which preceded the sfz marking.

In reply to by toffle

Check the dynamic settings on your sfz marking in the inspector. It contains both the amount of velocity increase on the note of the marking as well as the decrease/restoration afterwards.
This definition "conflicts" with a dynamic on the next note.

I agree that it would make sense for the latter to "win" out in this scenario, but as it currently stands, your option is to alter the sfz setting so the resulting velocity level evaluates to that of the dynamic marking you inserted.

In reply to by jeetee

Thank you, Jeetee.

This provides a solution with considerable control over the final sound, though it is somewhat more labour-intensive than a literal interpretation of the musical effect should require. The score in question contains dozens of sfz markings, which must now be individually edited. It does not appear that I can save a preference in the inspector to save any time with this task.

I am still concerned over the conflict between markings in adjacent notes. If ff followed by pp functions on adjacent notes, then sf followed by any other dynamic marking should work as well.

In my training and experience, sf and other similar markings are applied to single notes or chords. It appears that in MS a different interpretation is applied.

In reply to by Marc Sabatella

I tried this earlier, but it didn't work, and tried it again after your suggestion, (in case I had done something out of sequence) but still no. I was really hoping that would do the trick, but I'm afraid it's down to Jeetee's solution for now, which is to set a negative value that will cancel out the sf velocity. I still think there's some odd behaviour there.

Is this a bug? What design purpose would it serve to not allow a dynamic change on adjacent beats?

In reply to by Marc Sabatella

Random would mean that statistically, I'd have a 50% chance of success, and that's not happening with setting the value to zero. (I just checked and re-checked to make sure I haven't been misinterpreting your suggestion.) In my case, I still have to enter a subtractive value that will bring the velocity back to my target dynamic. Perhaps there is something else which limiting my options here. I'm using the latest stable release on Windows 10.
The process I'm using is only slightly cumbersome, so apart from the small investment of time to achieve the desired result, it's not really an issue. Still, it's something to be noted.

In reply to by toffle

I know playback works by dividing the score into "chunks", so I suppose maybe it depends on whether this happens on a "chunk" boundary, or on some other factor. Or it could be that it goes through items that are in an unsorted list, and internally the libraries handling unsorted listed handle this differently depending on number of elements order in which they were added, etc. Lots of ways code could be written in a way the results are not deterministic, meaning it's not always the same for all case. All I know is I seem to see different results at different times I cannot explain.

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