Faust constructor

[dfober]

Is there any good reason to have the .wasm and .data files passed as arguments of the Faust constructor? Normally you put them anywhere you want and the location is specified from the web page. Doing so hides the dependency when you want to build another library (my case) that (optionally) uses the Faust compiler. In addition, the location is then hardcoded in the library and makes it more difficult to use in different contexts. I understand that the libfaust-wasm.js is embedded in the final output library. Maybe you could keep the native library and the web wrapper separated and pass the FaustModule to the Faust constructor (which doesn't prevent to provide a high-level async interface to load the library).

[Fr0stbyteR]

In the older versions of faust2webaudio, the .wasm and .data files are also included in the final minified js file. But after a test under Firefox, it shows that the js file may be too large to load, and is running slowly. So I separated these two files and allow to load them from other locations. I understand that in your case, you may need to load a different version of libfaust-wasm.js. I think it is not hard to do by modifying LibFaustLoader.js. I will take a look. It should be something like:

const { default: LibFaust } = await import(/* webpackIgnore: true */libFaustUrl);

This requires that the browser support ES6 Module dynamic import.

[dfober]

The issue is not to use a different version of libfaust-wasm.js but to not hide the paths to the wasm and data files, which would be the case if I build a library that uses the faust library. This problem could be easily solved by separating the webaudio wrapper and libfaust-wasm.js, and passing a FaustModule to the Faust constructor. Do you see what I mean? I'll try this on a separate branch and I'll keep you informed.

[Fr0stbyteR]

OK I understand better now. Yes, to pass FaustModule to constructor is a better way.