Which framework does it use?

React, with project UI helpers and browser Web Audio support for the optional stream path. The workflow begins with your repository and adapts imports and styling to it. A standalone HTML version is an additional adaptation when requested.

Does it call an audio or AI service?

No service is called by the supplied visualizer. Demo values are generated locally, and the real-audio path analyzes a MediaStream supplied by the app. Recognition, model responses and any network connection belong to a separate integration.

Can I change the appearance?

Yes. Bar count, height limits and alignment are props; colors, radius and spacing live in the source and shared styling. Check those hardcoded utility classes as well as theme tokens, particularly the bars’ minimum width on phones.

Are moving bars proof that audio is being heard?

No. Demo mode synthesizes values and the example enables it. A genuine listening indicator needs the app’s real stream and state, with demo mode disabled.

Is this a measurement-grade spectrum display?

No. It groups normalized audio values into visual bands without calibrated frequency labels. Use it for interface feedback, not as evidence of a precise acoustic measurement.

Spectrum Monitor Chart

Previews from the publisher

Show a voice interface’s changing state with animated bars. Spectrum Monitor includes a React visualizer and buttons for connection, initialization, listening, speaking and thinking states. It can animate locally generated demonstration values or receive an audio stream, making it a presentation component for an audio experience rather than a complete voice agent.

What you get

A BarVisualizer React component with configurable state, bar count, minimum/maximum height and bottom or center alignment. The example uses twenty bars and five state-selection buttons.
A demonstration mode that generates changing bar heights locally for listening/speaking and uses state-specific highlighting for other phases. This movement does not mean a microphone is active or a real agent is answering.
Web Audio helper hooks that can analyze a supplied MediaStream into normalized volume bands. Stream capture and application state must be connected by the surrounding app; there is no built-in speech recognition or assistant backend.
Editable source and a visual guide for palette, type, radius, icons and motion, with utility-class styling and project UI imports to adapt to your repository. Bar count and sizing remain configurable for the available space.

Before you choose

Choose this when users need feedback about a voice interaction’s state. First establish which events actually mean connecting, listening or speaking in your app, then drive the bars from those events. The most useful improvement is truthful feedback: animation should not suggest a live microphone or reply when only a local demo is running.

Good fit

A voice-assistant or audio prototype that needs visible listening, working and replying states.
A page where the visualizer’s colors and spacing can be aligned with the existing interface without building the bar animation from scratch.
A developer who wants readable source and control over state/audio integration, rather than a packaged full voice service.

Not for

A complete page with navigation, forms, authentication or checkout, or an agent that captures and understands speech by itself.
A calibrated spectrum analyzer with labeled frequencies and measured engineering accuracy.
A maintained npm package or automatic fit to a mature design system. Project helpers, styles, motion and bar sizing need integration review.

How to use

You say

/data-visualization-spectrum-monitor Add the Spectrum Monitor Chart component to my dashboard using the data I provide. Inspect the existing page and framework before integrating it; ask for missing data rather than inventing values.

Inspect the target React project and its UI/button/card helpers before copying the visualizer and demo. Identify where the component belongs in the actual voice flow and which real application states should drive it.
Begin with demo mode to check layout and labels without capturing audio. Map the five state buttons to meaningful user-facing terms and distinguish a visual demonstration from actual connection or processing status.
For real audio, obtain the appropriate MediaStream in the surrounding app, pass it to the visualizer and turn demo mode off. Handle permission denial, silence and stream changes there; the component does not request microphone access itself.
Align colors, radius and spacing with the visual guide and choose a bar count that fits the container. Bars have minimum widths, so a large count can clip at narrow widths. Review animation and provide a reduced-motion behavior suitable for the product rather than assuming one is included.
Test every state and the transition between demo, real audio and no stream. Review phone-width labels, keyboard access to the buttons, animation cleanup and behavior after leaving the page. Run project type/build checks; for a real integration, verify that the displayed state reflects actual application behavior rather than an unrelated timer.

Requirements and costs

You bring: Not collected yet
Dependencies: Not collected yet
Outside costs: Not collected yet
Publisher testing: v1.0.0 — Claude Code / Claude Desktop / Cowork / Codex / ChatGPT