Pressing Space at a running cue should not stop it.

[musger]

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.

[FrancescoCeruti]

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)

This is possibly undocumented behavior

Yes, it's not explicitly stated in the documentation, it should be made more clear :+1:

[musger]

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).

[clemradio]

I don't get it. How could we stop a cue then?

[musger]

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: https://github.com/FrancescoCeruti/linux-show-player/issues/219#issuecomment-983991771

[FrancescoCeruti]

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.

[fnetX]

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.

[s0600204]

Obviously any feedback by others is appreciated.

Speaking for myself (running shows off a modified version of the develop branch): I set the spacebar action to "Faded Start", and use Esc as a global faded interrupt and Shift+Esc as a global hard-stop.

The only time I have to stop individual audio cues prematurely (and thus made use of the spacebar-stops-a-running-cue behaviour) is during the design/setup period - if I know I have to stop specific cues during a performance then I'll add stop cues.

(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 spacebar as a keyboard shortcut.)