hitting the assigned Hot Key during playback should restart the cue

There are two ways this request could be interpretted:

1) The cue is stopped, and then restarted

2) Another copy of the cue is played (as in ticket #44)

Number two can't be done, for the reasons give in ticket #44.

Number one can technically be done, but it mixes functionality in a way that can lead to unexpected behavior. For example, if a hotkey stops the cue and then restarts it, hotkeys that are assigned to groups or cue lists will stop every cue in the group before firing it again. I think this is usually not the desired behavior, but it couldn't be changed by the designer.

On the other hand, if you have a hotkey that *only* starts cues, you can recreate the stop/start functionality by building it as a cuelist with a sequence like:

1 - Sound Cue,
2 - Stop Cue (targets 1), autocontinues
3 - Goto Cue (targets 1), autocontinues

and assign your hotkey to the list. Then every time you hit the hotkey, the sound would be stopped and restarted.

Thoughts?

The biggest drawback I can think of is that if you need this behavior for many cues, you'd need a lot of separate cue lists. Which would probably feel cluttered.

This may indicate that we need a new kind of cue, or an option on an existing cue. (The Group or Start cues, specifically.)

The more I think about it, the more I think the solution is to add an option to Group Cues, like so:

Add a checkbox for all Group Cues, labeled something like "Sub-list". When this is checked, a Group Cue behaves as a miniature cue list. Firing the group advances the position of a local playback position for the group.

In the context of the cue list this thing is in, the playback would alter in the sense that playback would no longer go "into" the group, but would just fire the group from the "outside" and proceed to the next cue after the group.

This way the power of the Group Cue could be fully realized, to allow one cue to more fully represent a complex set of individual actions that can be fired more independently than is currently possible. (Right now, a Group Cue hides details more than it actually represents a fully composite set of actions...)

The drawback of this would be that it would not be clear where the current playback position of the Group Cue was, if it was behaving as a sub-list. I'd need to find some way to indicate to the user which cue is going to be fired when the group is fired.

I've made the modifications described above to the Group Cue, so you can now make a proper sub-list that tracks an internal state. It will be available in the next release.