You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an animation (e.g. by using a configured animationPreset or by calling the POST method directly) is started, the old state is preserved and reset at the end of the animation
const old = dmx.universeToObject(req.params.universe);
[...]
animation.add(old, 0);
By preserving the old state the animation API cannot be used for fading light in and out.
There should be a parameter to define if the old state should be preserved and preserving the old state should be false by default, since simple animations like
While it may be a breaking change, I think preserving the old state is not logical.
If the API can be used to set specific channels by using a specific duration, the user does not understand, why it goes back to the previous state after the animation is finished.
The text was updated successfully, but these errors were encountered:
Another way that would not be breaking could be to have a second API endpoint at /transition/<universe> for animations that don't return to the original state. But either way is fine. I don't think many consumers rely on this API and adding that parameter would also be easy.
The "transition" key lets you specify how long the fade to those values should take, it transitions form the current state of the universes smoothly without going to zero first.
When an animation (e.g. by using a configured
animationPreset
or by calling the POST method directly) is started, the old state is preserved and reset at the end of the animationSee https://github.com/node-dmx/dmx-web/blob/master/dmx-web.js#L89
By preserving the old state the animation API cannot be used for fading light in and out.
There should be a parameter to define if the old state should be preserved and preserving the old state should be false by default, since simple animations like
feel broken.
While it may be a breaking change, I think preserving the old state is not logical.
If the API can be used to set specific channels by using a specific duration, the user does not understand, why it goes back to the previous state after the animation is finished.
The text was updated successfully, but these errors were encountered: