Announcing Waveforms!

Hi everybody,

LIFX is pleased to announce the release of waveforms in our public LAN API.

Waveforms allow fine control over transitions between colors on your LIFX devices and are supported on all our devices.

You can find the two new messages (SetWaveform and SetWaveformOptional) on our LAN API documentation pages. Also we have included a Primer on Waveforms on how waveforms work.

We would love to hear your feedback.

Stephen.

7 Likes
  • Is there also a way to see what the current Waveform is (e.g. GetWaveform)? That would be useful for controlling the Waveform from multiple devices.
  • How should you cancel/stop the Waveform? :slight_smile:
  • How do Waveforms work with MultiZone lights? Does it apply the transition to all zones of the light? Is it possible to apply different Waveforms to zones?

@wborn

  • There is no way of querying Waveforms.
  • Any subsequent SetColor will cancel/stop the Waveform.
  • Yes the transition applies to all zones of the light and it is not possible to apply different Waveforms to zones. You can use SetWaveformOptional though to e.g. only set the brightness of the strip while keeping the individual colors for zones.
1 Like

This is working well using lifxLAN so far. It was already implemented just waiting on firmware updates and so far looking very nice.

Thank you for releasing this API officially!

You ask for feedback but in fact you have already shipped the implementation and will therefore be unable to make any changes.

Anyway, a few comments on this new interface:

The Pulse graphs in the primer are wrong. The implementation in fact starts out with the current color (like all the other waveforms do).

Unfortunately, it would have been better for Pulse to actually work like the graphs currently show. For long running effects (like a 1s flash every minute) it is really noticeable that the color does not change immediately.

The skew_ratio is a bit weird, it would have been easier to work with just two durations, one for low and one for high.

A way to stop the waveform is missing. Setting a solid color is insufficient because a different client might have started the waveform and we cannot know which value to revert to.

The SetWaveform message is completely redundant and just adds complexity.

It is software. It can be changed. Apologise

You ask for feedback but in fact you have already shipped the implementation and will therefore be unable to make any changes.

We are always accepting feedback on implementations this was previously an internal message that we decided to make public

The Pulse graphs in the primer are wrong. The implementation in fact starts out with the current color (like all the other waveforms do).

Yep we will be looking to change the graph now. it was created with our internal context and understanding of the system.

Unfortunately, it would have been better for Pulse to actually work like the graphs currently show. For long running effects (like a 1s flash every minute) it is really noticeable that the color does not change immediately.

We are just double checking the current implementation and will update the documentation to suit. though I’m not sure a waveform is the best fit for doing something like a 1s flash every minute as it would be canceled as soon as another state is set.

The skew_ratio is a bit weird, it would have been easier to work with just two durations, one for low and one for high.

Yep it is. it’s unfortunately an internal limitation of the way it is implemented inside the bulb

A way to stop the waveform is missing. Setting a solid color is insufficient because a different client might have started the waveform and we cannot know which value to revert to.

Not sure what i can recommend for you here but i will pass this feedback on and ask around the office for thoughts on better solutions for you. I can appreciate the pain of keeping a distributed state of a device :slight_smile:

Not sure there is anything to apologise for here.

Not you Kevin.

“You ask for feedback but in fact you have already shipped the implementation and will therefore be unable to make any changes.”

It came across when reading as attacking.

The rest were good points.

Agreed, that is a bit extreme. Even for a slow ping (0.1s flash every 2 seconds), the delay gets a bit annoying when previewing the effect. This is a case where it would have been better the other way around but it is not worth changing at this time.

Maybe there is already a way to cancel the effect. Perhaps starting a new 1ms effect, if that will persist the first effect color for non-transient effects(?). Having such a workaround documented would be great!

If you saw some frustration in my posting, that is correct. It is best to get things right the first time. Releasing a new firmware does not mean that it will be installed on all devices. However, getting an API right is extremely hard so it is a bit frustrating that feedback is only solicited when it is actually too late (this goes for all of the API).

1 Like