Skip to content

Add sound effects mode for subtle notifications #16

Open

Description

@Helmi

Description

Add sound effects as a subtle alternative to TTS notifications. Instead of voice announcements, users can opt for discrete audio cues (chimes, tones, beeps) that convey event information without being intrusive or requiring verbal processing.

Context

  • Project area: Core notification system (src/ccnotify/notify.py, src/ccnotify/config.py)
  • Complexity assessment: 6/10 (moderate - new provider pattern, sound research, config integration)
  • Current behavior: TTS or macOS system sounds only
  • Goal: Less obtrusive notification option while maintaining information value

Technical Details

Affected files:

  • src/ccnotify/notify.py - Add sound effects mode to NotificationHandler
  • src/ccnotify/config.py - Extend configuration with sound effects options
  • src/ccnotify/tts/ - Possibly new sound effects provider or extend existing pattern
  • sounds/ or assets/sounds/ - New directory for default sound library
  • pyproject.toml - Possibly new dependencies for sound generation

Current Architecture Integration:

  • ✅ pydub already in use for audio processing
  • ✅ play_sound_file() method exists for audio playback
  • ✅ Config system supports structured options (notifications.sound_enabled)
  • ✅ TTS provider pattern can be extended for sound effects

Sound Strategy Research

Option 1: Pre-built Sound Library

  • Freesound.org: Creative Commons licensed sounds, professional quality
  • Mixkit: 36 free notification sounds, royalty-free
  • Pixabay: No attribution required, good selection

Option 2: Programmatic Generation

  • pydub + numpy: Generate consistent tones/chimes
  • Event-specific frequencies: Different tones for different event types
  • Procedural sounds: Ensures consistency and small footprint

Option 3: Hybrid Approach (Recommended)

  • Curated high-quality sounds for key events (error, completion, input needed)
  • Generated sounds for less common events
  • User customizable through config

Requirements

Core Functionality

  1. Configuration option to enable sound effects mode instead of TTS
  2. Event-specific sound mapping - different sounds for different event types:
    • tool_activity - Subtle click or soft chime
    • execution_complete - Success chime
    • error - Alert tone (not harsh)
    • input_needed - Attention tone
    • subagent_done - Completion beep
  3. Sound volume control via configuration
  4. Fallback to system sounds if sound effects unavailable

Advanced Features

  1. Custom sound files - users can provide their own sounds
  2. Sound themes - different sound palettes (minimal, professional, playful)
  3. Programmatic generation for consistent sound design
  4. Caching system similar to TTS caching for generated sounds

Implementation Steps

  • Research and select initial sound library (CC licensed)
  • Decide between extending TTS provider pattern vs. separate sound effects system
  • Add configuration options for sound effects mode
  • Implement sound effects handler with event mapping
  • Add programmatic sound generation capabilities (optional)
  • Create default sound library with appropriate licensing
  • Update configuration documentation
  • Test cross-platform compatibility (macOS focus, Linux consideration)

Acceptance Criteria

  • Users can enable sound effects mode instead of TTS via configuration
  • Different sound effects play for different event types
  • Sound effects are subtle and non-intrusive
  • Volume is configurable
  • System falls back gracefully if sounds unavailable
  • Performance impact is minimal (sounds cached/pre-loaded)
  • Cross-platform compatibility maintained (at least macOS)
  • Documentation updated with new configuration options

Benefits

  • Reduced cognitive load: Audio cues vs. verbal processing
  • Better for shared spaces: Less intrusive than voice announcements
  • Faster recognition: Brief sounds vs. full sentences
  • Accessibility: Works well alongside other audio (music, calls)
  • Customization: Users can adjust to their preference/environment

Activity

  1. Helmi commented on Sep 22, 2025

    @Helmi
    OwnerAuthor

    Event Categorization for Sound vs TTS

    Based on further discussion, here's the refined approach for which events should use sound effects vs TTS:

    Keep TTS (Attention needed - project context is critical)

    • Full completion - Project name helps identify where to look
    • Input needed - Need to know what's being requested and in which project
    • Error - Need to know what failed and where

    Use Sound Effects (Status/background events)

    • Subagent finished - Simple status update
    • Subagent started - Background process notification
    • Some tool uses - Possibly certain MCP servers being used
    • Compaction - Background process (if filterable)

    Stay Silent (Already filtered by smart filtering)

    • Most bash commands - Routine operations
    • Most tool uses - Non-critical tool usage

    Key Principle

    If attention is needed, the project name is an important signal on where to look - use TTS. For background status events, subtle sounds are sufficient.

    This approach maximizes the benefit of both:

    • TTS: Provides context when you need to act
    • Sound effects: Gives status awareness without interruption
    • Silence: Eliminates noise from routine operations

    The smart filtering from #14 already handles the "stay silent" category perfectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions