Gurkirat Singh

A C#/.NET 8 app that turns a multi-monitor desktop into a sound stage: the desktop audio mix is positioned in 3D space based on where the focused window sits. Captures the mix via WASAPI loopback, tracks the focused window across monitors, and spatializes in real time. All code handwritten as a learning project, with AI review; HRTF convolution in progress.

Architecture

Focused window on the virtual desktop (multi-monitor)
  │  Win32: GetForegroundWindow, GetWindowRect,
  │  monitor union (P/Invoke, per-monitor DPI aware)
  ▼
WindowTracker ── azimuth θ, distance ──┐
                                           ▼
WASAPI loopback capture ── PCM chunks ──► Spatializer (DSP)
  (48 kHz float stereo)                    ├─ ITD: ring-buffer delay on the
                                           │        far ear (30·sin|θ| samples)
                                           ├─ ILD: equal-power cos/sin panning
                                           └─ HRTF: KEMAR IR convolution (M3)
  ▼
Output device (feedback-loop safe, headphones)

Key Features

• Window-following audio — azimuth/distance computed from the focused window's rect across the virtual desktop (±70° front-arc model); left/right image verified to follow window movement by ear
• Duplex-theory spatialization — ITD ring-buffer delay line (max 630 µs) on the far ear plus equal-power ILD panning with constant perceived loudness
• Measured latency — synthesized click-train probe reports 2.8 / 29.4 / 55.3 ms (min/avg/max) through the full capture→spatialize→render path
• HRTF loader (M3, in progress) — parses all 1420 raw big-endian MIT KEMAR HRIRs; loader self-verifies against the published dataset values (max sample −26793 ÷ 32768)
• Low-level Win32 — P/Invoke into user32.dll for window/monitor enumeration, per-monitor DPI awareness, asymmetric-monitor virtual desktop union
• Feedback-loop safe — capture and output devices must differ, so the spatialized mix can't re-enter its own loopback

A zero-cloud voice assistant for an AI coding agent. Listens to the agent's reply stream over SSE, synthesizes speech entirely on-device with Fish Audio S2 (GGUF + Vulkan on an AMD GPU) or a Kokoro fast engine, and speaks through your speakers — no cloud services anywhere in the voice path.

Architecture

opencode (AI coding agent, running in WSL)
  │  SSE event stream → completed replies
  ▼
voice_agent.py (Windows Python)
  ├─ sanitize()   → tables/code → "[table]" / "[code]" cues
  ├─ split_text() → ≤480-char sentence chunks
  └─ POST /generate per chunk (prefetch next while playing)
      ├─ s2.exe (s2.cpp)   → S2 Pro q4_k_m · Vulkan · 7 GB VRAM
      └─ kokoro_server.py → Kokoro-82M · CPU · ~10× realtime
  ▼
WASAPI → speakers (2s pre-buffer, self-healing stream)

Key Features

• Dual engine — S2 for expressive speech with natural-language style and emotion tags, Kokoro for near-instant CPU narration; toggle via engine.conf
• Zero cloud — models run locally on the AMD GPU (Vulkan) or CPU; the only network egress is the coding agent's own API
• Voice cloning — the assistant speaks with a cloned voice from a 10–30 second sample
• Stutter-free playback — the pipeline runs at ~1.5× realtime, so replies are synthesized one sentence-chunk at a time with prefetch overlap; tables and code blocks collapse to short spoken cues
• Resilient — self-healing audio stream survives device changes; single-flight TTS with graceful queueing
• Open-source contribution — submitted upstream PR #48 to s2.cpp fixing an unqualified max that breaks builds under NOMINMAX; avoided a 16 GB RAM OOM by moving from the torch server to a C++/GGML engine
• Fully documented — changelog of 15 resolved errors with root causes, plus a structured learning path

A browser-based tic-tac-toe widget built from scratch with an unbeatable AI opponent and online multiplayer. Features four game modes, immutable state management, a Cloudflare Worker relay with KV persistence, and room-code matchmaking.

Features

• Unbeatable AI (Hard) — minimax algorithm explores the full game tree for perfect play; Easy mode picks moves at random
• Online multiplayer — room-code matchmaking via Cloudflare Worker relay with Workers KV for cross-instance state sharing
• Session persistence — sessionStorage-backed rejoin; refresh or change tabs without losing your game
• Four game modes — vs AI (Easy), vs AI (Hard), local PvP, and online PvP
• State-driven rendering — immutable game state with a single render path; DOM always reflects current state
• Win line highlighting — winning triplet cells get a highlighted background for instant visual feedback

Architecture

TTTEngine (pure logic, zero DOM)
  ├─ createGame()    → fresh state object
  ├─ makeMove()      → immutable move + win/draw detection
  ├─ checkWin()      → scans 8 win lines against board
  ├─ getBestMove()   → easy=random, hard=minimax (recursive tree search)
  └─ minimax()       → +10 / -10 / 0 scoring, in-place mutate & undo

TTTWidget (UI controller)
  ├─ mount()         → bootstraps widget into DOM container
  ├─ renderBoard()   → redraws 9 cells from current state
  ├─ handleClick()   → validates, applies move, triggers AI or POST
  ├─ updateStatus()  → turn indicator, win/draw messages
  └─ pollRoom()      → 500ms polling for opponent moves in online mode

Cloudflare Worker (multiplayer relay)
  ├─ POST /room/create        → generates 4-char room code
  ├─ POST /room/join/:code    → joins as O, supports X-Player-Mark rejoin
  ├─ POST /room/:code/move    → validates turn, applies move server-side
  ├─ GET  /room/:code         → polls current board state
  └─ POST /room/:code/rematch → resets board, swaps X/O

A fully local, two-stage AI pipeline that extracts Japanese text from raw comic/manga pages and translates it to natural English. Zero cloud APIs, zero Tesseract, zero manual preprocessing — just raw images in, English dialogue out.

Architecture

images/*.png
  │  preprocess.py: load, downscale, base64-encode
  ▼
ocr.py ── POST /api/chat → Qwen3-VL (vision model)
  │  Returns raw Japanese text from speech bubbles
  ▼
translate.py ── POST /api/chat → TranslateGemma (LLM)
  │  Furigana stripping → contextual English translation
  ▼
outputs/batch_translation.txt

Key Features

• Two-stage local AI — vision model reads the image, separate LLM translates; both run on-device via Ollama
• Zero preprocessing — raw images go direct to the vision model; no grayscale conversion, thresholding, or denoising
• Vertical text support — vision models natively understand right-to-left Japanese reading order
• Crash-resilient batch mode — streaming per-page writes survive mid-batch failures; restart picks up from scratch with no duplicates
• Furigana stripping — regex-based removal of kana reading annotations before translation to prevent tokenization noise
• 563 lines of Python — no framework overhead, single-file modules, trivially auditable

A global mouse tracker that hooks low-level Windows APIs to intercept cursor telemetry across all applications. Renders real-time trajectory paths on a live JavaFX dashboard and displays hovered application names. Designed for UX heatmaps and productivity analysis.

Architecture

Windows OS
  │  WH_MOUSE_LL hook (jnativehook)
  ▼
App.java ── Worker thread (40ms pulse)
  │  ├─ Win32: GetForegroundWindow, WindowFromPoint (JNA)
  │  ├─ Weighted-pulse CSV logging (5px deadzone + dwell time)
  │  └─ Platform.runLater → UI updates
  ▼
TrackerUI.java ── JavaFX Application thread
  │  ├─ Live X/Y, active/hovered window titles
  │  ├─ Resizable path-trail canvas (multi-monitor normalized)
  │  └─ Dark dashboard theme
  ▼
logs/mouse_log_<ts>.csv

Key Features

• Weighted-pulse logging — writes CSV rows only on ≥5px movement or window change; accumulates dwell time during idle to minimize disk I/O
• Multi-monitor normalization — computes virtual desktop bounds from all monitors, maps raw hook coords to canvas-relative percentages
• Thread isolation — hook message pump on dedicated worker thread; all UI mutations marshaled via Platform.runLater()
• Resizable live canvas — path trail binds to window dimensions, auto-clears on resize

Debugging Highlights

• Resolved path-trail boundary violations where rendered points drew outside the canvas viewport
• Fixed layout overflow in the stats panel causing clipped window titles at narrow widths
• Added zero-guards and size-change listeners to prevent null-pointer crashes during window resize

A lightweight Go CLI that auto-detects any project's stack and generates a production-ready Dockerfile — then builds and runs the container with one command. No Docker knowledge required.

Architecture

deploybox init <dir>
  │  Scan: pom.xml→Java, requirements.txt→Python, package.json→Node, ...
  │  Load: deploy.yaml overrides (name, port, env, volumes, command)
  │  Generate: multi-stage Dockerfile with layer caching
  ▼
Dockerfile

deploybox up <dir>
  │  docker build -t deploybox-<name>
  │  docker run -d --rm (or docker compose up for depends_on)
  ▼
Container running ✓

Key Features

• Auto-detection — scans directory for pom.xml, requirements.txt, package.json, Cargo.toml, or go.mod and picks the right base image
• Multi-stage builds — every Dockerfile uses layer caching; dependencies installed before source so code changes skip full rebuilds
• Optional deploy.yaml — override name, port, environment variables, volume mounts, and startup command without touching the Dockerfile
• Multi-service support — depends_on in deploy.yaml generates docker-compose.yml to wire containers together
• host.docker.internal — containers reach host services (Ollama, databases) through Docker Desktop's built-in DNS
• Cross-project consistency — all generated Dockerfiles follow identical conventions; audit one, trust all

Verified Against

• OCR Translate (Python) — built image, ran batch translation, connected to Windows Ollama via host.docker.internal
• MouseFlow Tracker (Java/Maven) — built multi-stage image, resolved JNA + JavaFX + JNativeHook, compiled successfully