I’m curious as to why you’re not exposing the blinkani effects code in the API doc? The blink, strobe, rotate, and spin effect methods would be useful and avoid us duplicating the effect in our code since you already have it.
Is including blinkani.h in our sketch and calling blinkAniBegin in setup before using effects ok right now? (Btw, I’m actively using the effects code already in a sketch).
Yes, it seemed like a useful model to make games with Blinks would be to have an animation layer that you simply call the kinds of animations you desire and the “display manager” of sorts will handle the updating of the LEDs. My person experience with it has been that I constantly enjoy inventing new patterns and animations and that the animation library quickly becomes limiting, but that doesn’t mean I think it isn’t useful.
Would love to see your code using the ani library, perhaps we can use it as an example. Creating some nice examples of how to use the animation library is one of the main reasons it isn’t yet under the spotlight. Looks like you can help us get it there! 
blinkani.h is no longer in the library, right?
Yeah, the BlinksAni library is not in the current API. Do you think it is something you would use? For our current games, our animations are typically so custom that the model didn’t seem to help much. I am curious to see some examples of using this kind of a model to make games in a more event driven manner (i.e. something happens and then you call fadeTo(GREEN, 500) and the display manage simply takes care of fading the color from your current color to green…)
If you had started using it or extending it, I’d love your thoughts. Sometimes I love the experience of writing mathy animations and other times I would just love a function to call to express the animation I can picture in my head.
I would also be interested in using an animation library / manager of some kind. For my games projects, I almost always “design” the gameplay first, and “juice” the game in a later phase. But knowing how I will be juicing it definitely dictates some development decisions, so it’s good to have a sense of what the juice code will look like, and where it will impact the gameplay code. Having a library for this is super handy, even if, in the end, you want to do custom stuff not supported by the library, at least you have a framework in place.