Building serious audio software requires making a set of architectural choices that will remain with a project for years. Digital signal processing code tends to outlive user interfaces, frameworks, and even the products in which it was originally written. A good oscillator, filter, dynamics processor, resampler, or modulation system may eventually appear in a synthesizer, an audio effect, a web application, a native plugin, a testing environment, or a completely different product.<\/p>\n\n\n\n
That is the premise behind KahuStack DSP.<\/p>\n\n\n\n
Rather than building DSP separately for every product, KahuStack DSP is being developed as a reusable audio-processing foundation for MANA Synth, Voxaliber, future KahuStack audio products, experimental processors, web applications, and potentially native plugin environments.<\/p>\n\n\n\n
Three technologies are particularly important to that architecture:<\/p>\n\n\n\n
Rust, WebAssembly, and Faust.<\/strong><\/p>\n\n\n\n They each solve a different problem.<\/p>\n\n\n\n Rust provides the systems architecture.<\/p>\n\n\n\n Faust provides a specialized language for expressing DSP algorithms.<\/p>\n\n\n\n WebAssembly provides a portable execution target capable of bringing high-performance DSP into browsers and other sandboxed environments.<\/p>\n\n\n\n The interesting part is not any one of these technologies individually. The real advantage comes from using them together while keeping clear boundaries between their responsibilities.<\/p>\n\n\n\n The emerging KahuStack DSP model can be summarized roughly as:<\/p>\n\n\n\n DSP mathematics \u2192 Faust and\/or Rust implementation \u2192 Rust library architecture \u2192 WebAssembly\/native compilation \u2192 applications and test environments<\/strong><\/p>\n\n\n\n Faust is used where its declarative DSP model provides a meaningful advantage.<\/p>\n\n\n\n Rust is the primary integration and systems language.<\/p>\n\n\n\n WebAssembly is the primary portable deployment target, particularly for the web.<\/p>\n\n\n\n The same underlying library should remain usable by native hosts rather than becoming fundamentally dependent on browser technology.<\/p>\n\n\n\n This distinction is important.<\/p>\n\n\n\n KahuStack DSP is not intended to become a collection of unrelated Faust programs wrapped in JavaScript.<\/p>\n\n\n\n It is also not intended to become a massive Rust codebase in which every DSP primitive must be manually implemented even when a specialized DSP language would express it better.<\/p>\n\n\n\n Instead, we are creating a layered library where each technology is used where it is strongest.<\/p>\n\n\n\n Rust is becoming the architectural center of KahuStack DSP.<\/p>\n\n\n\n That does not mean Rust necessarily needs to implement every sample-by-sample DSP algorithm. It means Rust provides the framework in which those algorithms live.<\/p>\n\n\n\n This distinction is one of the most important architectural decisions in the project.<\/p>\n\n\n\n Audio processing is unusually sensitive to runtime behavior.<\/p>\n\n\n\n Real-time DSP cannot tolerate unpredictable pauses caused by garbage collection. An audio callback that stalls for even a few milliseconds can result in clicks, dropouts, or complete buffer underruns.<\/p>\n\n\n\n Traditionally, this has made C and C++ the dominant languages for professional audio development.<\/p>\n\n\n\n Rust offers something unusual: memory safety without requiring a garbage-collected runtime.<\/p>\n\n\n\n That provides many of the advantages associated with systems languages while eliminating entire categories of defects associated with unmanaged memory.<\/p>\n\n\n\n Rust’s ownership and borrowing system can prevent problems such as:<\/p>\n\n\n\n For a growing DSP library, this matters considerably.<\/p>\n\n\n\n A synthesizer with hundreds of voices, modulation connections, effect processors, buffers, worker systems, and state transitions can become extremely difficult to reason about in conventional C++.<\/p>\n\n\n\n Rust pushes many of those correctness constraints into the compiler.<\/p>\n\n\n\n KahuStack DSP is increasingly interested in strongly typed representations of DSP concepts.<\/p>\n\n\n\n Audio software frequently represents very different quantities using the same primitive type:<\/p>\n\n\n\n Those values might mean:<\/p>\n\n\n\n To a floating-point number, they are all identical.<\/p>\n\n\n\n To an audio system, they are completely different concepts.<\/p>\n\n\n\n Rust is particularly well suited to building strongly typed domain APIs around quantities such as:<\/p>\n\n\n\n This makes invalid operations harder to express.<\/p>\n\n\n\n Instead of relying on developer discipline to remember whether a parameter is normalized, logarithmic, measured in samples, or measured in seconds, the type system can represent that information directly.<\/p>\n\n\n\n This is already becoming an important design principle in KahuStack DSP.<\/p>\n\n\n\n The larger advantage of Rust is not merely safer code.<\/p>\n\n\n\n It gives KahuStack DSP a coherent library architecture.<\/p>\n\n\n\n A professional DSP system needs considerably more than the processor itself.<\/p>\n\n\n\n It needs:<\/p>\n\n\n\n Rust can provide that infrastructure while individual DSP implementations remain replaceable.<\/p>\n\n\n\n A compressor implemented today can eventually be optimized without changing every application that consumes it.<\/p>\n\n\n\n A filter may begin as a conventional scalar implementation and later gain SIMD processing.<\/p>\n\n\n\n A Faust-generated processor may sit behind the same higher-level Rust API as a hand-written Rust implementation.<\/p>\n\n\n\n That separation is central to the long-term usefulness of the library.<\/p>\n\n\n\n Rust is not free of costs.<\/p>\n\n\n\n Ownership, borrowing, lifetimes, traits, generics, and concurrency rules introduce complexity.<\/p>\n\n\n\n Developers experienced in C++, JavaScript, or Python can initially find Rust slower to work with.<\/p>\n\n\n\n DSP development already requires understanding difficult topics such as numerical stability, real-time constraints, aliasing, and filter topology.<\/p>\n\n\n\n Adding a sophisticated type system increases the conceptual load.<\/p>\n\n\n\n Rust makes expressive type systems possible.<\/p>\n\n\n\n That does not mean every scalar needs to become a deeply generic abstraction.<\/p>\n\n\n\n Audio code must remain understandable.<\/p>\n\n\n\n It is possible to create architectures where the type system becomes more complicated than the DSP itself.<\/p>\n\n\n\n KahuStack therefore needs to use strong typing strategically.<\/p>\n\n\n\n Types such as Creating elaborate abstraction hierarchies around every internal multiplication probably does not.<\/p>\n\n\n\n Large Rust projects can suffer from substantial compile times, particularly when extensive generics, procedural macros, code generation, and large dependency graphs are involved.<\/p>\n\n\n\n KahuStack DSP needs to keep crate boundaries intentional and avoid allowing the library to become monolithic.<\/p>\n\n\n\n JUCE, decades of plugin examples, proprietary DSP SDKs, and many vendor libraries are still centered around C++.<\/p>\n\n\n\n Rust integration with native plugin ecosystems is improving, but using Rust may occasionally require interoperability layers that would not be necessary in an entirely C++ project.<\/p>\n\n\n\n That is a real engineering tradeoff.<\/p>\n\n\n\n WebAssembly addresses a different problem.<\/p>\n\n\n\n Rust helps us build the engine.<\/p>\n\n\n\n WebAssembly helps us deploy it.<\/p>\n\n\n\n The browser is increasingly important to KahuStack’s audio work.<\/p>\n\n\n\n MANA has already demonstrated why.<\/p>\n\n\n\n If a serious synthesizer can run directly in the browser, users can test it instantly without installing software. DSP research can include interactive demonstrations. QA environments can exercise processors visually and audibly. Educational material can contain real implementations rather than screenshots.<\/p>\n\n\n\n WebAssembly makes that possible without maintaining a completely separate JavaScript DSP implementation.<\/p>\n\n\n\n The ideal architecture is not:<\/p>\n\n\n\n with five implementations of the same algorithm.<\/p>\n\n\n\n The goal is closer to:<\/p>\n\n\n\n This substantially reduces algorithm drift.<\/p>\n\n\n\n A filter validated in the web QA environment should be fundamentally the same filter used elsewhere.<\/p>\n\n\n\n A compressor should not behave differently simply because one implementation lives in JavaScript and another lives in a plugin.<\/p>\n\n\n\n WebAssembly provides the bridge that makes this architecture practical.<\/p>\n\n\n\n The browser is more than a deployment platform.<\/p>\n\n\n\n For KahuStack DSP, it can become a development instrument.<\/p>\n\n\n\n The current direction includes a lightweight Vite\/React QA environment capable of exposing processors vertically.<\/p>\n\n\n\n A DSP module can eventually have:<\/p>\n\n\n\n That gives each processor an interactive laboratory.<\/p>\n\n\n\n A developer implementing an allpass filter should be able to compile the library, open the test bench, route audio through it, automate its parameters, examine phase behavior, and listen to it immediately.<\/p>\n\n\n\n WebAssembly makes that experience possible while exercising production DSP rather than a JavaScript approximation.<\/p>\n\n\n\n WebAssembly is particularly attractive for numerical workloads.<\/p>\n\n\n\n It supports:<\/p>\n\n\n\n For many DSP workloads, carefully structured WASM can achieve performance sufficiently close to native code that the architecture becomes practical for sophisticated synthesis and effects.<\/p>\n\n\n\n That includes workloads involving:<\/p>\n\n\n\n Performance still needs to be measured rather than assumed, but WASM is no longer limited to trivial web-audio demonstrations.<\/p>\n\n\n\n WebAssembly also has important limitations.<\/p>\n\n\n\n Native applications have more direct control over:<\/p>\n\n\n\n The browser intentionally restricts many of those capabilities.<\/p>\n\n\n\n That is good for security but can complicate professional audio software.<\/p>\n\n\n\n Calling into WASM for every sample or tiny DSP operation would be a poor architecture.<\/p>\n\n\n\n Data should cross the boundary in relatively large, intentional units.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n is sensible.<\/p>\n\n\n\n Calling JavaScript \u2192 WASM for each individual sample is not.<\/p>\n\n\n\n This strongly influences API design.<\/p>\n\n\n\n Web audio processing generally involves separate execution contexts.<\/p>\n\n\n\n Communication between the UI, workers, AudioWorklet, and WASM engine needs carefully designed messaging and shared-memory strategies.<\/p>\n\n\n\n Poor architecture can erase many of WASM’s performance advantages.<\/p>\n\n\n\n This is another important distinction.<\/p>\n\n\n\n KahuStack DSP should not become architecturally dependent on WebAssembly.<\/p>\n\n\n\n WASM is a target.<\/p>\n\n\n\n The DSP library is the product.<\/p>\n\n\n\n Maintaining that distinction protects native portability.<\/p>\n\n\n\n Faust addresses another layer entirely.<\/p>\n\n\n\n Faust is a domain-specific programming language designed specifically for real-time signal processing.<\/p>\n\n\n\n That matters because DSP contains recurring structures that general-purpose languages do not represent especially elegantly.<\/p>\n\n\n\n Consider a DSP algorithm such as:<\/p>\n\n\n\n In a conventional language, much of the implementation concerns state storage, buffer traversal, sample loops, and plumbing.<\/p>\n\n\n\n Faust allows the developer to describe the signal-processing relationship much more directly.<\/p>\n\n\n\n The compiler handles much of the lower-level implementation.<\/p>\n\n\n\n That makes Faust particularly attractive for a DSP research library.<\/p>\n\n\n\n Academic DSP literature often describes algorithms mathematically.<\/p>\n\n\n\n Turning those equations into production C++, Rust, or WASM requires an additional translation step.<\/p>\n\n\n\n Faust reduces the distance between:<\/p>\n\n\n\n and:<\/p>\n\n\n\n That makes it valuable for experimentation.<\/p>\n\n\n\n A paper describing a nonlinear filter, oscillator, compressor, physical model, or waveshaper can often be prototyped more quickly in Faust than by constructing all of the surrounding infrastructure manually.<\/p>\n\n\n\n That implementation can then become:<\/p>\n\n\n\n Faust is not merely a scripting language.<\/p>\n\n\n\n The Faust compiler can transform DSP definitions into other implementation forms.<\/p>\n\n\n\n For KahuStack DSP, this creates an interesting possibility:<\/p>\n\n\n\n This allows Faust to function as a specialized DSP authoring layer while Rust remains responsible for the larger system architecture.<\/p>\n\n\n\n That distinction prevents Faust from taking over responsibilities it was not designed to solve.<\/p>\n\n\n\n Faust appears especially attractive for processor families such as:<\/p>\n\n\n\n It is also valuable when comparing multiple algorithms.<\/p>\n\n\n\n A research project examining five compressor topologies can implement them in a common DSP language and test them using the same surrounding infrastructure.<\/p>\n\n\n\n Not everything belongs in Faust.<\/p>\n\n\n\n Complex systems involving:<\/p>\n\n\n\n are generally better expressed in a systems language.<\/p>\n\n\n\n That is where Rust takes over.<\/p>\n\n\n\n The boundary might roughly look like:<\/p>\n\n\n\n The exact boundary can vary from processor to processor.<\/p>\n\n\n\n Faust introduces its own risks.<\/p>\n\n\n\n Code generation is useful only when developers understand the resulting system.<\/p>\n\n\n\n A DSP library should not blindly trust generated artifacts.<\/p>\n\n\n\n Generated processors still need:<\/p>\n\n\n\n Debugging handwritten Rust or C++ often means stepping directly through the implementation.<\/p>\n\n\n\n Generated code introduces another layer.<\/p>\n\n\n\n The bug may exist in:<\/p>\n\n\n\n That makes tooling and documentation important.<\/p>\n\n\n\n Every additional language increases project complexity.<\/p>\n\n\n\n Developers now need to understand:<\/p>\n\n\n\n and potentially C\/C++ interoperability.<\/p>\n\n\n\n That cost needs to produce substantial value.<\/p>\n\n\n\n For simple processors, handwritten Rust may occasionally be clearer.<\/p>\n\n\n\n Code generation introduces a repository-management problem.<\/p>\n\n\n\n If generated source is committed, it can become stale.<\/p>\n\n\n\n If generated source is not committed, builds depend on having the correct generator available.<\/p>\n\n\n\n KahuStack DSP needs explicit policies around:<\/p>\n\n\n\n A The architectural argument is ultimately not:<\/p>\n\n\n\n Rust vs. Faust vs. WebAssembly.<\/strong><\/p>\n\n\n\n It is:<\/p>\n\n\n\n Rust + Faust + WebAssembly.<\/strong><\/p>\n\n\n\n Each technology addresses a different layer.<\/p>\n\n\n\n This separation is intentional.<\/p>\n\n\n\n Consider a new analog-modeling filter.<\/p>\n\n\n\n Research may begin with an academic paper.<\/p>\n\n\n\n A Faust implementation can quickly reproduce the proposed signal structure.<\/p>\n\n\n\n The processor can then be compiled into the KahuStack DSP environment.<\/p>\n\n\n\n Rust provides typed controls:<\/p>\n\n\n\n rather than passing arbitrary floating-point values throughout the system.<\/p>\n\n\n\n The processor is exposed through a standardized Rust interface.<\/p>\n\n\n\n Tests measure:<\/p>\n\n\n\n The same implementation is compiled to WebAssembly.<\/p>\n\n\n\n The browser QA application provides:<\/p>\n\n\n\n Once validated, that same DSP module can eventually be consumed by MANA or another application.<\/p>\n\n\n\n The research has moved through an intentional pipeline:<\/p>\n\n\n\n That is considerably more valuable than implementing the same filter directly inside a synthesizer and leaving its knowledge buried there.<\/p>\n\n\n\n This is perhaps the larger architectural point.<\/p>\n\n\n\n KahuStack DSP should not be thought of as a collection of effects.<\/p>\n\n\n\n It is infrastructure.<\/p>\n\n\n\n MANA needs:<\/p>\n\n\n\n Vocal processing tools need:<\/p>\n\n\n\n Future audio applications may need completely different combinations of the same primitives.<\/p>\n\n\n\n If every application reimplements these capabilities independently, development effort grows while consistency declines.<\/p>\n\n\n\n A shared library reverses that equation.<\/p>\n\n\n\n Every new processor potentially strengthens every future product.<\/p>\n\n\n\n One of the more important recent directions in KahuStack DSP is the adoption of semantic DSP units.<\/p>\n\n\n\n Traditional DSP APIs commonly accept values like:<\/p>\n\n\n\n The meaning of these values exists largely in documentation.<\/p>\n\n\n\n KahuStack is moving toward APIs where meaning exists in the type system:<\/p>\n\n\n\n This becomes increasingly important as the library grows.<\/p>\n\n\n\n Time is particularly interesting because audio software operates in several simultaneous coordinate systems:<\/p>\n\n\n\n Confusing two of those can produce bugs that are difficult to diagnose.<\/p>\n\n\n\n A strongly typed architecture makes those mistakes harder to express in the first place.<\/p>\n\n\n\n Rust is particularly effective at supporting this design.<\/p>\n\n\n\n No language or framework automatically produces good DSP.<\/p>\n\n\n\n A Rust program can still allocate memory in the audio thread.<\/p>\n\n\n\n A Faust processor can still contain an unstable algorithm.<\/p>\n\n\n\n A WebAssembly processor can still miss its audio deadline.<\/p>\n\n\n\n Therefore KahuStack DSP needs to evaluate every implementation against real-time requirements.<\/p>\n\n\n\n That includes questions such as:<\/p>\n\n\n\n Architecture assists these decisions.<\/p>\n\n\n\n It does not replace them.<\/p>\n\n\n\n The accompanying QA test bench is an important part of this development model.<\/p>\n\n\n\n DSP should not be considered complete simply because it compiles.<\/p>\n\n\n\n Every processor should ultimately be testable vertically:<\/p>\n\n\n\n This dramatically reduces the distance between implementation and evaluation.<\/p>\n\n\n\n It also makes research reproducible.<\/p>\n\n\n\n A future article explaining a compressor topology could eventually embed the actual KahuStack implementation and allow the reader to hear it.<\/p>\n\n\n\n That is an unusually powerful combination of documentation and software.<\/p>\n\n\n\n There are legitimate reasons not to adopt this architecture.<\/p>\n\n\n\n The most important are complexity and fragmentation.<\/p>\n\n\n\n Using Rust, Faust, WebAssembly, TypeScript, generated code, native targets, and browser targets creates more moving parts than building a straightforward C++ plugin.<\/p>\n\n\n\n That means KahuStack must aggressively maintain boundaries.<\/p>\n\n\n\n The project needs:<\/p>\n\n\n\n Without that discipline, the architecture could become more complicated than the products it is intended to support.<\/p>\n\n\n\n The reason to accept that complexity is leverage.<\/p>\n\n\n\n A conventional product architecture optimizes for shipping one application.<\/p>\n\n\n\n KahuStack DSP is optimizing for building an audio technology platform.<\/p>\n\n\n\n Rust gives us a robust systems foundation.<\/p>\n\n\n\n Faust gives us a concise and research-friendly DSP language.<\/p>\n\n\n\n WebAssembly lets that DSP run directly on the web without creating an entirely separate engine.<\/p>\n\n\n\n Together they allow us to pursue an architecture in which:<\/p>\n\n\n\n research becomes reusable code, reusable code becomes validated DSP infrastructure, and that infrastructure becomes available to multiple products and platforms.<\/strong><\/p>\n\n\n\n That is the larger argument for the technology stack.<\/p>\n\n\n\n The goal is not to prove that Rust is better than C++, that Faust is better than handwritten DSP, or that WebAssembly is equivalent to every native environment.<\/p>\n\n\n\n Each technology has real drawbacks.<\/p>\n\n\n\n The argument is instead that their strengths align unusually well with what KahuStack DSP is trying to become: a portable, testable, strongly typed, research-driven DSP platform whose algorithms can move from academic literature to interactive browser experiments to serious production audio software without repeatedly starting over.<\/p>\n\n\n\n If we maintain disciplined boundaries between those layers, that is a substantial architectural advantage.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Building serious audio software requires making a set of architectural choices that will remain with a project for years. Digital signal processing code tends to outlive user interfaces, frameworks, and even the products in which it was originally written. A good oscillator, filter, dynamics processor, resampler, or modulation system may eventually appear in a synthesizer, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/posts\/19","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/parkr.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=19"}],"version-history":[{"count":3,"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions"}],"predecessor-version":[{"id":22,"href":"https:\/\/parkr.dev\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions\/22"}],"wp:attachment":[{"href":"https:\/\/parkr.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/parkr.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/parkr.dev\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nThe Basic KahuStack DSP Architecture<\/h2>\n\n\n\n
\n\n\n\nWhy Rust?<\/h1>\n\n\n\n
Memory Safety Without a Garbage Collector<\/h2>\n\n\n\n
\n
\n\n\n\nRust Makes Architectural Contracts Explicit<\/h2>\n\n\n\n
440.0\n0.5\n48000.0\n-12.0\n120.0\n<\/code><\/pre>\n\n\n\n440 Hz\n0.5 linear gain\n48,000 samples per second\n-12 dB\n120 BPM\n<\/code><\/pre>\n\n\n\nFrequency\nSampleRate\nGain\nDecibels\nPan\nStereoWidth\nMix\nSamples\nFrames\nSeconds\nMilliseconds\nPhase\nRadians\nBeats\nBars\nTempo\nPPQ\n<\/code><\/pre>\n\n\n\n
\n\n\n\nRust as the Library Layer<\/h1>\n\n\n\n
\n
\n\n\n\nThe Drawbacks of Rust<\/h1>\n\n\n\n
Rust Has a Significant Learning Curve<\/h2>\n\n\n\n
\n\n\n\nRust Can Encourage Over-Abstraction<\/h2>\n\n\n\n
Frequency<\/code>, SampleRate<\/code>, Pan<\/code>, StereoWidth<\/code>, and Mix<\/code> provide real semantic protection.<\/p>\n\n\n\n
\n\n\n\nCompile Times and Generic Complexity Can Grow<\/h2>\n\n\n\n
\n\n\n\nThe Native Audio Ecosystem Still Leans Heavily Toward C++<\/h2>\n\n\n\n
\n\n\n\nWhy WebAssembly?<\/h1>\n\n\n\n
\n\n\n\nOne DSP Engine, Multiple Environments<\/h1>\n\n\n\n
Rust DSP\nC++ DSP\nJavaScript DSP\nBrowser DSP\nPlugin DSP\n<\/code><\/pre>\n\n\n\n
KahuStack DSP\n |\n Rust Library\n \/ \\\n WASM Native\n | |\n Browser Plugin \/ Host\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy the Browser Matters for DSP Development<\/h1>\n\n\n\n
\n
\n\n\n\nWASM Performance<\/h1>\n\n\n\n
\n
\n
\n\n\n\nThe Drawbacks of WebAssembly<\/h1>\n\n\n\n
The Browser Is Still a Constrained Environment<\/h2>\n\n\n\n
\n
\n\n\n\nCrossing the JavaScript\/WASM Boundary Has Costs<\/h2>\n\n\n\n
process audio block\n<\/code><\/pre>\n\n\n\n
\n\n\n\nAudioWorklet and Threading Require Careful Architecture<\/h2>\n\n\n\n
\n\n\n\nWASM Is Not the Product Architecture<\/h2>\n\n\n\n
\n\n\n\nWhy Faust?<\/h1>\n\n\n\n
input\n\u2192 filter\n\u2192 nonlinear stage\n\u2192 feedback path\n\u2192 output\n<\/code><\/pre>\n\n\n\n
\n\n\n\nFaust as Executable DSP Research<\/h1>\n\n\n\n
paper\n<\/code><\/pre>\n\n\n\nworking audio processor\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nFaust’s Compiler Is Part of Its Value<\/h1>\n\n\n\n
Faust DSP\n \u2193\nGenerated implementation\n \u2193\nRust integration\n \u2193\nWASM \/ native\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere Faust Makes the Most Sense<\/h1>\n\n\n\n
\n
\n\n\n\nWhere Faust Makes Less Sense<\/h1>\n\n\n\n
\n
Faust\n---------------------\nsignal processing\nsample state\nfilters\noscillators\nnonlinearities\ndelays\nDSP graphs\n\nRust\n---------------------\nprocessor lifecycle\nstrongly typed parameters\nresource ownership\nvoice management\nrouting\nhost integration\nserialization\nthreading\ntesting\nWASM bindings\nnative bindings\n<\/code><\/pre>\n\n\n\n
\n\n\n\nThe Drawbacks of Faust<\/h1>\n\n\n\n
Generated Code Can Become a Black Box<\/h2>\n\n\n\n
\n
\n\n\n\nDebugging Can Be Less Direct<\/h2>\n\n\n\n
\n
\n\n\n\nFaust Is Another Language to Maintain<\/h2>\n\n\n\n
Rust\nFaust\nJavaScript\/TypeScript\nWebAssembly behavior\n<\/code><\/pre>\n\n\n\n
\n\n\n\nGenerated Artifacts Can Drift<\/h2>\n\n\n\n
\n
generate:check<\/code> style workflow is therefore valuable.<\/p>\n\n\n\n
\n\n\n\nWhy the Combination Is More Powerful Than Any One Technology<\/h1>\n\n\n\n
Layer<\/th> Primary technology<\/th><\/tr><\/thead> DSP research expression<\/td> Faust \/ Rust<\/td><\/tr> Production library architecture<\/td> Rust<\/td><\/tr> Strongly typed domain model<\/td> Rust<\/td><\/tr> Generated DSP<\/td> Faust<\/td><\/tr> Web deployment<\/td> WebAssembly<\/td><\/tr> Browser UI<\/td> TypeScript \/ React<\/td><\/tr> Native deployment<\/td> Rust\/native interfaces<\/td><\/tr> Testing and validation<\/td> Rust + browser QA<\/td><\/tr> Research documentation<\/td> Markdown \/ web knowledge base<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nA Practical Example: Building a Filter<\/h1>\n\n\n\n
Frequency\nResonance\nDrive\nMix\nSampleRate\n<\/code><\/pre>\n\n\n\n\n
\n
Research\n\u2193\nAlgorithm\n\u2193\nReference implementation\n\u2193\nProduction DSP\n\u2193\nValidation\n\u2193\nReusable library\n\u2193\nProduct\n<\/code><\/pre>\n\n\n\n
\n\n\n\nKahuStack DSP Is Becoming Infrastructure<\/h1>\n\n\n\n
\n
\n
\n\n\n\nStrongly Typed DSP Is Part of the Strategy<\/h1>\n\n\n\n
float cutoff\nfloat gain\nfloat pan\nfloat time\n<\/code><\/pre>\n\n\n\nFrequency\nDecibels\nLinearGain\nPan\nStereoWidth\nMix\nSeconds\nSamples\nSampleRate\nTempo\nBeats\n<\/code><\/pre>\n\n\n\nsamples\nframes\nseconds\nmilliseconds\nbeats\nbars\nPPQ\nhost timeline positions\n<\/code><\/pre>\n\n\n\n
\n\n\n\nReal-Time Safety Remains the Final Authority<\/h1>\n\n\n\n
\n
\n\n\n\nThe Importance of Vertical Testing<\/h1>\n\n\n\n
DSP source\n\u2193\nRust interface\n\u2193\nWASM\n\u2193\nbrowser audio\n\u2193\ncontrols\n\u2193\nvisualization\n\u2193\nmeasurement\n\u2193\nlistening\n<\/code><\/pre>\n\n\n\n
\n\n\n\nThe Main Risks<\/h1>\n\n\n\n
\n
\n\n\n\nWhy We Are Still Choosing This Direction<\/h1>\n\n\n\n