Add processor code size reporting to test-features.js for DSP feature compilation

[Copilot]

Creates test/node/test-features.js to compile six DSP variants (simple, soundfile, acc, gyr, midi, multi) and report processor code byte length for CI observability.

Implementation

• Fallback strategy for processor code access: Checks generator.processorCode property, then getProcessorCode() method, then falls back to empty string with warning
• Size calculation: Uses Buffer.byteLength(code, 'utf8') to compute raw byte length
• Test cases cover: basic DSP, soundfile integration, accelerometer/gyroscope sensors, MIDI, and polyphonic with effect

Current behavior

Processor code is generated dynamically during createNode() calls, not stored after compile(). Tests currently report 0 bytes with explanatory warning. If generator API is enhanced to expose processor code post-compilation, this test will automatically detect and report actual sizes.

// After each generator.compile()
const bytes = getProcessorCodeSize(generator);
console.log(`Processor code size: ${bytes} bytes\n`);

Original prompt

Update test/node/test-features.js to print the raw byte length of the generated processor code for each compiled DSP test case (simple, soundfile, acc, gyr, midi, multi).

Details:

• Path to modify: test/node/test-features.js
• After each call to generator.compile(...) for the six tests, read the generated processor code from the generator instance and print the raw byte length (number of bytes) of the processor code string.
• Use the following strategy to obtain the code from the generator instance:
  • Prefer generator.processorCode if present.
  • Otherwise, if the generator has a method getProcessorCode(), call it.
  • If neither exists, fall back to an empty string and print a warning message indicating the processor code could not be found.
• Compute the raw byte length using Buffer.byteLength(code, 'utf8').
• Print the size immediately after the existing "✓ Compiled successfully" message for each test. The printed line should be similar to:
  console.log(Processor code size: ${bytes} bytes\n);
• Keep all existing test behavior and messages; only add the size-printing logic.
• Ensure the file uses only Node built-ins (Buffer) and does not add new dependencies.
• Add clear comments in the modified file about why the size is being printed.

Make a single commit changing test/node/test-features.js with these updates.

Do not modify other files.

Repository: grame-cncm/faustwasm

Rationale: This change allows CI and developers to observe the raw size of the generated processor code for each feature combination during tests.

This pull request was created as a result of the following prompt from Copilot chat.

Update test/node/test-features.js to print the raw byte length of the generated processor code for each compiled DSP test case (simple, soundfile, acc, gyr, midi, multi).

Details:

• Path to modify: test/node/test-features.js
• After each call to generator.compile(...) for the six tests, read the generated processor code from the generator instance and print the raw byte length (number of bytes) of the processor code string.
• Use the following strategy to obtain the code from the generator instance:
  • Prefer generator.processorCode if present.
  • Otherwise, if the generator has a method getProcessorCode(), call it.
  • If neither exists, fall back to an empty string and print a warning message indicating the processor code could not be found.
• Compute the raw byte length using Buffer.byteLength(code, 'utf8').
• Print the size immediately after the existing "✓ Compiled successfully" message for each test. The printed line should be similar to:
  console.log(Processor code size: ${bytes} bytes\n);
• Keep all existing test behavior and messages; only add the size-printing logic.
• Ensure the file uses only Node built-ins (Buffer) and does not add new dependencies.
• Add clear comments in the modified file about why the size is being printed.

Make a single commit changing test/node/test-features.js with these updates.

Do not modify other files.

Repository: grame-cncm/faustwasm

Rationale: This change allows CI and developers to observe the raw size of the generated processor code for each feature combination during tests.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.