Open Fensterbank opened 5 years ago
Sounds good.
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.
You could try out the scene system in my PR, here is an example scene:
{
"id": "fhfdghdfgh-1cf6-fghj-vbnm-ghjk827e01ac",
"label": "Transition 1",
"type": "full",
"values": [
{
"type": "static",
"transition": 5000,
"channel": "1",
"value": "255",
"universe": "office"
},
{
"type": "static",
"transition": 5000,
"channel": "3",
"value": "255",
"universe": "office"
}
]
}
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.
There is also an API endpoint at /state/<sceneId>
Cheers, Will
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.