-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pressing Space at a running cue should not stop it. #219
Comments
I do not plan to change this default behavior, but, in the upcoming version, it's possible to change the default "stop" action as "do nothing" to prevent what you described (stop/pause buttons are not affected by this)
Yes, it's not explicitly stated in the documentation, it should be made more clear 👍 |
Is there a specific reason for not wanting to change this? To me the described issue seems to be a classic newbie pitfall. Changing the default "stop" action to prevent this sounds like a thing one would not do in the end after having already learned about this unexpecte behavior the hard way... I am sure the current behavior will almost always be discovered by mistake (even given the very recommended addition to the documentation). |
I don't get it. How could we stop a cue then? |
For unplanned emergency stops (which are the use case here) you would stop
either with a stop command that has been specified for the cue in its
settings, or using the global stop command that are supposed to be
mapped/mappable to a key shortcut in any version after 5.2-1.
Scrolling back to that cue number that you vaguely remember having
triggered the currently still playing cue and executing SPACE BAR on it
again is imho too much of a cognitive load for a quick emergency stop.
I think it is generally a bad idea to have the SPACE BAR work as a
global start OR stop key depending on which context you are in. Rather
have the SPACE bar start, and some other key like ESC stop.
I hope I could make this more clear now.
* clemradio ***@***.***> [2021-12-01 20:38]:
… I don't get it. How could we stop a cue then?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#219 (comment)
|
The main reason for this behavior is that it's what I need in most of the shows I run, where certain scenes cannot be timed precisely and manually pausing or stopping a track is necessary. Anyway I see your point, a different default might be more appropriate. I'll think about what to do. Obviously any feedback by others is appreciated. |
If the setting is changeable, it might be fine to alter the default. I also find myself having to stop a cue often, but when the default auto-advances, this is tricky anyway. And there were definitely shows where I accidentally stopped a running cue because I expected another one being selected :-( (But I didn't experience the newcomer problem, because I think I tested the software deeply before any show, so it was obvious to me how everything was supposed to work) Another good option would be to have a global stop-this-cue-key which is different, so "Play" will always play and e.g. "Escape" or "End" (= skip to end) will stop the current key. So you know that you can safely tap those keys without accidentally launching the next cue if it was auto selected. Also, a global stop-all might improve this situation. |
Speaking for myself (running shows off a modified version of the The only time I have to stop individual audio cues prematurely (and thus made use of the (That said: the default behaviour of audio cues in the Cart Layout - tap to start and tap to stop - does make sense IMO. But then that layout doesn't hardcode |
Presing at a re-selected and already running cue currently stops it in 0.5.1 (and possibly later versions). This is possibly undocumented behavior, should not happen, and can cause unwanted errors in shows.
The text was updated successfully, but these errors were encountered: