The joy of FX.....

I think that's an interesting idea. The effects functionality on Eos is very powerful, but can be confusing for occasional users who rarely need to delve into that part of the console. The ability to set up a simple step effect and record steps to it in the same way that other targets are recorded (RECORD EFFECT 2.3, for example, to record all manual channels into step 3 of effect 2, with a combination of time parameters on the end of the command line if required).

Not quite sure how practical this is, though ...

Have you tried building a secondary q-list to be your effect?  If you link the last Q to the first Q and use Follow times for everything it will allow you to create effects exactly like you build cues.

In the end it's probably more complicated than a step effect - but it can be a useful technique to have in your back pocket.

Hi Patrick, I think you misunderstand me.

I know how I would make cues behave like a chase using follows and links, as that is indeed the very point I am making.

As we are all familiar with this syntax, I am asking if it is possible for us to use these commands to make an effect, as these commands are familiar to us all.

ie I am much more comfortable with what Time, Delay, Hang etc will do to a sequence of cues than I am with what Dwell, Decays, Steptime, Cascades and Trails will do to a sequence of steps.

So rather than choosing to make an absolute, relative or step effect, I'm suggesting we also have another option; a cue-step effect, if you will! This would then be run from your cue stack as normal.

The step effect names have been with ETC consoles for decades.  I appreciate they are different than the Q names - but they have been around forever.

For relative and Absolute effects - the functions serve different purposes.  So for "Delay" - are we talking about the delay that the next set of channels waits before entering a step? (Trail) - or is it the time that the current set of channels waits before moving on to the next step (Dwell)

There is probably some name consolidation that could occur - but I think when you really tease it all apart you see that they are different functions from a traditional Q-List.

The Cue-Step Effect idea is interesting.  Would you propose building a chase Q stack like you normally would and then apply it to a selection of channels in the main Q stack? 

It is interesting because that would be a way to selectively apply Q information to a group of channels. 

Just curious.

Yes, you're right, I wouldn't want to change the existing options as they do their thing well. I'm only wondering if an additional option would be good.

How I would apply my notional cue-step effect though is a very good question! And I don't really have a good answer. I assume it would be as you suggest.

This just comes from needing to run a bunch of cues together for a theatrical rather than rock and roll effect, and having them run irrespective of subsequent pushes of the go button. For example, I just had a show where an oil lamp needed to slowly fade down to a point, sputter a bit, then continue to slowly fade out. I initially programmed it into the cue stack as a long slow fade, a few snappy follows jumping the level up and down, followed by another long slow fade. Simples. Then I'm torn because there is now another cue in the middle of all this (at a random point whenever the actor enters) which will of course foul up my carefully timed follows, so a single cycle chase is the obvious choice.

Now, obviously this is a very simple example, but the point stands that these are a bunch of very dull, theatrical and individual cues that don't really need the power of the existing effects options which are more designed for fancy chases from banks of PARcans etc. In the pressure of a tech, I think an average programmer chap like myself would be much more comfortable programming a sequence like this in the language of cues rather than chases? 

Or maybe I'm just too thick for this!?

it's always simple to say "i would have..." when you haven't been actually around, but i guess, i would have tried this with on slow fading cue with a curve. and provided you work in Tracking mode and be careful about move instructions and about not asserting, you could have had this cue inbetween at any point you wanted to without interrupting your curved fadeout...

Blimey, a curve! I've not done a lot with curves, but now you say it it is clearly a very smart path to take. 

However, while it is a solution for that specific problem (and I'm definitely going to do some home work on how exactly I would implement such a curve), I don't think it solves my main quandary, the problem of how an average programmer knocks it out quickly and confidently, as again it is a feature that some people use very rarely and that requires you to programme in a different way, rather than using exactly the same commands people are already familiar with. 

I feel I'm starting to sound like I'm arguing for people to not learn the desk better, that isn't my intention, it is more that this feels like an area that is a steep learning curve for a lot of new programmers and it feels to me that could be a little less steep if they got to use a framework they are already familiar with? And therefore springboard into the more traditional effects as they start to run into the limitations that this style would bring?

For your oil lamp example, with an intermediary cue:

You could build the cue sequence on a secondary cue list (triggered from the primary), and as long as the intermediary cue doesn't have a command for the oil lamp, the sequence will run without interruption.

Or, you could build the sequence in your main list using follow times of 0, and delays on each cue.  That way all of the cues get loaded immediately, and you can execute your intermediary cue with no problem.

There are probably a million other ways to do this too... I'm always learning new things lurking around here.

Happy cuing,

~P