TAG Issue: Explaining ("De-sugaring") the *Node Types

[chrislo]

The following issue was raised by the W3C TAG as part of their review of the Web Audio API

Explaining ("De-sugaring") the *Node Types

On the back of a repaired ScriptProcessorNode definition, the spec should contain tight descriptions of the built-in library of the AudioNode subclasses; preferably in the form of script which could be executed in a ScriptProcessorNode.

Obviously we do not recommend that implementations lean on this sort of self-hosting for production systems. It is, however, clear that without such a detailed description of the expected algorithms, compatibility between implementations cannot be guaranteed, nor can conformance with the spec be meaningfully measured. This de-sugaring-as-spec-exercise would be helpful for the testing of the system and for users who will at a later time want to know exactly what the system is expected to be doing for them.

We imagine an appendix of the current spec that includes such de-sugarings and test suites built on them.

[agoode]

Has there been any progress on this? I would be interested in looking into this. I would imagine starting a repo with only ScriptProcessorNode as a builtin and building the rest.

[opera-mage]

I think the main blocker right now is that we need to re-work the ScriptProcessorNode. There are too many shortcomings of the current ScriptProcessorNode, so it's not really possible to describe most of the audio nodes (a couple of problems that come to mind are the lack of support for AudioParams and the fixed number of input/output channels).

[joeberkovitz]

I believe the AudioWorker proposal allows this issue to be finally addressed.

[cwilso]

Do we want this as a normative definition? Informative appendix? Separate doc/library?

[joeberkovitz]

Proposal: non-normative descriptions in spec of all native node types, as far as possible.

[joeberkovitz]

How far do we want to go with this for V1, now that ScriptProcessorNode has been dealt with?

[billhofmann]

I'd propose we not hold for this.

[joeberkovitz]

I agree with @billhofmann but adding discussion label for TPAC 2015

[joeberkovitz]

TPAC: Not a V1 issue, but make progress over time on this.

[mdjp]

Going forwards, we will take this approach to developing new nodes and additional functionality in existing nodes.
Nodes in V1 spec will be tackled retrospectively.