Cobalt Seq+/Seq- FCB delay

I haven't ever noticed the problem. I can't recreate it offline with v7.2
Seq + will run attributes at the default attribute time. You can change the default attribute time. [SETUP] & [ATTRIBUTE] will open the pop-up where you can change attribute times.
Does this happen in a particular play file or all of the time?
I am assuming that this is with a sequence on the main playback. Do you have "Build" turned on for the sequence?
Good luck,
John

John,

I'll try changing the default attribute time and see whether the lag time changes proportionally. What other things pay attention to the default attribute time? Sequence steps use the step time for attribute time by default, right?

This does happen on all play files. I tend to hit it during tech rehearsals mostly, where I'm stepping through cues with [Seq-]/[Seq+] and then expect to be able to enter my next command as soon as I hit [Seq+] for example. Instead, my command simply queues for 3 or 4 seconds and then executes after..

Thanks!

Automark & Move in B use the default attribute time. Execute Attributes for a Master will use default.
I can't help wondering if the Master Playback faders might be involved. If you have the faders in the middle of a fade, it will lock-up some functions. Try using the faders to "bump" into the next preset and see what happens.
Do you have any external fader wings attached?
Have you tried running a face panel test? It is in the system settings shell under the Utilities tab.
Another thing is to run a "Deep Clear" from the same tab.
If these things don't help, call Tech Services! They are there to help, and can walk through solutions in real time with you.
Finally, 7.2 was a really big update. I absolutely understand not messing with things when they are working, and you are in the middle of shows, but I would recommend you think about updating. Or updating after 7.3 is released.

Automark & Move in B use the default attribute time. Execute Attributes for a Master will use default.
I can't help wondering if the Master Playback faders might be involved. If you have the faders in the middle of a fade, it will lock-up some functions. Try using the faders to "bump" into the next preset and see what happens.
Do you have any external fader wings attached?
Have you tried running a face panel test? It is in the system settings shell under the Utilities tab.
Another thing is to run a "Deep Clear" from the same tab.
If these things don't help, call Tech Services! They are there to help, and can walk through solutions in real time with you.
Finally, 7.2 was a really big update. I absolutely understand not messing with things when they are working, and you are in the middle of shows, but I would recommend you think about updating. Or updating after 7.3 is released.

Thanks for the info on what else uses the default attribute time..

I have verified that changing the default attribute time changes the length of time the console is "locked up". So, as a tech week workaround I can just set this value to .25 or similar and be much better than previously at least, and then I can set the value back prior to an actual run through.

Master playback faders don't seem to be involved.. no fader wings attached (Congo Kid, so doesn't support them). I've done face panel tests, but I think this is a software thing -- I have two Congo Kid's and they behave identically..

I'll definitely plan on putting 7.2 on there after the end of this show. I'm curious to mess with cue lists -- I admit I don't understand what their purpose might be, other than to more easily move a chase sequence from show to show without worrying about preset numbers bumping into each other or something..

I may indeed give ETC support a call -- the delay seems like a bug, or at least unexpected behavior that should be documented..

It sounds odd that the default attribute time would affect any of this.

Could you give us an indication on how many devices you are using in this show and how many devices there are in a typical cue?

Anders,

Not many -- I'm quite a small venue. I have 44 standard dimmers, and then generally 10 RGBW LED mover fixtures. The delay only occurs if FCB parameters on the RGBW movers change..

If I have the channels selected when I hit [Seq+] or [Seq-], I can see the attribute values changing and that change seems to be done at the default attribute time value. If I change the default attribute time, that attribute value change fade changes duration to match, and the length of time the console is "locked up" also changes with it.

Happy to send any show files or do any other diagnostics you would like.. I have two Congo Kid consoles and they both act identically, so I don't think it's hardware related, though..

Thanks!

Ok. So the amount of devices should not be a problem.

Do you see an hourglass in the top right corner when the console locks up? What is puzzling me is that you can see the attributes executing on the screen even if the console appears locked up, which means it isn't really locked up.

Anders,

I am not sure about the hourglass -- I will be in venue tomorrow evening and will check it out. I'll also try to take a video of the whole process and the lag/delay/lockup I experience in case that will help..

I agree that the console isn't really locked up, it's just that it must be ignoring most command input until the [Seq+]/[Seq-] fade operation is completely finished. Since I'm using Seq+/Seq- to cut around in my cue list during tech, it's not intuitive that this should block out other console functions, and so the issue is I'll enter a command and nothing happens for several seconds, by which time I've probably started re-entering the command (and all the other issues that come with input lag)

Thanks for chewing on it!

A short video would most likely be helpful. It is still a mystery why the execution of attributes would prevent console actions.

Anders,

Any thoughts after seeing the video? Should I open a support case?

Thanks!

Joe

Hi Joe,

Sorry for the delay on this. I watched the video last week but I didn't have any ideas about what is happening and therefore not much to say about it. We haven't been able to look closer at it yet but will do that soon. However, it isn't a known issue as far as I know and I am a bit puzzled by the behavior you see.

Regards,
Anders

Anders,

Gotcha, thanks for the update. I have a couple week break between productions -- would it be helpful if I update from 7.1.1 to 7.2 just to confirm that the issue is still present on latest?

Joe

We have now tried to reproduce this on various consoles, without success. Updating to 7.2 would be a good thing to try, although I can't see how it could change this specific behavior.

Anders,

Okay, I will update to 7.2 (possibly tonight). Assuming the behavior continues (I assume it will) I will grab a copy of the show file for you, in case its an artifact of my device template or something..

Thanks!

Hi Joe and Anders,

Im glad you have brought this up i have a Congo Jr running cobalt and i have the exact problem, to the point if I'm running back through the show and make a change to a fixture if i update the cue and the sequence hasn't completed it saves the cue in the state when i hit update, which is extremely frustrating when you want to make a minor change, do you have that issue?

Patch

Anders,

I did update the console to 7.2, and I did notice several slight differences in behavior.. I've been trying to nail down a specific test scenario to send you, and will spend some more time on it after this weekend's event finishes up in our venue.

One thing that I think I *have* nailed down is that my GO lockup situation that you can see in the video is related to AutoMark. If an AutoMark is occuring, that seems to lock up any go or SEQ+/SEQ- functionality until the automark is completed. I don't know if the same issue happens with AutoMark disabled and channel levels set to M.. I'll test that out too and see if I can narrow the scope any further.

My hope is to be able to send you a show file and a sequence of steps to trigger the behavior. Apologies for the delay.