Suggestion: "Wait for input"
I see in v2.0 the is a way to "stretch" time to better handle fermatas. That is welcome.
Would it be possible to add a way to pause (during play of course) indefinitely at some score point until some keyboard or mouse (or tablet touchscreen) input were received and then proceed?
i imagine a performance situation like this... Suppose you're playing an instrument, accompanied by a MuseScore piano arrangement. Your instrument requires both hands but you have your keyboard or mouse situated down by your foot or elbow.
You're playing along until you encounter a fermata. The score pauses while you do your dramatically long note or cadenza and then resumes with the next note in the score when you tap the keyboard with your foot or elbow.
There would need to be a way to distinguish between circumstances where a note is held indefinitely and circumstances where a note expires and then the gap between it and the next note is really what is extended.
Perhaps these two versions would handle it...
Wait on Start: a note is started but time does not proceed until an input is received. If we applied this feature to a whole note, for example, the whole note would begin normally when it was encountered but time would stop and it would continue playing. On 'input," time would start again as it were resuming at the start of that note (without actually re-articulating it).
Wait Before Start: MuseScore plays everything prior to the note, but pauses to wait for input before resuming time with that note and continuing on.
Comments
FWIW, while not out of the question for MuseScore, this seems much more appropriate for the mobile apps, which are more geared toward play-along use cases.
In reply to FWIW, while not out of the by Marc Sabatella
In my case, I practice at home and not on the bus. :D
By "mobile apps" you mean iPad and Android versions of MuseScore?
I don't have either of those devices but from what i read, they are "Play only" with no creation or editing features.
Wouldn't you need to have this feature in the "desktop" version anyway to create scores with it that would be used in the mobile versions?
In reply to In my case, I practice at by robert.holmen.7
Correct. The model is, you create with the desktop software, with playback features designed to help you create scores, make demos of them, etc. But for dedicate play-along purposes, the mobile (Android & iOS) apps are trying to be focused on that use case, which is really quite different.
In reply to Correct. The model is, you by Marc Sabatella
"But for dedicate play-along purposes, the mobile (Android & iOS) apps are trying to be focused on that use case, which is really quite different."
I'm not sure i understand the argument.
I understand that people use mobile devices differently than desktop ones, but since you can't create scores in the mobile version, a feature like this would HAVE to exist in the desktop version it if is going to exist in the mobile version.
I don't understand how the mobile apps' different "focus" would make it possible for them to develop such a feature without it being developed in the desktop version.
In reply to "But for dedicate play-along by robert.holmen.7
Why would you think some particular playback feature that is not relevant at all to the process of *creating* a score, only to the process of *playing along with* a score, would "have to" exist in the desktop software? The two applications are very distinct, not just two different user interfaces to the same software. What they are in common is the core code to display a score on screen, and that's about it. So any code added to make a score *display* differently would indeed be added to both at once by default. But any code added to support a particular playback feature like this would need to be added twice - one in MuseScore, once in the mobile app - and it's just not *needed* by most users of the desktop software, who are by definition more focused on creaitng scores, not playing along with them.
Again, I'm not saying such a feature couldn't be added, but it still seems a much more natural fit for the mobile apps, and as such I feel would make sense to add there first, as this could actually be an important feature for many users of that app. For MuseScore itself (the desktop application), it would probably not be of interest to nearly as high a percentage of users.