A way to specify that playback should stop at section breaks
In my accessibility work, I have become aware that it would be useful to be able to force MuseScore to stop playback rather than merely pause at section breaks. This would help ensure that blind users don't miss text frames containing important information about the next section. I would want this when creating accessibile educational materials.
Not sure the best way to do this. One way is probably a property on the section break itself. Right now we have a "pause" (in seconds). I propose also adding an option to stop. Perhaps adding radio buttons pause / stop, and then the current spin box only being enabled is "pause" is selected (and it would remain so by default for compatibility). Another would be a style option that would affect all breaks.
The downside of this approach is then a score created with that option enabled would stop for all users. Not a bad thing for my use case, since my intended usage is for creating entirely separate passages that sighted users should not play straight through either. So I could see also/instead a program preference for this, if this turns out to be an issue for people.
Thoughts?
Comments
I think that, doing full-stop at the section-break may cause some problems.
Suppose that the "Stop" option is added to the section-break properties (on the right-click pop-up menu).
We played the piece and the software stopped after to this measure.
How to resume playing?
Proposal:
In order to continue playing, an (internal) command such as "standby" or "suspend" should be applied instead of "full-stop".
in this instance, software waits for the user's next action.:
If the play command is executed again without further action, It continues to play from the next measure.
If the user selects something (or click somewhere) in the score, the real "Stop" command should only be activated in this case.
Reason:
Da-Capo, Segno and similar repeat operations are already problematic. Performing a full-stop here can result in many other repeat/playback problems that are not expected.
In other words, while trying to give a feature to the software, it is important not to break of the other features that are already barely working.
In reply to I think that doing Full-Stop… by Ziya Mete Demircan
Well, I'd have suggested that simply hitting "Space" would resume playback at the next measure.
Having the problem wait for user input doesn't seem like a good to me, how would the user (especially if blind) know that this was the case? They would probably expect to just be able to resume using MuseScore normally.
I can't imagine using this new proposed feature in a situation where I had any reason to worry about things like Da Capo. It really would be just things like separating one four-bar musical example in a theory handout from the next.
In reply to Well, I'd have suggested… by Marc Sabatella
You wanted to get thoughts, so I gave you one :)
It is up to you to evaluate, decide and implement (Or you may not even consider it).
In reply to I think that doing Full-Stop… by Ziya Mete Demircan
I don't understand any of your objection to the proposal of Marc. Playback would just be (optionally!) stopped at section break and pressing "play" would continue to play where it has stopped, what could be wrong with that ?
In reply to I don't understand any of… by frfancha
Well, like he said, it's a thought -), and worth thinking.
As far as I can tell, if the playback continued from there on the next press of "Space", it would be exactly the same as what was being suggested of a "standby" mode, except for the special case of repeats (including repeat barlines and also DS/Segno/Coda). Because stopping and restarting resets the repeat counter, the results would potentially differ between merely pausing versus stopping if it occurs in the middle of a repeated section. But I'm not sure repeat behaviors are intended to be meaningful or well-defined across section breaks anyhow, and certainly, I wouldn't be using these breaks in such a context.
I'm still interested to hear if others might have a use case I haven't considered, one that might suggest a different approach to the problem.
In reply to I don't understand any of… by frfancha
@frfancha
If you try to stop and play again in the middle of any repetition, you may have noticed that the repetition of that part is played as if it were playing for the first time.
My concern here is the necessity to use a soft-stop (pause, suspend) instead of a hard-stop.
In addition, section-breaks are currently being used as a workaround to control volta-repeats after DS and DC.
Consider placing a DC-repetition at the end of a score that consists of several sections and includes many section-breaks. (eg: medleys)
I have no objection to anything.
And these are just thoughts on the subject.
I had been thinking about a similar function, (though for different purposes) and may have suggested it here, but I can't be sure I actually hit send on the post.
My thought at the time was in terms of theatre music where the music stops for an unspecified time at a caesura, and proceeds after a cue from the actors, stage, lights, etc. The idea was that the play clock would stop when playback reaches a caesura which has such a condition set, and not resume until it receives input from the user. You could set it so that once playback is suspended, any key press will continue playback. The reason for "any key" (where's the "any" key?) is that I know how difficult it is to switch musical gears in mid-performance to find a specific key - even something as prominent as a spacebar - on a computer when you have other things happening at the same time. Bashing the wrong key mid-performance could have disastrous consequences to the playback of a score.
Now that I think more on it, it seems there was some small discussion of the matter, but it was considered either not workable at the time, or superfluous to other time functions in the program.
In reply to I had been thinking about a… by toffle
I vaguely recall that discussion, but not any specifics. It does seem a bit specialized, but in the context of what I'm talking about here, I could see it fitting in. Like, a third radio button for "continue on cue".
In reply to I vaguely recall that… by Marc Sabatella
The specifics of that discussion are lost in a fog of time, but it would be great if such a feature could be added. It would, of course be dependent on your ability to preserve the play count of repeated sections. I was unaware (though it seems obvious enough now) of how much is re-set when you stop the play clock. I do recommend the "hit any key to resume" option.
In reply to The specifics of that… by toffle
The discussion as I remember it centered on waiting for MIDI input, which is one reason it seemed a bit esoteric.
How about allowing and interpreting a negative pause duration to mean "stop playback"?
In reply to How about allowing and… by Jojo-Schmitz
The hacker in me is fine with that, the usability proponent less so :-) Internally I could still imagine implementing it that way - but then the possible "wait for user input" feedback would need additional consideration.
In reply to The hacker in me is fine… by Marc Sabatella
It could a quite easy fix that way, and a UI may even hide this.
Hmm, I just tried something with
QRadioButton
s (incidently I've been playing with that code the past couple hours, trying to move the section break properties into the Inspector): those don't seem to work in Inspector?In reply to It could a quite easy fix… by Jojo-Schmitz
Adding support for
QRadioButton
in Inspector seems a quite easy 2*2 lines code addition and one line change.How about this UI?
In reply to Adding support for… by Jojo-Schmitz
Nice! Does this solve the issue of resetting the play count if the break is within a repeated section?
In reply to Nice! Does this solve the… by toffle
No idea. So far there's just that UI, no real functionalty behind it yet
In reply to Nice! Does this solve the… by toffle
To me it's still a non-problem - I haven't heard anyone suggest a real-world use case where anyone would think to use this feature in the middle of a repeated section.
I would guess that hooking some functionality up to that radio button wouldn't be hard, but I know very little about how that aspect of the playback code works. Best I an tell if it would be something to set up in the tempo map, which is where the pauses are currently inserted. But I don't see where that value gets used.
In reply to To me it's still a non… by Marc Sabatella
Yep, tempo map, just not sure that has the capability to stop playback altogether
In reply to Yep, tempo map, just not… by Jojo-Schmitz
Probably not currently. I would guess it would be easy to add (although I could be wrong), just add such a property to tempo map, find the place where we actually use pause value the when rendering the MIDI, and add a check for the stop property and issue a stop command instead. But I'm not finding the palce where this information is actually used currently.
In reply to Probably not currently. I… by Marc Sabatella
Developer side-note; be aware that for fixing the pause-on-repeat I play with the idea of adding/pointing to the relevant pause property from a RepeatSegment during the unwinding process.
In reply to Developer side-note; be… by jeetee
And hopefully, this process doesn't affect a process that we have implemented as a workaround for an existing bug.
Examples added.
1- buggy
2. applied workaround.
In reply to And hopefully, this process… by Ziya Mete Demircan
Well, no one would force you to use the proposed new "stop at section breaks" feature, so absolutely, it doesn't affect any process if you don't use the feature.
In reply to Well, no one would force you… by Marc Sabatella
I hope my concerns are absurdly pointless and everything works as it should. ;)
In reply to Well, no one would force you… by Marc Sabatella
Wondering out loud how this could affect rendering mp3s?
Obviously, (?) this is not a function which could be embedded in a sound file, so "pause until input" would have to be replaced with a timed gap in playback. (Which is what we currently do with breath marks and caesurae)
In reply to Wondering out loud how this… by toffle
Good point, and excludes the option to use a negative pause value for this
Or maybe not, 3 means 3 seconds pause, -3 means stop on playback but 3 seconds pause on audio export