내부 신호를 보여주는 브라우저 오디오 작업 공간을 구축한 이유

작성자

카테고리:

← 피드로
DEV Community · BIFROST · 2026-07-24 개발(SW)

BIFROST

Fixed audio tracks are convenient, but they hide almost every decision from the listener. You press play and receive a finished result. You cannot inspect the carrier frequencies, see the beat difference, or change the signal while it is running.

That lack of visibility was the reason I started building BIFROST.

BIFROST is a browser-based workspace that generates binaural audio and amplitude modulation in real time. It is not a medical device, and I am not claiming that a particular frequency produces a guaranteed effect. My goal is narrower: give people direct control over the audio signal and make the current state understandable.

The design problem

I wanted the experience to answer three questions without forcing the user to trust a black box:

  1. What is being generated right now?
  2. Which values can I change while listening?
  3. Can I combine the generated signal with audio I already have?

The browser is a useful place to explore this because the Web Audio API provides oscillators, gain stages, filters, channel routing, and real-time parameter changes without requiring a native installation.

It also creates constraints. Audio contexts have lifecycle states. Mobile operating systems may suspend work when an app moves into the background. Media playback and generated audio do not always behave identically across browsers. Those constraints have shaped the interface as much as the sound engine itself.

Making the signal visible

The central UI element is the Live Monitor. It displays internal application values including:

  • left and right carrier frequencies
  • the difference between the carriers
  • carrier and background signal state
  • active playback state

This is intentionally not a measurement of the body or the brain. It is a view into what the application is doing.

That distinction matters. Audio tools can easily drift into language that implies more certainty than the software can support. I would rather show the generated values clearly and let users evaluate the experience for themselves.

Local audio as part of the workspace

BIFROST can load local audio files into its internal player and combine them with the generated signal. I added this because many people already have music, ambient recordings, or spoken audio that fits their routine. A useful tool should not require replacing everything they already listen to.

The difficult part was not adding another play button. It was keeping transport state, generated audio, routing, and the visible monitor understandable as one system.

Why the interface matters

Many audio utilities are technically capable but unpleasant to use. Others are visually polished but reveal almost nothing about the signal path.

I am trying to find a middle ground:

  • enough control for meaningful experimentation
  • enough visibility to understand the current state
  • a free path so people can try the core experience
  • no automatic billing after the five-day full-access trial

The product is still evolving. The next decisions should be driven by real use, not by adding controls simply because the audio engine can support them.

What I am looking for

I would value direct feedback from web and audio developers:

  • Is the Live Monitor understandable at first glance?
  • Which controls feel essential?
  • Where does the interface expose too much complexity?
  • What browser or device behavior should I test more aggressively?

You can try BIFROST at bifrostaudio.com. The core tools have a free tier, and the trial does not require a credit card.

I will share the implementation decisions, browser constraints, and mistakes as I continue building it.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다