Allow same cue to be played multiple times

Interesting idea. I'd like to think this one over a bit. One concern I have is that the behavior of complex cue sequences might become more difficult to decipher. This could especially be the case in the future when conditional cues (if, while) are added.

I guess I'm leary of breaking from the "simple pieces" approach. If each cue has at most one target, and each cue is doing at most one thing at a time, and each "domino" in each sequence of cues is unambiguously either stopped or in the process of running, my instinct is that this reduces the headache of picking apart complex sequences.

The issue of cue sequences is of particular interest to me. The current system is set up according to the "domino" philosophy. If two sequences of cues (two rows of dominoes) fire the same cue (meet together, like two rows of dominoes meeting at one domino), then the subsequent sequence of cues only falls once, as one row of physical dominoes would. I'll call this a "uniquely instantiated" cue sequence. On the other hand, if cues can be played multiple times, it's like you have an infinite number of copies of the same set of dominoes, and they all fall independently of each other. I'll call this a "polyinstantiated" cue sequence.

I'm sure there are both pros and cons to having polyinstantiated cue sequences vs. uniquely instantiated cue sequences. I suppose the important question is which is easier to use, and if one is more powerful than the other.

Boy, I hope that all makes sense; sorry if it is confusing.

There are definite benefits to either approach. The reason why I like my method is the following scenario:

Take a really silly sit-com play or something. Whenever something funny happens, you want to play a laugh track. The natural way to implement this would be to have a cue at the top, which immediately follows to the next cue, which does a "goto cue" to go back to the laugh track. Thus, sequential "Go"s fire the same top cue in the loop. In this situation, you want a second "go" on that cue to be a new instance. You don't want to have to put two copies of the cue to flip-flop between.

In most shows, this wouldn't happen anyway. But this way makes more sense in my head at least. Perhaps a preference? Too many preferences can be a bad thing, but I personally love to have a ton of preferences hidden away in an "Advanced" section for things like this (look at Adium for example, if you use that)

I'm certainly not averse to the idea of having it as a preference. All my philosophizing aside, the main stumbling block might turn out to be the technical challenge of adjusting how cues and the cue trigger mechanism behaves to allow this to happen.

I'll see if I can figure out how difficult it would be to implement this change, and in the meantime there's always the "make up a huge cue list of 700 copies of my laugh track cue with a goto at the bottom" to create the effectively unlimited repeat of the same sound. Not as pretty on the face of it, but maybe not so hard to get used to. At least while I figure out what might be done about doing it the other way....

Honestly, for times like this, I'd rather have a small built-in sampler rather than treating them like a proper playback cue. Each sample has its own matrix mix and amplitude envelope, as well as either MIDI or ASCII trigger.

If I remember correctly (this is how SFX v5.5 worked) when you retrigger a cue, it doesn't actually make it polyphonic, but it starts the cue over.

I've continued to think about this design problem quite a lot. I've come to believe that it would break the cue model to allow polyinstantiation of cue sequences. There are several examples of how this would break the workspace:

1) some choice would have to be made about which running copy of a cue should be affected by other cues. this could either be A) all copies B) the most recent copy C) the copy that was active when the affecting cue was triggered. Depending on the circumstances, any one of these choices might be the desired behavior. If there was some mechanism to set a preference about how any particular cue was treated, this would introduce a layer of obscurity in the construction of cue sequences, leading to user error and confusion.

2) polyinstantiating cue sequences would cause an exponential growth of running sequences for certain kinds of recursive cue sequences. The simple use of an auto-continued Goto Cue that loops back to the top of a sequence would create an explosion of running cues. This behavior would be an inherent part of the cue model and would allow users to easily create cue sequences that would have the effect of eating up all available memory and crashing their computer. In contrast, modeling cues as single, atomic actions (single dominoes in a chain that are either fallling or not falling) provides a built-in mechanism to prevent accidental recursive explosions.

In short, designing cues as single atomic actions (that are either running or not) increases both the clarity and stability of a workspace. Meanwhile, the *functionality* that would be bought by implementing polyinstantiated sequences can still be achieved (via other means) through the current design, so we aren't losing any power by avoiding polyinstantiation.

Thus, I will leave the design as-is, and focus on adding mechanisms to increase the usability/management of cues. In the case of wanting a sound to layer on top of itself multiple times, I would suggest that a composite cue is the right way to solve the problem:

Create a Cue List, which will represent the high level cue that, in your mind, is being played multiple times. Inside that Cue List place as many copies as necessary of the sound you wish to repeat. Put a Goto Cue at the bottom that points up to the top. Assign a hotkey to the cue list. Then, every time you hit the hotkey you'll get another copy of the sound playing.