Trace, Trace

Steve, the double hit of trace to force channels not previously in use to trace was requested by a number of designers.  Here's the reason.  

a) You are mid scene and have made changes to channels that were already in use, and you have add a group of lights that were not previously in use - maybe because the action in the active cue spreads to DSL.   You don't want to trace ALL of those channels, just those that were already in use.  Via an update, though, you want to add the new lights to the active cue.   You could do this in two steps.  Find the lights already in use and via s selective command update trace enter.  Then update enter to deal with the new lights.   Lot of work though.  Or you could just update trace.  Channels previously in use will find their source cue.  New channels will only be added to the active cue.

b)  You are mid scene and have made changes to channels that were already in use, and you have added a group of lights that were not previously in use - maybe because the action in the active cue spreads to DSL.  Oh wait, that scene is being reblocked so you need those new lights through the entire scene.  Update trace trace enter.

:-)

The way a full block (or an I-Block) works has not changed in a really long time.  Channels that do not yet belong to the cue list do not appear with a white zero in the blocked cue.  However, you will notice if you add them later to an earlier cue, they WILL appear as a white zero in the blocked cue.    You don't want to block the ENTIRE rig, if those channels do not belong to the cue list in question, because that would result in erroneous reporting for channels in use, last used, and so forth ---- but if channels are added, they will be blocked appropriately.

Hope that helps.

a

Thanks Anne.

SB

Spurred on by Steves queries about Trace I thought I would look into the function I really don't use enough.

Am I doing something silly - I can't seem to get what i think [Trace] [Trace] should be doing to work.

Cue 1 - Channels 1 Thru 3 have no value.

Cue 10 - Channels 1 Thru 3 are set to Full

Working still in Cue 10 - [1] [Thru] [3] [Update] [Trace] [Trace] [Enter]

This should force the value of channels 1 thru 3 all the way back to Cue 1, as you would expect tracking to do forwards, but because of Trace, go backwards as well,  the only thing that would stop the trace, like tracking would be a Block.

It doesn't seem to be tracing back.

Sammy, I hate to ask the question, but is the - in your final syntax example a separator for your explanation or a - on the command line.  I assume the former?

Just tried your example and am not seeing any problems at all.  Those channels are tracing back as expected.

Pondering.

a

Thanks for the response,

I have no idea what I must have been doing as I checked it out again after you said it was working fine for you and it's working fine for me too.

Very strange but I can't seem to reproduce anything wierd again, so I blame the operator *points finger at himself*

Thanks very much.

Thanks for the response,

I have no idea what I must have been doing as I checked it out again after you said it was working fine for you and it's working fine for me too.

Very strange but I can't seem to reproduce anything wierd again, so I blame the operator *points finger at himself*

Thanks very much.

Ooo ok I think I found why I was having trouble.

Using my example from above:

Say in Cue 10 you've set channels [1] [Thru] [3] [@] [Full] and then [Update] [Enter]

You then realise "oh I wanted that to trace back too!"

I try each of these:

[1] [Thru] [3] [Update] [Trace] [Enter]

[1] [Thru] [3] [Update] [Trace] [Trace] [Enter] 

and maybe even try something like...

[1] [Thru] [3] [@] [Full] [Enter] [Select Last] [Update] [Trace] [Trace] [Enter]

None of these trace back the value.

The only work around would be:

[1] [Thru] [3] [@] [Enter] [Update] [Enter]

[1] [Thru] [3] [@] [X] [Update] [Trace] [Enter]

Sammy you should just be able to [undo] your update, which should restore those channels to their manual level, then do [update] {trace} [enter].

That true..

But say in a different scenario:

You were going through the show and you came across a channel you forgot to trace back perhaps yesterday (anytime that the undo feature is too far gone to use)

Is the only way to trace back to do?:

[1] [Thru] [3] [@] [Enter] [Update] [Enter]

[1] [Thru] [3] [@] [X] [Update] [Trace] [Trace] [Enter]

Did you try making them manual (using the make manual button)?  Since update only takes things that are manual?

Which is effectively what you did via the work around.

:-)

a

Hey Anne,

[Make Manual] doesn't seem to work. I've just been testing it out and it looks like you have to have the channels starting from a purple value.

Which is why I did [@][Enter][Update][Enter] and then [1][Thru][3] [@] [X] [Update] [Trace] [Trace] [Enter]

I would have expected that trace would have worked with a manual value, be it by doing [Make Manual] or just [Channel] [@] [X] [Enter]

Well, channels need to either have not been in use before (for trace trace to work) or they have to have been tracked (for trace to work) -  this is true.  If the channel is a move instruction is it considered the origin of the current value and will not track back into the previous cue.

a

I imagine {make manual} [Update] [last] [trace] [trace] would do the trick.  Essentially updating the move to the cue before, but going as far back as possible.

This does make me think Trace might be a useful addition to the Copy To command.

-Josh

That would work Josh, You would also have to finish it off with [Update] [Enter] though to update the cue you are in.

I would expect Anne though, that if you have made a channel manual and you purposely put on your syntax [Update] [Trace] or [Trace] [Trace], should it not do the job? 

Nope, not if the stored value in the active cue is change from the previous cue.  The status of the channel as manual or selected doesn't matter in that case.  Unless was is a completely new channel parameter, if the stored value is a move, it will not trace.  You have to think of trace as "go find the source (cue with the move) of the stored value for this parameter."  If the stored value that you have just manually overridden IS a move (change from previous), the current cue IS the source.

You can, though, do a range update, which will get you what you want.

:-)

a

Thanks Anne,

Thats a much better way of thinking about it,

rather than just thinking that its Tracking but backwards.