Will need to have backend be able to reply to a request for it's current animations.

Need to get this thing on a pcb

When is use, the voltage regulator will generate enough heat to melt the chassis of a thinkpad laptop. It is completely possible that being soldered to a pcb will provide the voltage regulator with enough heat dissipation. If not, heat dissipation will need to be provided or another regulator will need to be purchased.

Controls are first generated when one animation is visited, and if the user navigates to a different animation without refreshing the page, the correct controls will not be displayed.

Apparently much less janky than my python setup.

Should automatically try to reconnect to websocket after disconnect, or at least display a reconnect button upon disconnect.

If the user slowly drags a slider in the basic site, messages to be sent to the server are generated faster than we can push them out. Either sending an update only on mouse up or limiting the rate at which new messages can be generated would both be solutions.

When the computer side program has been running for a long-ish period of time it breaks in a strange way. cylonEye gets shifted by ~20 LEDs and smoothStrobe just makes it look like it has a seizure.

I suspect the formatTime function is at fault.

Next step for the hardware is to have the eagle design fabricated and move all hardware onto it.

It would open up the possibility of significantly cooler animations if I could pass in more/less/different parameters than the current hard-coded ones. Perhaps the animation data struct could hold multiple function pointers for animations, and all but one would be null?

The max speed and radius on the website is a little low. Should perhaps have first half of slider go 0-1 and have second half go 1-40.

Current driver is crappy and blinks a lot. Moving away from Arduino due to excessive lag.

Due to current hardware limitations (standard LEDs are being used, as opposed to RGB LEDs), only the red channel of each LED is being used. This should be changed to use all three channels.

Use FFT to analyze audio stream and calculate what frequencies are playing. Use this information to light up sections of LEDs in different colors.

Note: should probably wait for project to be moved to raspberry pi.

Once made, the only way to change an animation's type or modifier is to remove and re-add the animation. This will result in annoying UI limitations when making the "advanced" page of the website.

Progress cannot be made on dammitAnimation due to the fact that once I moved over to the raspberry pi, the portaudio library cannot find any audio devices. Mplayer is able to play audio out over the 3.5mm jack, so I believe the problem lies with the library.

Server should be able to accept infinite commands in one line. Can only accept what I believe to be two. Not really a big issue with the way the website is set up, but should be done eventually.

Need better syntax and ideally something not cli (web?)

This is so that eventually a web ui can be created to control the LEDs.

I hear that I should open a port with a very high number to enable communications between the C program and a python program on the same machine.

Make an array of a data struct that will allow animations to write down information about their current state. Would allow for significantly more advanced animations.