Red (second-hand) with a width of 1 -- so it blocks out the underlying color unless it is only partially overlapping the hour or minute hands.
A "thinner" second hand would show more color mixing, and appear less bright.
(viewed through a sheet of paper to reduce brightness and show color blending)
When I was previously working on this project, I somehow jumped to an incorrect conclusion that SPI0 (pins 19,21,23) could not be used at the same time as SD1 (pins 13-18,22) -- so I got really off-track trying to find an alternative (I was extremely stressed out at my previous job -- by a hostile takeover, and new CEO firing and burning out loads of people)
I decided to switch from EL-wire to LEDs in the C-ring. I hand wired LEDs into groups of 4, and used short thin wires to connect to a larger power bus wire.
I had a huge amount of LED failures, maybe from a too-hot soldering iron (maybe bad parts?). I also had a wire failure (even though it wasn't open -- it broke the LED data chain)
(those 60 LED rings are nearly perfect width and radius for the C-ring -- but their board is too thick for the power switch board, and possibly would also hit the RPI -- and would also need cutting)
The DMA on SPI0 prevents most glitches on WS2812b LEDs, but is not perfect. A potential fix may be for the SPI kernel driver to support adjustable transfer bits. Current code can only inefficiently send 2 led-bits per byte and that exhausts the 32 bit SPI buffer very quickly.
(or the driver should detect an LED timeout and resend the whole LED frame)
(I'm interested in building a kernel driver, but that is a steep learning curve)
Since the LED data is not using the PWM system -- sound output is available, and sound visualizations should be possible.
A major problem in my current code, is the subpixel rendering is very slow. The subpixel resolution can be set by changing the size of bytearray "mix". Full resolution would be 256 -- smaller numbers limit blending to that many steps.
With just 3 or 4 objects (x 3 for RGB), it was taking seconds to render 256 steps. For now I settled on 32 to match up the FPS and number of steps. To go a bit faster, the code only renders subpixels at the edges of lines.
Not sure why it is so slow: might be a bug in my code, or maybe bytearray is slow?
An alternative might be to use pygame or some other canvas provider -- but it may be difficult to find anti-aliasing / subpixel rendering. Ideally, the color mixing should also be gamma adjusted.