[TAG] Remove non-UA-implemented stuff from AudioWorkletProcessor

[domenic]

I raised this point before in previous threads, but it doesn't seem to have been reflected. Chrome's intent to implement makes this particularly urgent, as it's important for implementers to be able to get an accurate idea of what they are expected to implement.

As far as I can tell, AudioWorkletProcessor should only have postMessage, onmessage, and contextInfo. process and parameterDescriptors are user-supplied and do not belong in the IDL.

[joeberkovitz]

@hoch is there any reason why this is not a matter of simply removing the noted methods and attributes from the IDL?

[hoch]

@joeberkovitz Agreed. I am removing them from the IDL.

@domenic What is the best practice to present an attribute or a method that cannot be captured by IDL? Perhaps an informative section? an example? I am planning to do something similar to this: https://www.w3.org/TR/css-paint-api-1/#paint-worklet.

[domenic]

@hoch an example sounds perfect to me. Maybe something like:

Developers will typically create subclasses which extend AudioWorkletProcessor. These must implement a method named process() that (does X) and have a static property named parameterDescriptors which is an iterable of AudioParamDescriptors. An example of a minimal subclass is as follows:

class MyProcessor extends AudioWorkletProcessor {
  static get parameterDescriptors() { return [{
      name: 'bitDepth',
      defaultValue: 12,
      minValue: 1
      maxValue: 16 
    }];
  }

  process() {
    // do X
  }
}

[domenic]

More specifically, I actually kind of don't like the example from the Paint API which says "This is how the class should look" and then uses IDL. Web developers don't know how to read IDL.

[hoch]

Okay, I'll go with the example then. Thanks!

[hoch]

Fixed by #963.