Shipping a Tauri desktop shell wrapping a Python/PyTorch inference backend is tricky to get right across platforms. A few thoughts and questions on the packaging and runtime side:
- Sidecar packaging vs portable runtime: Are you bundling a frozen Python environment with PyTorch/CUDA embedded in the native installer, or bootstrapping wheels on first launch? Bundling torch + CUDA binaries easily pushes installers past 2-3GB, whereas bootstrapping requires reliable network access on end-user machines.
- Peak memory on 6-stem Demucs: Running htdemucs_6s with default segment sizes and shifts can spike VRAM/RAM pretty heavily on longer tracks. Are you dynamically clamping the segment window or chunk overlap when falling back to CPU or 4GB/6GB consumer GPUs?
- Localhost port collisions: Using FastAPI over a fixed localhost port often runs into conflicts with other local dev tools or corporate firewall/VPN endpoint blockers. If you ever hit that, switching the Tauri-to-Python IPC to named pipes (Windows) / domain sockets (Unix) or dynamically negotiating an ephemeral loopback port saves a ton of support headaches.
Great work putting this together. Having zero-cloud, zero-telemetry local audio processing in a clean native UI is a huge win.
- Sidecar packaging vs portable runtime: Are you bundling a frozen Python environment with PyTorch/CUDA embedded in the native installer, or bootstrapping wheels on first launch? Bundling torch + CUDA binaries easily pushes installers past 2-3GB, whereas bootstrapping requires reliable network access on end-user machines.
- Peak memory on 6-stem Demucs: Running htdemucs_6s with default segment sizes and shifts can spike VRAM/RAM pretty heavily on longer tracks. Are you dynamically clamping the segment window or chunk overlap when falling back to CPU or 4GB/6GB consumer GPUs?
- Localhost port collisions: Using FastAPI over a fixed localhost port often runs into conflicts with other local dev tools or corporate firewall/VPN endpoint blockers. If you ever hit that, switching the Tauri-to-Python IPC to named pipes (Windows) / domain sockets (Unix) or dynamically negotiating an ephemeral loopback port saves a ton of support headaches.
Great work putting this together. Having zero-cloud, zero-telemetry local audio processing in a clean native UI is a huge win.