Printable View
Tested with 3.3h24 but probably same in all builds.
Cue 1: playfwd inframe 1 outframe 301
Cue 2: playfwd inframe 302 outframe 600
Cues 1 and 2 only execute correctly once.
Cue 1 will not execute correctly after cue2.
Catalyst is very naughty! On basic stuff like this it should do what it's told. :)
Yea, 4.02m40 is the same.Quote:
Originally Posted by micpool@mac.com
It seems to check whether the current frame is >= to endframe before it goes to the inframe which, obviously, is not whats required
Mic,
I've checked this through, and you're right - if you run through the sequence once, and go back to the beginning, then the first sequence gets stuck.
May I suggest a workaround?
Put in a setup cue that sends the library or file parameters to look in to space for a fraction of a second and then go back to the cue 1.
So you could have:
Cue 1 - Setup cue - file/ or library look into space
Very short wait time to:
Cue 2 - The first sequence
Cue 3 - Second sequence
So Cue 2 has a v. short wait time.
See if that helps.
Best wishes,
Hugh
it is NOT a bug.
its a console programming/operating decision.
you need to program
playfwd
then inframe
then playforward.
OR - you use the "playfwd - retrigger >0" playmode.
if you use this rather than playfwd- you explicitly retrigger the inframe and outframe values - by moving the intensity to zero ( 0% ) then back to 100%
i believe this is to do with the modal behaviour of playmodes - and non-interlocked behaviour from consoles.
once the clip has stopped - it is only restarted if the playmode is changed -
the play channel has a priority over the inframe and outframe channels.
Changing inframe and outframe - do NOT cause the loop to retrigger.
i believed this is the safest way to operate under a broad range of circumstances.
And as this behaviour is now programmed into lots of shows - it cannot be changed.
It is analogous to how you would have to operate a tape deck or video player.
This isn't true for all circumstances. In the example I gave play stopped at frame 301. Changing the inframe and outframe as I described (i.e without changing the playmode) does restart the clip-as long as the new inframe is higher than the old out frame.Quote:
Originally Posted by samsc
the reason it stops and doesnt start in your example -Quote:
It seems to check whether the current frame is >= to endframe before it goes to the inframe which, obviously, is not whats required
at the end of CUE 2 - the current frame is 600.
the next cue ( CUE 1 ) has inframe 1 outframe 301.
as this is playing forwards in ONCE mode - the possible next possible inframe/outframe must be larger than current frame - it isnt. so nothing happens.
this is correct behaviour.
playforward DOES NOT Retrigger - and you have programmed a cue that has a inframe/outframe range that would stop the cue anyway ( if the current frame was anywhere after the outframe of cue 1 ) ...without an explicit goto frame command.
( lighting consoles have no notion of 'current frame' - if they did - then maybe just maybe it might be possible to do something a bit cleverer )
---
you need to be more explicit in the behaviour you require by programming an additional cue with either inframe or an intensity change and use the retrigger playmode.
---
i could add an extra playmode which explicitly retriggered when the inframe or outframe values were changed.
Quote:
Originally Posted by samsc
Thanks, I would find that very useful. ( And an audio version?)
OK but that won't work for playaudio at the moment because it wont go to inframe after play. (See my other bug report)Quote:
Originally Posted by samsc