Plugin system

[wchill]

Twilight needs a plugin system capable of dynamically loading plugins/filters for color generation and manipulation at runtime.

How this would work:

• Twilight starts up and enumerates all available light panels
• The plugin loader enumerates all available plugins and filters and loads them (the loader can also be triggered by a user command after Twilight has been fully initialized)
• The user specifies which plugin and (optionally) which filters to use for determining colors
• Plugin/filters are initialized
• On each frame, Twilight passes the current panel layout and other metadata through the plugin pipeline (Twilight -> plugin -> filter 1 -> filter 2 -> ... -> Twilight) which then either generates colors (plugin) or modifies the ones passed down to it (filter).
• Twilight then outputs this frame to the panels.

[wchill]

A setup like this allows us to change how Twilight runs the lights without having to restart it, switch scripts, or have some other complicated system. It also simplifies plugin development since plugins are now treated as a black box by Twilight.

[wchill]

For an example implementation, see https://github.com/tehp/OpenPoGoBot/blob/master/app/plugin_manager.py

[warut-vijit]

How should plugins be switched? Assuming that users are submitting requests/scripts through groot, should the newest script instantaneously be loaded or should it be faded in? It seems like switching between two different imported scripts might be rather jarring on the user side

[wchill]

This is a small implementation detail, but it can probably be done by doing one of the following:

• Running both plugins through the processing pipeline and averaging them with a time-weighted factor, so the first plugin is weighted less over time than the second
• When switching plugins, the first frame from the 2nd plugin is grabbed and then Twilight fades to that frame; until the fading is complete no more frames are generated.

[wchill]

Closed by #11