Aurora v2.0 Goals

[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.

[kigster]

Thanks for starting this, @jasoncoon! This is great 👍

I agree with most of your suggestions above.

• As I did not have SD card available/added to the matrix, most of the SD-card functionality was not useful to me. I am personally not very interested in animated gifs.
• Saving of the settings should be done onto the EEPROM, not on SD card. OR, if SD card is available use that – if not, use EEPROM.
• I would love to see files organized by folders: eg, put all Clock*.h files into the aurora/clocks folder. This compiles great in Eclipse, but I have not yet checked if Arduino itself will compile source files in the subfolders. If it does, then just reorganizing the files will do wonders to making the project easier to understand.
• Everything that is created in the aurora.ino file as a static variable, and then subsequently externed in the Externs.h should become an AuroraApp class, which can be statically instantiated at the very top, and which in turn then encapsulates all of the other top level objects. This way instead of externing a specific variable, subclasses just need access to the top level AuroraApp class. This pattern is very nice and easy to use, and I took advantage of it on this project: https://github.com/kigster/BedTime – check out the main app class and the top level .ino file which instantiates the App class statically.
• I agree that the Menu class should be simplified and broken up. It contains the main event loop, and it took me a while to grok how it flows.
• I would love to see some sort of debug("msg") macros everywhere, which would then be implemented based on various pound-defines to either log to serial console, or to an available via I2C LCD screen, or to a log file on the SD card. Watching how the app behaves over the console would be super enlightening, and will aid in bug detection.
• I would love a mode where the audio input would be auto-detected, and then audio-sensitive patterns would be played only. Reverse should also be true.
• Alternatively, Hardware.h should contain a number of #defines that allow enabling and disabling whole blocks of the program. Something like:

    #define SD_ENABLED
    #define AUDIO_ENABLED
    #define GAMES_ENABLED
    #define IR_REMOTE_ENABLED
    #define CLOCK_ENABLED

Then based on these defines, whole sections of the code would be disabled, for example all clocks would be disabled if CLOCK_ENABLED is not defined.

I am sure there will be more, so I'll think about it and add more thoughts later.

Thanks again for starting this!