steller

in which stuff needed to represent stylistic elements are built. The editing styles DSL [2] and documentation show how this stuff can be represented well removed from implementation details. (Disclaimer: I used to work for muvee, but no longer do so stuff may have changed.) In particular, video and animations were not modeled as functions of time to Image, but functions of a time interval [t,t+dt] to Image. The reasoning was that the interval information is critical to render motion blur. You could argue that the "dt" is a detail that can be passed on later at render time, but it didn't take away much from the API's simplicity. - Steller[3] - a library for declaratively composing dynamic temporal structures, useful (and used) for music and synchronized animations. - elm-anima[4] - a concept demo of structuring animations in Elm. This was pre-18 and so doesn't use subscriptions. Here, animations are conceived of as processes rather than functions over time. I've described the thinking in a post [5]. Elm fell out of favour for me as there were many APIs I needed to work with that I couldn't use it with and the portion that needed Elm was small in the systems I was working with. [1]: https://github.com/srikumarks/muSE [2]: https://srikumarks.github.io/muvee-style-authoring/ [3]: https://github.com/srikumarks/steller [4]: https://github.com/srikumarks/elm-anima [5]: http://sriku.org/blog/2015/12/13/towards-reactive-animation-...