Music Gpt Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for audio/AI features. This package buys you integration surface for an external AI audio vendor (Music GPT): music generation from prompts, AI voice covers, text-to-speech with voice cloning, stem extraction, voice catalog browsing, and async job/conversion tracking. If any of those are on your roadmap, adopting the SDK removes the "write an HTTP client + DTOs + error handling" workstream and turns it into a vendor evaluation instead.
• Feature scoping for a v1. Because every endpoint is exposed, you can ship one narrow capability (e.g. TTS or stem extraction) as a beta without committing to a music-generation UX. Useful for validating demand before investing in asset storage, moderation, and billing flows.
• Roadmap sequencing input. The feature list maps cleanly onto cost/complexity tiers: TTS and voice search are cheap to ship; stem extraction and voice covers imply file upload pipelines, storage costs, and longer async job handling; music generation implies rights/licensing review. This helps decide what order things land in.
• Platform standardization risk. ⚠️ This is a Symfony bundle, not a Laravel package. It targets Symfony ^7.0 || ^8.0 with autowiring/DI, and requires PHP >= 8.4. There is no Laravel service provider, facade, or publishable config. For a Laravel codebase this is not a drop-in — it is at best a reference implementation or a component you'd wrap manually. That is a first-order product/platform decision, not a detail.
• Buy-side diligence trigger. The release is a good prompt to price out the underlying API (per-call costs for generation, TTS characters, stem extraction minutes) before any roadmap commitment, since the SDK itself is free but the vendor is not.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is Symfony 7/8 on PHP 8.4+ (or you are willing to hand-roll a thin adapter around the underlying API for a Laravel app).
• AI audio is a differentiator or a validated request, not a speculative "we should have AI" checkbox.
• You are comfortable with a hard dependency on a third-party SaaS API for a user-facing capability, including its uptime, pricing changes, and content/licensing terms.
• You can absorb 0.x churn: this is 0.1.0, and semver permits breaking changes in minor releases. Treat the public API/DTO shapes as unstable.
• You can accept PHP 8.4 — still uncommon on managed hosts and CI images; verify your runtime, Docker base image, and any legacy dependencies that cap PHP.

Look elsewhere or build in-house when:

• You are on Laravel or plain PHP without Symfony DI — the integration ergonomics evaporate; you'd essentially be reimplementing the client.
• You need self-hosted or on-prem audio processing, or your data policy forbids uploading user audio/PII to a third party.
• You need guaranteed SLAs, rate-limit handling, queue/retry orchestration, webhooks, or cost controls — none of these are mentioned in the release notes. Plan to build a job layer around it regardless.
• Audio rights, voice-cloning consent, and provenance/disclosure are unresolved in your org — those are product/legal blockers the SDK cannot solve.
• You need a stable, supported dependency for a revenue-critical path. At 0.1.0 with a single maintainer, bus factor is the concern.

How to Pitch It (Stakeholders)

For executives (one paragraph): A new open-source PHP package gives us a ready-made integration to an AI audio provider covering music generation, voice covers, text-to-speech, and stem extraction. The upside is speed: it could let us prototype an audio feature in days instead of weeks, and it costs nothing to license. The caveats are that it is a first, pre-1.0 release, it is built for Symfony rather than our Laravel stack, and it requires PHP 8.4. The real commitment is to the paid API behind it, not the code. Recommendation: approve a short, time-boxed spike to validate vendor quality, per-unit cost, and licensing before any roadmap placement — do not yet treat this as a production dependency.

For engineering (bullets):

• Composer package: yoanbernabeu/music-gpt-bundle. Requires PHP >=8.4, Symfony ^7.0 || ^8.0. Not a Laravel package — no service provider, facade, or config publish; budget an adapter layer if we adopt on Laravel.
• Surface area: music generation, voice covers (pitch control), TTS + voice cloning, stem extraction, voice search, and async conversion status/result retrieval. Type-safe DTOs, enums, interfaces; PHPStan max, PHPUnit, PHP-CS-Fixer — quality signals are good for a 0.x.
• Wrap it. Put our own interface in front of it (e.g. an AudioGenerator contract) so vendor and package swaps are cheap. Keep DTOs out of our domain layer.
• Operational gaps to fill ourselves: job queueing/retries, rate limits, timeouts, idempotency, file storage/lifecycle for uploads and outputs, cost instrumentation, and webhook or polling strategy for long-running conversions.
• Unknowns to confirm in the spike: API pricing and quotas, upload size limits, retention/data-handling policy, voice-cloning consent requirements, output licensing for commercial use, and library license compatibility.
• Pin the version and expect breaking changes on the path to 1.0; do not adopt ^0.1 loosely.