A little project of mine where individual Game of Life patterns compete against each other. Note how alive cells at the very edge "charge up" the perimeter between them and try to dominate their neighbour.

We are using a Parity Grid ("checkerboard pattern") to assign neighbouring patterns alternating signs +/- which makes the calculation of the perimeter cell charge trivially easy.

When reading from our database of known patterns we can select those of similar lifespan (500-599 generations in our video) which makes for a more interesting dynamic. When using random patterns, most fizzle out very quickly and only a few live for potentially very long lifespans (which would make them dominate the leaderboard).

I'm excited of how the final output came together, visualising the progression and layers behind the design with layering of colour hatching, by density of lines in these cases.

What do you think?

I approached this as a reference-led reconstruction problem rather than a prompt-to-video exercise. Kimi K3 handled source inspection, frame extraction, edit-point detection, and helped translate the shot structure into an editable codebase.

The implementation separates three concerns. GSAP manages the temporal system: shot boundaries, easing, transitions, and camera transforms. Generated textures provide the material layer for physical props. Three.js handles the spatial simulations, including instanced particles oriented along the local field direction.

Each clip was evaluated against matched reference frames for timing, shot scale, density, and transition continuity. In practice, the frame-level QA pass had more impact on fidelity than the initial reconstruction.

In a pipeline like this, would you lock editorial timing before building the simulations, or let the motion system influence the cut structure?

1.5s comparison. Left: simplified V1 props; Right: final realistic textures and richer visual density

30s comparison. Left: thin-line V1 field; Right: final particle rendering with an iron-filings texture

https://reddit.com/link/1v2myey/video/wcfplnomxleh1/player

used my m1 macbook, onboard rgb camera for the hand tracking, and some semitransparent fabric with a short throw projector

Extension of the work by Pajouheshgar et al. Instead of photo stamps there are now video stamps. Each pixel has an extra phase layer that drives both the NCA and the LPPN. Each video stamp has a different phase and pixels try to stay consistent with one phase.

Python (NumPy + Pillow)

I spent the last few months building a browser-based synthesizer.

Hi everyone!

I wanted to share a project I've been working on in my free time. The goal was to see how far I could push the Web Audio API while keeping everything inside the browser—no plugins or installation required.

Current features include:

* 25-key playable keyboard

* 6 built-in instrument presets

* Polyphonic playback

* Reverb, Delay and Distortion effects

* Real-time controls

* Keyboard mapping

* Recording directly in the browser

* Export to WAV and MP3

* Responsive interface for desktop and mobile

I also spent a lot of time designing the interface because I wanted it to feel more like a premium music application than a typical web demo.

I'd really appreciate hearing what musicians, producers and developers think about it. I'm especially interested in feedback on the UI, workflow and overall experience.

If anyone would like to try it out, feel free to leave a comment or send me a message and I'll happily share the demo.

Thanks for taking a look!

Pillow+NumPy

Kiss Me I'm Dying - This Eternal Decay

I want to build my own dock in Python, but due to Wayland limitations, I can't align the dock to the top of the screen. How can I bypass this limitation?

To be clear, I don't want a solution that only works on a single compositor. I want it to work across Hyprland, Niri, KDE Plasma, GNOME, and Sway.

How can I position the dock at the top of the screen, similar to how Waybar does it?