Giter Site home page Giter Site logo

faust2webaudio's People

Contributors

barnabycollins avatar fr0stbyter avatar sletz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

faust2webaudio's Issues

Syntax errors

Hi

When I try to open the test pages (./test/mono.html etc. ) I get weird syntax errors.

./test/mono.html gives:

Uncaught (in promise) Error: stdfaust.lib : 1 : ERROR : syntax error, unexpected SUB
compileCode Faust.ts:264

I tried changing the code variable:

code = 'import("noises.lib");
process = noise*0.1;'

this gave the syntax error:

Uncaught (in promise) Error: noises.lib : 1 : ERROR : syntax error, unexpected SEQ, expecting DEF
compileCode Faust.ts:264

finally I tried, code = 'process = 0;', which compiled without errors.

Do you know what causes this?

Thank you for helping out

TypeScript build failures

When using this module with the following import:

import {Faust, FaustAudioWorkletNode} from "faust2webaudio";

and trying to build my project using tsc, with the following tsconfig.json

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "lib": ["ESNext", "DOM"],
    "moduleResolution": "Node",
    "strict": true,
    "sourceMap": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "noEmit": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true
  },
  "include": ["./src"],
  "exclude": ["./node_modules"]
}

I'm getting over 300 build failures across the whole module! I can see that this is quite a strict tsconfig, but even relaxing it to:

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "lib": ["ESNext", "DOM"],
    "moduleResolution": "Node",
    //"strict": true,
    "sourceMap": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "noEmit": true,
    //"noUnusedLocals": true,
    //"noUnusedParameters": true,
    "noImplicitReturns": true
  },
  "include": ["./src"],
  "exclude": ["./node_modules"]
}

gives me 59 errors - mainly the following complaints:

node_modules/faust2webaudio/src/Faust.ts - error TS2339: Property '_malloc' does not exist on type 'LibFaust'.
node_modules/faust2webaudio/src/Faust.ts - error TS2339: Property 'HEAP32' does not exist on type 'LibFaust'.
node_modules/faust2webaudio/src/Faust.ts - error TS2339: Property 'HEAP8' does not exist on type 'LibFaust'.
node_modules/faust2webaudio/src/Faust.ts: - error TS2339: Property '_free' does not exist on type 'LibFaust'.
node_modules/faust2webaudio/src/FaustAudioWorkletNode.ts - error TS2339: Property 'get' does not exist on type 'AudioParamMap'.
node_modules/faust2webaudio/src/LibFaustLoader.d.ts - error TS2702: 'FS' only refers to a type, but is being used as a namespace here.
node_modules/faust2webaudio/src/LibFaustLoader.d.ts:37:17 - error TS2503: Cannot find namespace 'Emscripten'.
node_modules/faust2webaudio/src/LibFaustLoader.d.ts:85:36 - error TS2304: Cannot find name 'EmscriptenModule'.
node_modules/faust2webaudio/src/utils.ts:54:74 - error TS2339: Property 'split' does not exist on type '(options: Imports) => Promise<Exports>'.

I take it you don't have these issues when building, eg, the Faust IDE, so is there some way I can resolve these (preferably without changing my tsconfig.json) or do changes need making to the library's typings?

Difficulty getting faust2webaudio to work on Windows

I'm looking to use this module for an academic project, since I need a framework to generate synthesisers in the browser and Faust seems ideal for this. I see that it's used in the Faust IDE, but I am having problems getting it to work and am wondering if I'm missing some documentation somewhere.

Faust constructor

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).

Creating ~50 nodes via .getNode() yields "RangeError: WebAssembly.Instance(): Out of memory: wasm memory"

I'm unsure if this is a usage problem by me, an underlying limitation or a bug (doubtful).

If I create ~50 AudioWorkletNodes via getNode(), I get the out of memory error mentioned in the title on latest Chrome on macOS.

image

Here is a reproduction based on test/mono.html:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <script src="../dist/index.min.js"></script>
    </head>
    <body style="position: absolute; width: 100%; height: 100%; margin: 0px">
    </body>
    <script>
        audioCtx = new (window.AudioContext || window.webkitAudioContext)();
        const faust = new Faust2WebAudio.Faust({ debug: true, wasmLocation: "../dist/libfaust-wasm.wasm", dataLocation: "../dist/libfaust-wasm.data" });
        window.faust = faust;
        faust.ready
        .then(async () => {
            const code = `
import("stdfaust.lib");
process = ba.pulsen(1, 10000) : pm.djembe(60, 0.3, 0.4, 1) <: dm.freeverb_demo;`;

            const node = await faust.getNode(code, { audioCtx, useWorklet: true, args: { "-I": "libraries/" } });
            node.connect(audioCtx.destination);
            window.node = node;

            let i = 1;
            const another = async () => {
                console.log('five seconds have elapsed, make another', i++);
                const node = await faust.getNode(code, { audioCtx, useWorklet: true, args: { "-I": "libraries/" } });
                await new Promise(r => setTimeout(r, 5000));
                node.destroy();
                another();
            };
            another();
        })
        const unlockAudioContext = (audioCtx) => {
            if (audioCtx.state !== "suspended") return;
            const b = document.body;
            const events = ["touchstart", "touchend", "mousedown", "keydown"];
            const unlock = () => audioCtx.resume().then(clean);
            const clean = () => events.forEach(e => b.removeEventListener(e, unlock));
            events.forEach(e => b.addEventListener(e, unlock, false));
        }
        unlockAudioContext(audioCtx);
    </script>
</html>

Normally I wouldn't want 50 nodes connected at the same time, but I would like to be able to compile 50 nodes over the course of half an hour without having to refresh the page. I'm calling node.destroy(); but perhaps this isn't enough to clean up the memory used by each new AudioWorklet. In this example I'm not connecting the new nodes to the audio graph so there should be no hanging references on the js side (honestly I'm not sure how WebAssembly memory allocation and js's regular garbage colllection interact, if at all). Is there anything I can do to overcome this limitation?

hard coded reference to src in dist/index.d.ts

As far as I can understand, the dist folder contains everything to run Faust: it is self-contained from code and resource viewpoint. However, index.d.ts makes reference to the src folder, which makes the dist folder not sufficient for development.
In addition, dist/index.d.ts makes only imports from various files located in the src folder, which is not very declarative and more or less useless for the developer.
Could it be possible to have a 'real' interface e.g. a faust.d.ts file that declares all the public types and interfaces without reference to the src folder? (and hides internal dependencies) It seems it almost exists in the src files.
But maybe there are good reasons to proceed this way...

emscripten and FS manual declaration

I note that emscripten functions and FS are manually declared in libFaustLoader.d.ts
You could probably save time and maintenance effort by using the existing types declarations available from npm

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.