Weird lag problem I've seen before, but can't find it

[chuckd]

I have a fair amount of channels (650), and it's all run from one network. Everything is running pretty well, but I have this one song where about a 10 second segment seems to lag in the live display version, but the sequence editor animation is spot-on.

It doesn't seem to be any more complex in the live version, but I do 'flash' the entire 650 channels a bit during this segment (synchronized with cymbal crashes).

Am I perhaps sending too many commands out during this portion? The actual light flashing is just a bit late, but it's enough to be quite noticeable.

I'm using a WAV file for the sound file. Here is a video of the song, and it might be possible for you to tell near the end of it where the cymbal crashes get off.


I'm also using version 2.0.16. I'm not upgrading until this season is over.

http://www.vimeo.com/2555647

Chuck

[-klb-]

I think you are in the ballpark of where lag can be a concern, depending on your sequences. Since the animation is on, I would suspect your sequence requires more commands be sent down the serial link than can fit in real time. You could try going into edit/preferences/network preferences, and try configuring the short network/high speed option, and see if your network is up to it. If so, it may show if your lag is network related. Another test would be to make a copy with only half the channels taking action, and see if the lag goes away... Then you would know... On the 602 channel city park show, we went to three networks for several reasons, one of which was just to avoid any risk of issues from network load..

[chuckd]

I do have another RS485 adapter that I could use to create another network and take off half the load, but there's no way I'm doing that now that everything is live.

I can't use the 'short network' feature, since my total run is almost 1000 feet. I'm pretty sure that isn't a short network.

I'd love to see a feature added to the sequence editor that indicated areas of timing concern. Maybe a histogram showing lag times during the songs, broken down into 2 to 5 second intervals. Then it'd be much easier to simplify sequences so that lags weren't so noticeable.

Every writeup I've seen on bandwidth limitations with LOR doesn't fully address the detais of what is going on. For example, I don't know which commands are more complex than others. I guess the only way we'd know is to actually see the protocol, and so far no vendor has opened this information up. Sad, because there's a few ideas I've had for LOR compatible devices that simply won't be built because of that.

It's tough to simply find out on the live display that you're doing too much at one time.

Chuck

[-klb-]

In general, ramps are the worst offenders, as the current protocol (2.0.12 and older, I can't speak to 2.1.x) sends every required intensity to the controller. Ramping large numbers of channels in parallel is probably about the worst case.

But even in cases of large numbers of channels turning on and off together, you can get a wave effect...

Multiple networks can actually be pretty simple to implement, especially if you have a track where the controllers are pretty much sequential...

• 
  
• Make backup copies of all your sequences.
  
• Find a point about half way through your chain of controllers.
  
• Document which ones are before vs after.
  
• Run a new cable to that midpoint.
  
• Enable multiple networks.
  
• Configure display networks in the channel properties grid.
  
• Verify which com port is the "regular network"
  
• Add the new USB adapter, and note which com port it comes up as (The com port list in the device manager is good for this)
  
• Configure network AuxA to use the com port associated with the new adapter
  
• Use the channel property grid to switch all channels on controllers that are going to the new network from regular network to AuxA.
  
• Test it all..

This way, you can roll back pretty easily. Even if you make changes to your sequences, and you choose to go back to one network, just update so all your channels are on the regular network, and plug things back into the one chain.

- Kevin

[chuckd]

I don't do any ramping at all, since I have the 2008 CDI strings that create all types of incendiary effects if I do! Most everything is an on/off transition. When I do the big flashes, I'm hitting every channel to turn on and off in about .15 to .2 seconds, so I guess that's a lot of commands.

Thanks for the input, and you can bet that next year I'll be running all 4 networks together in parallel, since I'm expanding quite a bit.

Chuck

[bob]

In general, ramps are the worst offenders, as the current protocol (2.0.12 and older, I can't speak to 2.1.x) sends every required intensity to the controller.

That's not correct (or, at least, it shouldn't be). Fades are not resource intensive from the comm point of view.

If you suspect that your sequence is doing this, you might want to check that you really do have fades, rather than a bunch of individual set intentsities. To do so, click on a cell in question, and select "Cell info" from the "View" menu.