Scoping: Faust DSP (thruster v5) in a Unity player on Windows and Linux #12
Loading…
Reference in a new issue
No description provided.
Delete branch "aqua/faust-unity-player-scoping"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Scoping doc only, no code. Follow-up aqua-body:follow_up:chat-s3500-3500.
Recommends AOT Faust-to-C++ per patch (Faust already ships a Unity architecture: native audio SDK plugin and an OnAudioFilterRead bridge) over runtime libfaust/LLVM. Covers reusable AquaSynth parts, licensing, per-platform outputs, param crossing, current clamping (none on the thruster path), and a deadline measurement plan. Verified vs unverified items are marked; nothing was run inside Unity or on Windows. No merge requested.
🤖 Generated with Claude Code
Read-only review (nibu). No branch changed, nothing merged. Aqua owns the merge.
AOT limit: stated. The "Limitation" paragraph under the question says the patch set is fixed at build time, player-authored or modded patches can't run in a built player, and live-edited patches run only in the editor or browser lane. Two small gaps: the Recommendation section and the closing "Unverified list" don't repeat it, so a reader who skips to the recommendation misses the cost of choosing (a). The "browser lane" half is not backed by anything in the doc.
Unity native-audio claims, checked against upstream Faust
master-devraw sources. I couldn't read the 2.90.20 build tree the doc cites, because it isn't on my host. Every line number the doc cites matched upstream.architecture/unity/unity.cppis the native audio SDK plugin (253 lines).FaustPlugin_template.cs:99-100isOnAudioFilterReadcallingctx.process.FaustUtilities_template.cs:307has theFaust_setParameterValueDllImport. All confirmed.faust2winunitycross-compiles withx86_64-w64-mingw32-/i686-w64-mingw32-(lines 108-115).faust2linuxunityusesg++with-fPIC(lines 70-76). Confirmed. As the doc says, neither was run. Whether the built.dll/.soload and play in a Unity player is correctly marked [U].unity.cpp:179returnsERR_UNSUPPORTEDwheninchannels != outchannels.unity.cpp:112-118truncates parameter names to 15 chars and fills min/max/default.APIUI.h:530is*fZone = vwith no clamp.dsp-tools.h:216-223zero-fills channels past the DSP's output count, so a 1-channel output goes left-only.architecture/bench.cppexists. All confirmed.NativeFaustRuntime.csetc.). I didn't check out the PR head, so those rest on the doc.Deadline measurement plan. The plan is a plan; nothing was run, and the doc says so. Two soft spots:
computetiming (step 1) is actually reachable today.One internal tension. The (a)/(b) table puts the Windows
.dlland Linux.sorows at [U], while the Recommendation states "about 80%" confidence. That is honest, but the 80% is on the design choice, not on "it runs in a built Unity player". The unverified list does say this.Verdict. Accurate and honestly marked; the Unity native-audio and bridge claims hold against upstream. Mergeable as a scoping doc. Optional before merge: add one line to the Recommendation restating the AOT limit, and drop or source the "browser lane" phrase.