Another amount of CUEs bugs
Posted: 30 Jul 2009, 11:55
[The message from BugReport Form]
I often use only a one CUE. But using it is like a pain in ass!
First of all - CUE-list haven't to use LTP or HTP priority on channels - it has to have ascending priority - the highest number has highest priority (I mean 20 seq in CUE will be highest one) (it seems to me it have been realized in previous versions).
The second - CUE-list must to trace what seq goes on or off and return to the prev state of playback with all enabled seq's. Now it happens only when working seq switches to another step.
And there is a whole headache with indicators of seq's are ON - enabling or disabling one could dim playback indicator for all enabled seq's in CUE (but they are playing!).
And WHY enabling the seq in Cue switch it to a near step, when I only wants to play CURRENT step of seq?
(Looks like the program code of CUE-list should be revised and maybe it should use some kind of refresh time to trace the DMX output from current CUE-list state, IMHO
)
I often use only a one CUE. But using it is like a pain in ass!
First of all - CUE-list haven't to use LTP or HTP priority on channels - it has to have ascending priority - the highest number has highest priority (I mean 20 seq in CUE will be highest one) (it seems to me it have been realized in previous versions).
The second - CUE-list must to trace what seq goes on or off and return to the prev state of playback with all enabled seq's. Now it happens only when working seq switches to another step.
And there is a whole headache with indicators of seq's are ON - enabling or disabling one could dim playback indicator for all enabled seq's in CUE (but they are playing!).
And WHY enabling the seq in Cue switch it to a near step, when I only wants to play CURRENT step of seq?
(Looks like the program code of CUE-list should be revised and maybe it should use some kind of refresh time to trace the DMX output from current CUE-list state, IMHO
)