Projects

Case Studies and Experiments

Featured case studies first: named limits, decisions, and evidence. Experiments and smaller builds are grouped below so the main thread stays easy to scan.

Featured case studies

Each entry has a dedicated case-study page with artifacts, tradeoffs, and linked evidence.

StringFlux

A multiband granular delay and freeze plugin I'm building for guitar. It listens for transients and uses them to drive grain scheduling, so pick attacks and sustained lines steer the grain cloud the same way they steer your hands.

Status: In Progress

Problem: Most granular processors treat every input the same. For stringed instruments, that means pick attacks get smeared and the effect feels disconnected from the performance.

Constraints: Real-time audio code cannot rely on mid-buffer rebuilds, allocation-heavy behavior, or vague "we'll fix it later" DSP decisions.

Tradeoff: I've kept the feature set narrow on purpose. Getting the engine stable and the transient response right matters more than adding controls nobody can trust yet.

Outcome: Still in progress. The current build has 3-band crossover routing, transient-driven grain scheduling, history/freeze capture, and safe 1x/2x/4x oversampling transitions.

Evidence: Public DSP case study and decision records document architecture, constraints, and validation. Core implementation details are kept private for licensing and commercial release planning.

Known limits: No public benchmark or latency claims yet; still validating consistency and host behavior under broader session conditions.

Audio PluginDSPGranular SynthesisTransient DetectionOversampling

Evidence links:

StringFlux case study Oversampling decision log StringFlux public product page

Case study Product page & beta waitlist

Research Radar

A working prototype for MIR and audio ML papers: ranked emerging and undercited feeds with visible signal breakdowns, plus paper detail, trends, evaluation, and bridge experiments.

Status: Live prototype

Problem: Paper discovery tools often hide the signals behind ranking. I wanted ranked lists where those signals are visible so you can compare versions without guessing what moved.

Constraints: Solo prototype, curated corpus, no human-labeled relevance benchmark, and ranking claims limited to visible signals and baseline comparisons.

Tradeoff: I focused first on saving ranking runs, exposing signal breakdowns, and making the prototype understandable before pushing harder on more experimental ranking ideas.

Outcome: The current prototype has working emerging and undercited feeds, paper detail with similar papers, a trends view, an evaluation page for comparing output against simple baselines, and a separate bridge experiment.

Evidence: The strongest stable claim today is that the prototype makes its ranking behavior visible and understandable over a curated set of MIR and audio ML papers.

Known limits: Bridge is an experimental view separate from the main recommender; semantic similarity only appears in runs where the UI labels it; the corpus is still narrower than the long-term plan.

Next.jsFastAPIPostgrespgvectorPythonRanking

Evidence links:

Research Radar case study Research Radar source repo Reviewer brief and proof map

Case study Try live demo Code

Personal Site

This site. Next.js 16 with MDX blogging, a contact form that sends email through Resend and falls back gracefully when the database is down, and a GitHub OAuth admin inbox for managing submissions.

Status: Operational

Problem: GitHub alone was a weak container for case studies, limits, and proof links. I also needed contact that survives spam without turning into ops work, plus a stack I could iterate on without fearing every deploy.

Constraints: Solo project, so operational overhead had to stay low. No dedicated backend: managed services (Resend for email, Upstash for rate limiting, Neon for Postgres) handle the heavy parts.

Tradeoff: Server Actions plus Resend, Upstash, and Neon keep the solo-operator footprint small; the trade is accepting vendor-shaped limits I can live with on a personal site.

Outcome: Live at mmaitland.dev with honeypot + Redis rate limiting on contact, GitHub OAuth admin gating, and MDX blog with draft protection.

Evidence: Production safeguards are documented in a public case study and decision record, with CI and smoke tests in the repository.

Known limits: Some route-level dynamic behavior remains broader than needed and will be narrowed in later optimization work.

Next.jsTypeScriptTailwind CSSPrismaAuth.jsUpstashMDX

Evidence links:

Personal site case study Contact decision record Route smoke tests

Case study Code

Full Swing Technical Support

My day job. I work at Auxillium supporting Full Swing simulator customers remotely. Many setups also run Laser Shot or E6 Golf from TruGolf, which I support on the same tickets. This case study documents the triage approach I've built from that work.

Status: Operational

Problem: Simulator issues rarely have one cause. A customer reports "the ball isn't tracking" and the root cause could be calibration drift, a licensing timeout, a network config problem, or a Windows update that broke a driver.

Constraints: Remote support, incomplete logs, frustrated users, mixed hardware/software/network symptoms, and privacy limits on public evidence.

Tradeoff: More time upfront on isolation and logging pays back when the same failure signature shows up again: you reopen the checklist instead of re-deriving the path from memory.

Role: Technical support specialist at Auxillium. Scope is Full Swing simulator deployments plus Laser Shot and E6 Golf from TruGolf when those are part of the install.

Outcome: Built repeatable triage workflows that I now use across calibration, licensing, display, networking, and OS subsystems. Documented publicly as a case study.

Evidence: Public case study includes workflow artifact, representative incident pattern, and troubleshooting playbook linkage.

Known limits: Customer-identifying details and hard incident counts are intentionally excluded due to privacy and support constraints.

Technical SupportTroubleshootingWindowsNetworkingHardware/Software Integration

Evidence links:

Full Swing case study Troubleshooting playbook

Case study

Experiments

Interactive experiments and small-scope builds used to explore implementation patterns, runtime behavior, and tradeoffs.

PythonMachine LearningCNN

Snake Detector

Narrow snake vs no-snake computer vision with a reproducible evaluation workflow, explicit limits, and a public case study plus training repo.

Status: Operational

Evidence: case study / repo

PythonMachine LearningCNNComputer Vision

Evidence links:

Snake Detector case study Training repo

Try live demo Case study Code

Sample Library Organizer

A PyQt5 desktop app (Musicians Organizer) for large local audio libraries: recursive scanning, SQLite persistence with SQLAlchemy Core and Alembic migrations, filtering and multi-dimensional tagging, duplicate detection, background audio-feature extraction, similarity-style recommendations, and waveform/spectrogram preview in the app.

PythonPyQtSQLiteAudio

Code