It's how these things go on teams, budgets, and companies large and small - you set out with one goal in mind and eventually lose sight due to the myriad of design, development & infrastructure decisions that come up in the meantime.
In this case, the team is just me, the budget is zero, and the project is a web app that's been roughly half-working for about three years. Meet "Synthesia".
There's no buzzy tagline or product sign-up sheet - it's just a project to see how to make (my) music more interactive. Users navigate to a page, are given a song, and asked to pick a color based on what they are feeling or hearing while listening.
an initial idea
After getting lost in the weeds of trying to make this a product for some reason, today I finally got to the fun part of doing a bit of color analysis.
At present, all tracks and their responses are saved to a supabase database with a 'colors' field existing as an array of hex code strings (i.e. ['fa012c', 'fffc43', 'c5e3a0', ...]). This has been the easiest to work with, easiest for users to understand, and a fairly quick solution.
However, the world of color science goes deep. I'm no Bob Ross, but even I understand how colors can typically be represented in values of hue, saturation, and lightness (or 'light'). These basic values are rooted in core art principles and have existed long before computer screens made them common vernacular. They refer to the pure base color like red or blue (hue), the purity and intensity of that said color (saturation), and the amount of blackness or whiteness within that color (lightness).
On computer applications from Photoshop to Figma to good ol' CSS, color can be defined by hex codes, hsl(), hsv(), and many more ways.
So, the challenge was to figure out what interesting info I could glean from a set of hex codes.
about the extent i can take hex codes (or is it?)
For the sake of time and simplicity, I began with a simple and easy translation of my hex codes into hsl (hue, saturation, light) format using chroma-js. This spat out a nice list of super long floating point numbers, but it gave me something to work with.
Next, concatenated each of the respective values into their own arrays, used a simple reduce() function to get a sum, and then extracted an average value for each. However, these were still just numerical values. In the online space, hue is interpreted as the degree at which the color sits on the color wheel while saturation and lightness are interpreted as percentages between 0% and 100%. A quick note that white, blacks, and grays will cause some wonkiness, so I took those out for now.
Some simple math led me a few nice values, just a step away from deriving something neat.
Finally, after a bit of finagling to figure out the correct syntax, I was able to define what is more-or-less the average color selected for this track!
There is hefty amount more that can be done to analyze just color values, but also an opportunity to do some statistical analysis to determine which tracks have an average color that follows closest to each of the individual selections. As you can see above, the derived color seems to be fairly reasonable. In the below track, however, the color appears to come out of nowhere.
I've always been drawn to statistics and took a few courses at uni but have never really gone too far into the realm of possibilities. Perhaps this is a good opportunity to collaborate with some statistically-minded friends.
In the next TIL iteration about this project, I hope to share a bit more on the technical considerations I made behind how to perform this computational analysis within my codestack.
For now, farewell.
-B
Top comments (0)