Hi! Quill’s global system tap keeps the recording flow wonderfully simple, but it also captures unrelated audio such as notification sounds, music, and other apps running during a meeting.
Would you be open to a focused per-app capture option?
My proposed scope:
- keep All system audio as the default, preserving today’s behavior
- add a small Capture audio from submenu listing eligible running apps
- allow selecting one app before recording starts
- build the system track from that app’s Core Audio process output instead of the global mix
- store the selected capture scope in
meta.json for traceability
- fail visibly if the selected app is unavailable when recording starts, rather than silently falling back to all system audio
- keep transcription, diarization, and existing recording output otherwise unchanged
The main case would be recording Zoom, Teams, or a browser call without also capturing Spotify or notification sounds. Core Audio’s process-tap APIs appear to support the underlying scoped mix directly, so this should remain local and avoid new dependencies.
I’d start with one selected application or the existing global mode, then treat browser helper processes and app restarts as explicit test cases before expanding the UX.
Happy to put together a small implementation with focused selection/resolution tests if this direction fits the project. Thanks!
Hi! Quill’s global system tap keeps the recording flow wonderfully simple, but it also captures unrelated audio such as notification sounds, music, and other apps running during a meeting.
Would you be open to a focused per-app capture option?
My proposed scope:
meta.jsonfor traceabilityThe main case would be recording Zoom, Teams, or a browser call without also capturing Spotify or notification sounds. Core Audio’s process-tap APIs appear to support the underlying scoped mix directly, so this should remain local and avoid new dependencies.
I’d start with one selected application or the existing global mode, then treat browser helper processes and app restarts as explicit test cases before expanding the UX.
Happy to put together a small implementation with focused selection/resolution tests if this direction fits the project. Thanks!