Yea, 4.02m40 is the same.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
Yea, 4.02m40 is the same.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
Best Regards
Mic Pool
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.Originally Posted by samsc
Best Regards
Mic Pool
the reason it stops and doesnt start in your example -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.
Originally Posted by samsc
Thanks, I would find that very useful. ( And an audio version?)
Best Regards
Mic Pool
OK but that won't work for playaudio at the moment because it wont go to inframe after play. (See my other bug report)Originally Posted by samsc
Best Regards
Mic Pool