These appear to be wound backwards:
15L
19aR
19bR
37R
42R

Looks like some of the rear panels too?

The slider should look like:

This library for creating stylized sliders looks promising: https://github.com/sghall/react-compound-slider

https://github.com/espressif/llvm-xtensa

Maybe-useful stuff:

• https://www.nayuki.io/page/tap-to-measure-tempo-javascript

How to do this: https://www.thepolyglotdeveloper.com/2019/01/getting-started-mongodb-docker-container-deployment/

https://gist.github.com/davideicardi/f2094c4c3f3e00fbd490

Older how-to: https://www.thachmai.info/2015/04/30/running-mongodb-container/

Use Case:

Use mongodb to persist user accounts, presets/preferences within sparklemotion.

Please refer to this Schema!

Need to support packet reassembly

Steps to reproduce:

1. run ./gradlew runPinkyJvm and ./gradlew runBrainJvm
2. Open browser at localhost:8004
3. Open either another browser tab or incognito window and go to localhost:8004
4. Start adjusting the eye positions on both browser windows

When two users subscribe to the moving heads PubSub and start sending updates, the server keeps both instances alive and bounces back and forth between both values in an infinite loop. This stops when one user disconnects.

It seems like it is because the UI sends an update for the moving head position, but never listens for what the position should be from the server, which is why I think we get competing moving head positions when multiple users subscribe to that topic?

Lights with color wheels support intermediate positions, which allow for some cool but easily-overlooked effects:

We can support direct control of the color wheel to shows, for when they want that much that much control.

We could also maybe encourage the effect's occasional appearance in less minutely-coded shows by, e.g., matching wheel mixtures against the requested RGB color from the show.

We should probably adopt a code of conduct, something like this: https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md

See https://www.w3.org/TR/compositing-1/#porterduffcompositingoperators

Steps to reproduce:

1. Run ./gradlew runPinkyJvm and ./gradlew runBrainJvm
2. Go to localhost:8004
3. Click on the tab: Eye Controls
4. Click on the Shows tab
5. Click back to the Eyes Controls tab, then try to control the eye

Expected Result:

Should move the eyes

Actual Result:

UI freezes, some infinite loop sometimes occurs, then the UI crashes

• trivial implementation of user DB/management to start
• simulator allows launching UIs authenticated as users

We should make a .gif of the sparkle motion simulator, and include it in our readme as one of the first things.

It makes it look cool, and gives a quick demo/overview of what this project is all about!

Needs to take any user through all the steps for setting up a dev env, and writing a first hello-world show, and how to add a couple of features.

This vulnerability got fixed: sass/node-sass#2625

So it's safe to add back node-sass

Ubiquity?

We should sync panel names in the model back up with the names printed on the panels.

1D/1P through 43D/43P have been so named for 7 years now and lots of people know them intimately. Let's not change them. The F1* through F19* and R* series are also well-known and I'd suggest we leave them as-is unless there's a clear better alternative. There are some fill-in panels in front that don't have names and need them. Face, ears, and tail probably need sub-panel surface names.

Given a moving head's model position and orientation, and a target point, calculate pan and tilt.

For the uninitiated: https://color.adobe.com/create

User story: it would be cool to map a physical interface of knobs/sliders/buttons to produce the same result as adobe color

Mock up:

… using protobufs or CBOR?