After 3.0! A long-term roadmamp for BiblioPixel

Now that 3.0 is ready, it's time to look forward to the long-term - because without a long-term plan with something really exciting at the end, this is just a maintenance exercise.

BiblioPixel has three types of components: animations, layouts and drivers.

And our long-term goals are solving six problems:

sharing: to reuse components and share them with others.
combining: to combine existing components into new ones.
controlling: to control components with external signals or data.
scaling: to handle larger projects with multiple components of each type.
recording: to record and playback a performance, recording both the output results and the incoming control signals.
multiprocessing: to make good use of more than one CPU core, with potential large increases in processing power.

The goal of BiblioPixel 4.0 and perhaps beyond will be solving these six problems.

If we solve the six problems well, it should be easy for an individual LEDJ to build up a library of animations that is both broad and deep: "broad" meaning that there are many animations, and "deep" meaning that the animations are highly controllable and customizable.

APPENDIX: A rough analysis of what tasks need to be done.

1. Sharing is mostly solved.

The mechanism for sharing is already enabled in BP3.0.

BiblioPixel contains the gitty library, which uses a public source code repository like github or gitlab to store and share both data files and code - so you can directly load or run someone else's work from github or gitlab.

We need to automate parts of the workflow so you can, for example, record a performance and then push to a repository automatically. And we need a document explaining exactly how this is all done.

2-4. Combining, controlling and scaling need a rewrite.

BiblioPixel 3.0's whole architecture requires exactly one Layout and one Animation.
Clearly some fairly dramatic surgery will need to take place simply to allow multiple Animations controlling multiple Layouts to work at all.

There are other issues.

Right now, when an animation starts running, it completely takes control. Many animations run indefinitely! If one animation can take control of your system and run indefinitely long, it's bad news for gracefully swapping in and out of the animations.

This comes from the fact that the animation engine is built into each Animation - and that design, which worked well for three reasons, is now causing other issues.

The animation engine will need to be completely split off from Animation so an Animation can run as the complete slave of another.

Threading will also need to be split off the device and animation classes entirely, for similar reasons.

Backwards compatibility with BP3.0 will likely be like backwards compatibility between BP2.x and 3.0 - good but not perfect.

5. Recording depends on steps 2, 3, and 4.

We're going to have to add a recording aspect to each of our components. This can likely be handled in a way that's transparent to the user (a metaclass perhaps?) but we can't even start this until steps 2, 3 and 4. are completed.

6. Multiprocessing depends on 2, 3 and 4.

We could easily implement everything except multiprocessing, and run it entirely on one core. This is how it is now, and it works fine for 95% of projects today...

But given access to far more CPU power, users could do all sorts of things impossible with the current technology. In particular, there has been persistent interest in floating point color

To do this correctly, we need to see how the other parts shake out. Getting all the threading out of the individual components will help a great deal too.

Implementing multiprocessing cannot be started until 2, 3 and 4 are done.