That’s pretty much it: the impact on patterns is synchronization of the time call results.
It works like this:
Once a second PB sends out a beacon broadcast. Firestorm, or a Pixelblaze in AP mode, will reply with a “timesync” packet which contains the time base (a 32 bit number in milliseconds) and will thus act as a time sync source. The python clients [1],[2] can act as time sync sources as well.
The actual time base number doesn’t matter so much as long as it increments by 1 for every millisecond. For Firestorm it’s the lower 32 bits of the current time in milliseconds since the Unix Epoch, and for a Pixelblaze in AP mode, it’s the number of milliseconds it has been running for.
When a PB gets a timesync reply, it takes the time base from the time sync source and half of the network round trip time, then adjusts its own time accordingly to try to match. If the difference is huge, it will jump to the base time (e.g. when a PB first comes online), otherwise it adjusts its local time slightly in the right direction. There’s a bit of filtering in there to prevent the odd network blip or jitter from throwing this off, but thats the gist. After a handful of seconds it’s within a few milliseconds of true.
The base time is then used when calculating return values for time(interval) which creates a sawtooth waveform roughly like this:
(currentTimeMs % intervalMs) / intervalMs
So if 2 PBs have roughly synchronized the same currentTimeMs, they will return similar values for calls to time(interval) with the same interval parameter.
By the way, the currentTimeMs is a snapshot taken for each frame, so multiple calls to time(interval) will always return the same result within a single animation frame even if it took a while to run the pattern code.