-
Notifications
You must be signed in to change notification settings - Fork 7
Ideas
Some ideas on how to develop the dance floor software.
The dance floor code is a framework that separates sending and receiving data from the floor hardware from the code that generates the LED data. The loop looks roughly like:
while True:
weight_values = get_weights()
led_values = generate_frame(weight_values)
wait_remaining_1_24th_of_a_second()
set_leds(led_values)This loop executes 24 times a second getting weights, generating LED values and sending that data back to the floor. There are a number of other interesting things that could be done as well.
The code behind generate_frame is one of many different pattern generators. Some ideas for interesting patterns that could be developed
There are a number of pixel editors online that allow 8 bit style sprite editing. People good at design but maybe not at coding could help create floor patterns if we created an integration with one of these.
The online editor PiskelApp allows resizing the canvas to 8x8 and can export to a C file where the data is represented as an array. With this, almost anyone could create an animated sequence that could be turned into a floor pattern. To do this we'd need:
- Code that took the (easily parsed) C file and turned it into a Python data structure and saves it to a file
- A processor that reads these files and sequences through each frame as its called.
Note that PiskelApp allows the user to change the framerate. Currently the floor framerate is fixed (maybe control of that could be an improvement?) and requiring 24 fps from causal hand animators might be too much. The fps is saved as part of the C file. If its something less than 24 fps the processor could extend/duplicate frames to fill out 24 fps. That means we'd probably ask folks to use some multiple of 24 like 12 or 8 fps
Here's an example Piskel Pacman and its associated C file.
The event loop described in the overview calls a single processor and sends the LED values it produces directly to the floor. However, there might be other effects, independent of the processor, that would be interesting if applied to the pattern.
Some processor authors might be interested in creating a cool pattern, but don't have any particular idea about how things should change when a person is stepping on a square.
Rather than have every processor writer implement some default weight handling, (or not implement anything at all) we could have an independent weight handling layer that ran after generate_frame() is called. It would take the weight values and LED values and alter the LED values just generated dependent on the weights. Some ideas:
- Increase the intensity of whatever color is on the square that someone is standing on (R, G & B all increased)
- Increase one of R G or B by a percentage
- Create a ripple effect centered on the square just stepped on.
Any effect should try to work to alter an existing squares LED values rather than replace them.
Another type of layer that would be interesting is something that gets input from the current audio (the Raspberry Pi has USB and WiFi) and effects the floor based on the beat of volume of the music. This could also be a dedicated pattern as well
Currently, the controller is just the loop above. 24 times every second it asks for another frame from a processor. As more and more processors are added, it would be nice to be able to have some way to switch between them. Some kind of controller class would be useful to manage the different processors and effects. It would control which processor was running and for how long.
The controller would probably also be responsible for handling layers described above. Aside from deciding what layer to use and when, its possible that some processor would not want a particular layer. For example, if a processor did something interesting with weight values, it wouldn't want a weight handling layer to be applied to it.