Real-time guitar audio
Amp and effects processing through the Python audio engine.
Flagship project
An end-to-end desktop guitar practice platform that brings real-time audio processing, tablature, practice feedback and media workflows into a single application.

I designed and implemented the application’s core software systems, including the Electron interface, Python audio-engine integration, practice tooling, runtime packaging, performance work and security hardening.
Guitar practice often requires separate tools for tablature, amplification, effects, metronome control, media playback and performance feedback. GuitarSense combines these workflows in a desktop application designed around active practice.
Practice workflows were fragmented across multiple applications. Real-time guitar audio and synchronized tablature needed to coexist without making the interface feel delayed, desktop distribution required Python and native audio dependencies to work outside the development environment, and imported media and project files required clear trust boundaries.
Amp and effects processing through the Python audio engine.
Playback, editing, tempo control, offset handling and count-in workflows.
Pitch-aware note validation, accuracy, score and streak tracking.
Local media and YouTube-oriented import workflows.
Packaged Windows beta with separated runtime responsibilities.
Runtime validation, constrained project-file access and rollback-aware installation.
Selected interfaces showing how GuitarSense brings audio, practice and media workflows into one desktop application.
Custom presets combine output control, tone-analysis settings and an editable effects chain that can be reused during practice.

Local and YouTube-oriented workflows expose core, live-audio and AI runtime readiness instead of assuming every dependency is already installed.

Audio behavior was evaluated across multiple backend and buffer configurations. In a tested 64-sample configuration, the backend reported approximately 6 ms with ASIO and approximately 46 ms with WASAPI.
These are backend-reported values from tested configurations, not laboratory-measured end-to-end round-trip latency.
High-frequency playback and accuracy updates initially caused unnecessary rendering work. The practice view was moved toward event-driven updates, throttled realtime data and transform-focused visual movement.
The desktop build separates core, live-audio and AI runtime responsibilities. Runtime installation includes validation, staging, backup and rollback behavior rather than assuming development-machine dependencies exist.
Navigation, project-media access, runtime resolution and imported files were constrained with fail-closed policies, path validation, containment checks and safer child-process environments.
Test configuration interface
