Edit: Ok. I can repro the problem if I push the commands just a little bit faster. You might want to go back to the pre-fade version of multisegment for a day or two while I sort this out. There’s definitely something strange going on in there!
I ran it overnight, doing a bunch of automated switching and fades, and it’s still behaving itself, so there may be something else going on. Here are a few things to try.
First, the paranoid option: be absolutely certain you’re running the latest version from the experimental repo: multiseg3.js. There’s a slight possibility that something went wrong during the save process, per this thread:
A fix is in the works, but for caution’s sake when saving, I note the pattern’s frame rate beforehand, press save, then touch nothing 'till the frame rate has returned to its prior value. Get the pattern saved, then switch to another pattern for a second, switch back and check code in the editor to make sure everything’s OK.
Also, check/restart your controller to make sure it didn’t save any data from the previous version, which had the JSON array size problem. If the controller was using getVars, it might have grabbed an incorrectly sized array, and sending it back to the Pixelblaze would definitely cause weirdness. This version uses the original 7-element controls - state, hue, sat, brightness, effect, size, speed.
Effects should be be fadeable too, so effect setting should have… no effect at all. But it is possible to overrun the websocket connection with data, which could cause the lag. My controller is relatively slow and only sends data for one segment at a time so I might not have seen this. If nothing else works, see if you can add a short delay, maybe 50-100ms to start with, between websocket commands.
Meanwhile, I’ll set up a Python testbed this afternoon to stress it more and see what I can shake out.