Tracking data

you can use "que only" in the quelist-option, but then it works for all que's in that list...

Does not address this issue sadly, although clearly a well used and valuable option in other programming situations.

Ross

I've also run into this when I want to create a 'rig check' Q before my show's Q stack. Making your 1st Q a block Q is the only way I can think of getting around it, which I agree is a bit of a pain. I'd much prefer for it not to track through like Ross suggests.

maybe use the "release on end"-option?

Again this does not remedy the issue. It's unfortunate as I rely heavily on this method for my personal style of programming/reheasing shows.

Ross

Ross

I must say this bugs me also... HES should put more resources fixing tracking issues and also the really annoying timing bug. It's a bit shame that one of the top consoles have this kind of bugs with tracking and timing.

1) the bug Ross mentioned
2) add a new channel to cue using merge or update and using cue only. Cue only adds off value to next cue and the timing is showing default timing instead cue timing in the cue editor, but it doesn't fade using that time.
3) The difference between H3 Cue only option and H2 maintain state. In H3 channels are released using release time not faded using cue timing.
4)Difference in backtracking when using merge and update with cue only...the way update works is so totally wrong. Cue only is done in the wrong place. It seems that nothing is updated in the cue you are updating, but the value which is the source of tracking is changed and reverted back to original right in the next cue...the result is that you changed a value for example 10 cues back, but the cue you updated didn't change.
5) bug #11682

The timing issue you mention Sami frustrates me greatly also. However I have never found a reliable way to repro it. It appears that in some specific undeterminable cases the timing adopted is the default or tracked parameter one and one not the current cue global timing, effectively splitting the cue times, and yet on other occasions using the same keystrokes the global cue time remains in tact. I see this happening over and over again but cannot create a consistent reproduction.

Ross

Ross,

See also forums.highend.com/showthread.php?t=6111&highlight=bug+%2311682

They know what is wrong and the fix is coming, but progress has been a bit slow....they have also a kind of timing bug :)

I see it. I think I remember logging some of this before also a way back.

Ross

Brad could tell what is the current timeline for fixing these bugs. IMO, timing bugs should be fixed as soon as possible. Also the merge/update issue in backtracking is very annoying. It can cause very confusing things to happen.
The way cuelist Cue only option works now, I can live with that, but I know a few programmers who have been a bit confused when trying to figure out what's wrong with their chase timing.

Sami,

The timing bugs are of course very important and we are planning to solve them as soon as possible. I do not have an exact time to post, but it will be as soon as we can.

thanks for your understanding,

Thanks Brad,

I think, many theater operators/programmers will be very happy when that happens.

Keep up the good work!