Things in MuseScore that should be developed
This is a feedback so that the MuseScore team can make MuseScore 2.0 stable version the best, most professional and easiest to use composing programme ever existed.
First of all, I will start with the biggest problem, in my opinion. MuseScore cannot playback trills and some other ornaments, such as gruppeto and some pralls-mordents. Furthermore, It cannot playback glissando, pizzicato and snap pizzicato as well. In addition, when you add crescendo or diminuendo, it does not increase and decrease the note played, as it should.
Lastly, there are some tempo issues. First of all, there's no availability of acceleration and decleration signs. I am already aware that you can fake it with tempo marks but it would be better, easier and more accurate to create an "acceleration and decleration pallete" including those symbols. And the second of the tempo issues is fermata playback. All kind of fermatas can't be accurately playbacked. Informativelly the original fermata doubles the note duration, the long fermata quadruples the note duration, the very long fermata octuples the note duration and the short fermata is like a dotted note.
Comments
Thank you for the interesting information.
Regards,
Thanks for your suggestions. Do keep in mind the primary purpose of MuseScore is *notation*, not playback. So playback enhancements are always lower priority than core notation features. That is, it is much more important that trills, crescendos, and other markings are *displayed and printed* as well as possible than that they playback. And huge amount of effort has gone into improving this for 2.0. Some effort did go into playback - some simple ornaments like mordents do now play, as do crescendo and diminuendo on a note-to-note basis (crescendo one a single note would require supporting MIDI features not currently implemented in the synthesizer). Anyhow, presumably by some future release, the notation features will have matured to the point where more effort can go into playback.
What are acceleration and deceleration signs? What symbols would a palette for acceleration and deceleration contain?
In reply to What are acceleration and by [DELETED] 448831
E.g. "rit." for ritardando
In reply to E.g. "rit." for ritardando by Jojo-Schmitz
Accel.
In reply to Accel. by xavierjazz
Well, yeah. :-) But those are neither signs nor symbols, so I wondered if the original poster had something else in mind. Until those terms can be applied with an actual functionality that's distinct from Staff Text or System Text, I can't see why they would be on a Palette - but I guess that's stating the obvious.
Are such plans actively in the works? To implement functional crescendos, diminuendos, accelerandos and ritardandos, that is?
I've been reading classical piano scores for about 55 years, and I thought I knew all the terms and symbols. I only entered this thread because I was curious if there was something I had missed - or if I just misinterpreted what was being asked.
In reply to Well, yeah. :-) by [DELETED] 448831
crescendo and diminuendo AKA hairpins do work already in 2.0 Beta 1
Well, not quite, they had been fixed to work properly in a later nightly build
In reply to crescendo and diminuendo AKA by Jojo-Schmitz
Oh, my bad. I had forgotten that, so thank you for the reminder!
In reply to Oh, my bad. I had forgotten by [DELETED] 448831
Still, crescendos don't work for single notes - you cannot crescendo through a whole note, for instance. But that's not going to happen for 2.0, since it would require a radical revamping of the playback architecture. Right now, volume is based entirely on the velocity of the MIDI "note on event"; there is no support for continuous controllers.
I think that adding support for this as well as slurs (which also would require extending the current architecture), trills, and more would make fine projects for some enterprising student for next year's Google Summer of Code, and hopefully make a 2.X release.
In reply to crescendo and diminuendo AKA by Jojo-Schmitz
#jojo-schmitz when will be that nightly build ready and is there any chance that my other requests will be fulfiled in another version or nightly build ?
In reply to #jojo-schmitz when will be by KostisP57
Nightly builds already have crescendo playback. As for ritardando, see my previous comments. Playback just isn't the focus of MuseScore. Some improvements have been made already, but I wouldn't be holding your breath for much more any time soon. The priorities for the immediate future are about stability, not additional features, and to the extent any additional features are likely for 2.0, again, improvements to notation come first.
In reply to Nightly builds already have by Marc Sabatella
I agree with you #Marc Sabatella but playback is as important as notation. I personally have a you tube that I upload sheet music of my adaptations and arrangements to some songs. And it's not only me. I've seen at least dozen of you tubers using musescore. It must have an accurate playback, in my opinion. By the way, I think notation is already higly improved. You must now focus on the tempo (acceleration, decleration and fermatas) and ornaments (trills, gruppeto, glissando, pizzicato and snap pizicato) accuracy in playback. I hope that MuseScore 2.0 stable version wil be released soon with all these impovements!!
P.S.: By "soon", I mean as soon as possible. I can wait for a year or so...!
In reply to I agree with you #Marc by KostisP57
With respect, KosrisP7, it was difficult for me - an end-user here just like you, by the way - to get beyond the first sentence of your comment. The idea that 'playback is as important as notation' may be true for you, but everyone does not share that opinion. There are many different reasons for using MuseScore, and we use it for different purposes. As regards playback, the developers have made it clear for years that, in their determination, the priority of the software is notation. That matter is for them to decide, not us.
Don't get me wrong: I am sure that suggestions and input are welcome, else forums like this one on the MuseScore website wouldn't be here. I am also reasonably sure, on the other hand, that outright demands - which is how your input here is presented - are inappropriate.
In particular, a statement that the development team 'must now focus' on x, y or z functionalities seems out of place to me. We don't get to make those determinations - and we absolutely have no control over the schedules of future releases or the specific functionalities they will offer. As they say, 'It is what it is.'
In reply to I agree with you #Marc by KostisP57
Again, while playback might be important to *some* users of MuseScore, it is always less important than notationm which is by definition trhe single most important thing to each and every user of a notation program. So yes, where it makes sense, we do try to improve playback, but it cannot come at the expense of notation. We want to release 2.0 as soon as possible - and we do *not* want to wait a year. So it will release when enough bugs have been fixed andf thye new notation features are finished, but there is no way the release should be held up to add more playback features. Too many people are depending on the notation features that are coming with 2.0 to hold up the release to add more playback features.
That said, sure, some day - maybe within a year for some features, maybe two or three for others - I wouldn't be surprised to see more playback features. But again, it is just not the focus. If you want more control oer playback, you can always export your score to MIDI and then do further processing in softrware whose primary purpose *is* playback.
"Rit" and "accel", btw, seem to me like they belong on the current Tempo palette - no need for a new one.
In reply to Again, while playback might by Marc Sabatella
Yes, "rit." and "accel." would belong to the Tempo palette, they are in fact Tempo texts, but it'd be great though if this would playback too, this would probably involve them being turned into spanners and have some kind of "Tempo change" to it (similar to hairpins and their "Velocity change."
In reply to Yes, "rit." and "accel." by Jojo-Schmitz
Yes, and in fact lasconic I just discussed this a couple of days ago. It's definitely on the radar. No idea if there is any chance of this going in for 2.0, but my point is, we aren't going to hold up the release of 2.0 for more playback features. It's already much improved as hasd been noted, and maybe some other improvements will yet slip in. The priority needs to be actually releasing 2.0, not putting it off another year to add playback support for every possible notation!
In reply to Again, while playback might by Marc Sabatella
Can I just add to that, Marc, that playback IS being worked on, it just has (quite rightly) a lesser focus then notation issues atm.
Igevorse has been working on improving the MIDI side of things since the summer, particularly making JACK work better with MuseScore, which makes the use of VSTs and external samplers or synths possible.
It is possible to direct the MIDI stream from MuseScore into an external sequencer where it can be manipulated in any way you wish.
You have direct control over both velocities and tempo within MuseScore itself, so there is very little that needs to be added unless you are wanting to use brass or string crescendos on the same note, which are easily added in a separate sequencer track, either in real-time or programmed.
This means there is very little you can't achieve in terms of score rendering to audio with MuseScore if you're prepared to work a little at it, instead of bitching about bad playback.
In reply to Well, yeah. :-) by [DELETED] 448831
#stevebob, I meant that there should be a palette with the tempo marks rit.,ritard.,accel. etc in order to be more acurate than fake accelerations and declarations...
In reply to Accel. by xavierjazz
indeed, for accelerando, the opposite of ritardando
They are tempo texts, sort of.
In reply to indeed, for accelerando, the by Jojo-Schmitz
A few weeks ago, I had also thought about tempo text for gradual differences.
My next thought is, how would it be handled for MusicXML? I know Finale tries to interpret such text, but that maybe application-specific - maybe this is something we can do?
Should it be plain text with special properties, or an actual tempo text with options (radio button or drop-down list)?
Another issue that I just faced is that the drumset editing changes to default every time I create a new score. Please fix that as well!! Thanks in advance.
In reply to Another issue that I just by KostisP57
Could you make a new forum topic for this so it will get the right attention? Thanks!
In reply to Another issue that I just by KostisP57
FWIW, this is not really a bug - just like changes to Style settings, changes to drum set are per score. This is a good thing generally - often you'd want different settings for different scores. For both drum sets and styles, you can save settings and load them into new scores, so you don't have to recreate things manually. Or you can save an empty score as a template then create new acores from that template, and they will get the drum set and style settings automatically. So you never need to start over defining your drum set.
Now, one opportunity for improvement would be for drum set settings to be saved as part of the style, so that if you specify a style to be the default (which you can do in Edit / Preferences), it will include the drum set settings. This could useful if you are really sure you pretty much always want to start off with the same settings even when starting "from scratch" as opposed to from a template. Or, we could add a default drum set option alongside the default style option.
But again, it's already quite possible to reuse a drum set definition. Templates in particular are really a great way to go about this and many other things where you know you want a bunch of different scores to share certain characteristics.
Hi, Mark.
I know it's been a while since you posted what I'm replying to, but it is a long-standing concern.
I am using Musescore 1.3, and no matter the search results from Google, fermatas seem to be entirely non-functional in my install. I have read that they can be double-clicked to configure them, but double-clicking them in my install yields nothing at all. The software just sits there. You can right-click it to get to the Articulation Properies dialog, and that shows text gadgets for entering information on Channel, and MIDI Action, but they are both empty, and I find no mention anywhere as to what to put in those gadgets. It is as if the fermata is visually connected, but not functionally connected. It would be nice to know what to enter into those text gadgets, or even whether they are functional at all.
Also, on MP3 export, it is said that if you want MP3 export, you need to tell the software where to find the added libraries, but I cannot find any way of doing that. If I were able to do that, with appropriate settings active, it would save me a step in my release process.
Thanks, Guys, for all you do.
In reply to Hi, Mark. I know it's been a by Billsey
Playback of fermatas is indeed not supported in 1.3; that's a feature that will be new with 2.0.
As for MP3 export, that also is not supported in 1.3, but will be in 2.0. It should find the libraries automatically if you have already installed them in the default location for Audacity. Otherwise, it will pop up a dialog asking you where you installed them.
In reply to Hi, Mark. I know it's been a by Billsey
Double click puts it into edit mode, here you can change it's position, using the cursor keys.
This is the same in 1.x and 2.0. Editing the time stretch is possible in 2.0, in Inspector
Please take a look at this forum post.
https://musescore.org/en/node/56281
Let me know you feedback about trills and other ornaments.