Aurora v2.0 - Refactoring

Jason · July 31, 2015, 12:41am

Aurora is in need of a refactor. I would love to have more people involved, and @kigster has expressed interest in helping. Anyone else interested?

I’ve started the conversation on GitHub, please join in the discussion (here or there) if you’re interested.

Thanks!

github.com/pixelmatix/aurora

Aurora v2.0 Goals

opened 12:39AM - 31 Jul 15 UTC

jasoncoon

Aurora is in need of a refactor. It would be great to have more people involved…, and @kigster has expressed interest in helping. Anyone else interested? #### Goals Some possible goals for a refactor would be (in no particular order): - Simplify all of the #includes and externs. Right now it's a bit of a mess, has to be kept in a very particular order for various class dependancies, is problematic for Eclipse users, etc. - Make it easier to add, remove, disable content (patterns, audio patterns, games, etc), and functionality (TPM2 streaming). - Eliminate the hard-coded item counts that have to be updated every time a pattern is added or removed. - Reduce memory use where possible. - Move input handling out of the Menu class (seems wrong, the class is huge). - Simplify settings loading and saving (should likely be moved out of the main Aurora.ino file). - Simplify menu state and foreground overlay handling (brightness, palette, play mode, etc). - Separate audio patterns into individual classes, like Patterns. Currently audio patterns are all just handled as function pointers, and they're all in the same class. This is definitely simpler than how patterns are handled, but to provide names for them, like Patterns, Palettes, etc, they'll either need an array of names that need to be kept in sync as they're added/removed, or they need refactored into separate classes. #### Aurora Strengths - The Drawable base class, and one pattern per class. I like the start, stop, and drawFrame methods, which allow easy initialization, and the complete lack of delays used within the patterns. - The way the requested delay for the content is handled, while still processing input from IR, Serial, etc. - The relative simplicity of adding new patterns. #### Wishlist My wishlist of new features, and things I'm not completely sure how to pull off: - Scripting and/or bootloading support. It'd be awesome to be able to write new patterns, copy them to the SD card, and have them dynamically loaded and executed, without recompiling. - Content rating system, similar to how WinAmp visualizations can be rated, and rating affects how often content is shown in random playback mode. I can't decide how best to store the rating on the SD card, tied to the content (pattern, animated GIF, audio pattern), especially as patterns are added, removed, reordered. - Support for multiple animated GIF 'albums'. Currently all animated GIFs are cycled through in the single Animations mode. I think adding a new menu entry for each directory in /gifs is a decent idea, but the menu doesn't currently support dynamic items, they have to be statically defined/allocated. Another way to handle it would be to show directories in the gifs folder, as you're cycling through animations. Pressing select would 'enter' that directory.