pizzicato sound does not stop (on non-string instruments)
In Musescore 2 and 3 I could add the terms "pizz." and "arco" from the text palette and it would not affect how the notes sounded, with an instrument that is not a string instrument. I use it with accordion for instance.
In Musescore 4 if I place "pizz." above a note it will continue to sound forever. That's not what pizzicato should mean.
I know that an accordion has no real pizzicato but the term is often used in accordion scores to indicate decaying notes (simulating a real pizzicato).
I know that I can just place the text "pizz." as staff text and then it has no effect, but I'd like all my previous scores where I did use the predefined "pizz." element to not be broken...
Comments
The "pizz" text is not meant to be used on instruments that do not support it. While it's certainly possible that a special auto-correct could someday be added to fix older scores that used the original pizz marking inappropriately, realistically, you'd be better off just fixing them. But also, feel free should open an issue on GitHub requesting this new auto-correct feature.
In reply to The "pizz" text is not meant… by Marc Sabatella
It might be as easy as adding a Pizzicato section (doing basically nothing but ignoring it) to .../src/framework/mpe/resources/general_voice_articulations_profile.json
In reply to The "pizz" text is not meant… by Marc Sabatella
The easiest thing would be to have pizz and arco just do nothing on non-string instruments, like it did in Musescore 2 and 3.
The problem now is that if in a whole measure there is a short pizzicato note followed by only rests the pizzicato note will continue to sound forever, not just the whole measures but the whole length of the music piece. I'm not expecting a fix where a "pseudo pizzicato" effect is generated for instruments like an accordion. I'm only expecting the note to stop when it should stop (if there was no pizzicato). Musescore 2 and 3 did this correctly, so how hard can it be to make Musescore 4 simply copy the old behavior of making the note stop?
In reply to The easiest thing would be… by pauldebra
Of course. I meant the easiest way to achieve this might be what I described
In reply to Of course. I meant the… by Jojo-Schmitz
I understand.
I am temporarily going to do what I find the easiest way: go back to Musescore 3 until most screw-ups in Musescore 4 might get fixed. In my previous life I was a professor in computer science and taught my students what to do and what to avoid when updating user interfaces... I would have love to have Musescore 4 at the time to give them more examples of what they should never do...
In reply to I understand. I am… by pauldebra
Far easier: don't use pizz on non-string instruments
In reply to Far easier: don't use pizz… by Jojo-Schmitz
You are right about that. But as I am making lots of arrangements of classical and baroque music for accordion ensembles, the terms pizzicato and arco are use a lot in this type of arrangements (by every arranger, not just by me) and students also learn how to simulate the pizzicato effect on the accordion.
Of course I can just replace these meaningful terms by plain (staff) text.
Another thing I have learned in the past is to avoid software versions with a 0 in them. Musescore is now at 4.0.0, so that should have been a clear warning, and I ignored it and am now sorry I did...
In reply to You are right about that… by pauldebra
No, it is at 4.0.1, since some 6 weeks. 4.0.2 being imminent
In reply to No, it is at 4.0.1, since… by Jojo-Schmitz
Thanks for the tip. Sadly that update appears to still have the same bahavior (not only with pizzicato but also other things like palettes not opening on startup). I will simply wait a while until there is no more 0 in the version number.
In reply to I understand. I am… by pauldebra
Hopefully you also taught your students the importance of participating in public beta programs for open source software to provide feedback so you can help identify issues before release, and the importance of reporting issues you find during the beta and afterwards to developers so they can be fixed.
Anyhow, looks like this particular one is now understood, it's really something that it was never expected anyone would ever try to do which is why none of the people who did volunteer to beta test found and reported it. Would have been great to have had your input then, but it's not too late for further input. If there is some other issue you've identified that you are needing to see a fix for, be sure to open GitHub issues for them.
In reply to Hopefully you also taught… by Marc Sabatella
ISTR to have seen this been reported before
In reply to Hopefully you also taught… by Marc Sabatella
I did teach my students very explicitly about the importance of thorough (beta) testing. I also taught them that a release version is not intended for further testing but should really be finished.
I am now retired as a computer scientist and am just a musician using the software for making arrangements. I was hoping that testing before the release were more thorough, especially to make sure that everything that used to work in the previous release version would still work in the next release version. Alas, it wasn't to be...
The point about not using a version with a 0 in it is very well known in the computer science scene even though it shouldn't be. With Windows people were even joking that as Windows 10 had a 0 in the "major" release number it was double trouble with 10.0 came out...
I'm not complaining, especially about free software. It's just a pity that every new version requires a lot of re-learning by the end-users. But before Musescore I used Capella and that wasn't better, not just in reliability but also in unwanted changes when introducing new versions...
In reply to I did teach my students very… by pauldebra
Given your background, I'm sure you realize you misspoke in saying software should be "finished" before release - if that were the criteria, not a single piece of software more complex than "hello world" would ever have been released :-)
Anyhow, testing was as thorough as the other volunteers who participated made it. Making sure that literally nothing at all was broken - again, someone with your experience should realize this has never once happened in the entire course of history. During a beta, bugs are found and fixed, and the software is released when it seems there is nothing critical left. But it's of course a given that "0" in the name or not, bugs will remain to be found and fixed in future updates, which is why the testing and development never ends, and indeed is called a "cycle" for a reason.
In reply to The "pizz" text is not meant… by Marc Sabatella
See https://github.com/musescore/MuseScore/issues/16684