MyGo 云音乐
Go와 MyGo로 만든 서드파티 네이버 클라우드 뮤직 데스크톱 클라이언트
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.README 전문 보기 ↗Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.
/prerendered volume), legacy /{lang}/… and slug URLs get 301sRequires Bun >= 1.2.
bun install
bun run dev
Dev server starts on localhost:3001, proxying API requests to the backend at localhost:3000.
| Command | Description |
|---|---|
bun run dev | Start Vite dev server |
bun run build | Production build to build/ |
bun run preview | Preview production build locally |
bun run test | Run tests (Vitest) |
bun run test:e2e | Playwright end-to-end tests (needs the backend on :3000) |
bun run test:stress | Many-singer stress test, see below |
bun run test:stress puts a dozen singers into one party: real Chrome contexts
with a fake microphone, each running the whole pipeline (AudioWorklet → ONNX
pitch worker → WebSocket), the first one hosting. Every browser carries an
in-page monitor, and the run ends with a per-client table (frame rate, long
tasks, JS heap, notes in/out, latency) plus assertions that nobody
disconnected, everyone is on the scoreboard, the singers' notes reached the
host and the host stayed above MIN_FPS. Past eight singers the server puts
only eight on screen (three top scores pinned, five lanes rotating one per
lyric line), so from then on the host hears the lanes rather than everyone,
and the run prints who they were.
| Env | Default | Meaning |
|---|---|---|
REAL_SINGERS | 12 | Chrome contexts (incl. the host) |
BOT_SINGERS | 0 | extra synthetic singers driven from Bun over WebSocket (e2e/wsSinger.js), cheap enough for dozens |
STRESS_SECONDS | 30 | how long everyone sings |
MIN_FPS | 20 | host frame-rate threshold |
CPU_THROTTLE | 1 | DevTools-style CPU slowdown for every real browser: 4 ≈ mid-range phone, 6 ≈ an old low-end one |
Serve the production build for realistic numbers (bun run build && bunx vite preview;
the test reuses whatever is on :3001), because React's development runtime
alone dominates a profile. Emulating an old phone with a dozen singers:
REAL_SINGERS=1 BOT_SINGERS=11 CPU_THROTTLE=6 bun run test:stress.
Mind what you are measuring: every real context runs its own ONNX pitch
worker and YouTube player, so a dozen of them on one laptop saturate the CPU
and every client (host included) stalls — the run then prints a warning that
the host video stopped advancing. That measures the machine, not the app. To
measure the frontend's cost of rendering many singers, keep the real
browsers few and add bots: REAL_SINGERS=2 BOT_SINGERS=40 bun run test:stress.
docker build -t singspree-fe .
docker run -p 80:80 singspree-fe
Multi-stage build: Bun 1 Alpine for bun install --frozen-lockfile && bun run build, then Nginx Alpine to serve the static files. The build stage is deliberately not cached in CI -- installing takes about eight seconds, and caching it meant pulling a 577 MB node_modules layer out of the GitHub Actions cache first.
src/
components/ UI components (MusicBars, Lyrics, ShareCard, ...)
logic/ Pitch detection, mic input, lyrics parsing, WebSocket handling
pages/ Route pages (Entry, Party, Join, compliance pages)
i18n/locales/ 21 locale JSON files
index.css Tailwind v4 theme (neon-cyan, neon-purple, neon-magenta, neon-green)
MIT