faustwasm updated to 0.14.0.

[sletz]

No description provided.

[b-ma]

Hey thanks!
Just let me now when it is stabilizing on your side and you want me to merge (and happy new year :)

[sletz]

Happy new year 2026 !

Yes "vibe-coding/working" a lot on this project https://github.com/sletz/faust-mcp, so heavily using the node-web-audio-api, really nice BTW. I'm using my fork right now, I've let you know when a merge can be done.

[sletz]

Can you possibly merge now ? And update https://www.npmjs.com/package/node-web-audio-api ? Thanks.

[orottier]

I might be mistaken but I don't think updating a devDependency has an effect on end users

[b-ma]

Thanks!

I might be mistaken but I don't think updating a devDependency has an effect on end users

No indeed, it doesn't

[sletz]

Reading here: https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file, and having faustwasm packagage in devDependency, what is expected work flow for user using NPM packaged version when Faust support is needed ?

[b-ma]

For a end user, the workflow would be to install both the node-web-audio-api and @grame/faustwasm packages, and then use them as follow:

import { AudioContext, AudioWorkletNode } from 'node-web-audio-api';

// Expose AudioWorkletNode globally so faustwasm can patch it into worklet factories.
if (typeof globalThis.AudioWorkletNode === 'undefined') {
  globalThis.AudioWorkletNode = AudioWorkletNode;
}

const {
  instantiateFaustModuleFromFile,
  LibFaust,
  FaustCompiler,
  FaustMonoDspGenerator,
} = await import('@grame/faustwasm/dist/esm/index.js');

This is a bit convoluted for now... but I'm thinking about exposing a register-global.js entry point that should allow to clean this to:

import 'node-web-audio-api/register-global.js';
import {
  instantiateFaustModuleFromFile,
  LibFaust,
  FaustCompiler,
  FaustMonoDspGenerator,
} from '@grame/faustwasm/dist/esm/index.js';

cf. #166

[b-ma]

Hey @sletz ,

I just tried to update your faust examples using the second cleaner syntax given that the lib now exposes a polyfill.js entry point.

The problem is that it fails because the polyfill creates a window object to support existing libs that explicitly rely on window, e.g. https://github.com/chrisguttandin/standardized-audio-context

I have seen that you check if we run in a browser using typeof window === 'object' (e.g. https://github.com/grame-cncm/faustwasm/blob/79248357f2a9e081f84bb4418fcfc70b4b61be83/src/instantiateFaustModuleFromFile.ts#L18), then we fall into the wrong branch. I tried to replace it with a more robust

const isBrowser = new Function('try {return this===window;}catch(e){ return false;}');
// and similarly
const isNode = new Function('try {return this===global;}catch(e){ return false;}');

But then it fails again because of some similar check are done in libfaust-wasm.js which appear as transpiled code and I could not figure out where it comes from.

Happy to help (or make a PR with some guidance) if you are interested in fixing this