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
I am currently developping a full-featured go library for the BlinkyTape and i aim to implement animations. From PatternPaint, we can only export the animation to an Arduino C header file, and i would like to suggest to add a new export capability with a more common syntax, like JSON.
The structure is pretty straightforward, we have a key frames which is an array of frames, each frame is an array of pixels. A pixel have for now only the field color represented by three keys, but we may add more later, like brightness ?
The values of repeat and delay follow the syntax of the arduino export. name is for consistency/debug. Still, i think we should use speed as it is more human friendly (like in the PatternPaint GUI) and let the libraries do the math to get the delay between each frame.
The proposal does actually fit my library implementation, but i think it is representative and not too specific to be used by other libraries. I am open to any changes.
The text was updated successfully, but these errors were encountered:
Hello
I am currently developping a full-featured go library for the BlinkyTape and i aim to implement animations. From PatternPaint, we can only export the animation to an Arduino C header file, and i would like to suggest to add a new export capability with a more common syntax, like JSON.
The structure is pretty straightforward, we have a key frames which is an array of frames, each frame is an array of pixels. A pixel have for now only the field
color
represented by three keys, but we may add more later, likebrightness
?The values of
repeat
anddelay
follow the syntax of the arduino export.name
is for consistency/debug. Still, i think we should usespeed
as it is more human friendly (like in the PatternPaint GUI) and let the libraries do the math to get the delay between each frame.The proposal does actually fit my library implementation, but i think it is representative and not too specific to be used by other libraries. I am open to any changes.
The text was updated successfully, but these errors were encountered: