- From: Chris Lilley <chris@w3.org>
- Date: Thu, 5 Dec 2013 18:48:54 +0100
- To: Olivier Thereaux <olivier.thereaux@bbc.co.uk>
- CC: Chris Lowis <chris.lowis@gmail.com>, Audio WG <public-audio@w3.org>
Hello Olivier, Wednesday, December 4, 2013, 11:52:29 AM, you wrote: > On 3 Dec 2013, at 19:58, Chris Lowis <chris.lowis@gmail.com> wrote: >> On the call the participants reached a consensus to: >> >> 1) Keep dezippering in the spec >> 2) Apply it universally to all parameters (such that there are no >> "edge cases" in the spec >> 3) Define it in terms of one of the other methods (probably >> exponentialRampToValueAtTime) to simplify the spec and also to >> indicate to developers how to achieve parameter changes without >> dezippering by using those methods directly. >> >> I think Olivier would like to consider this a Call for Consensus, so >> if I've missed anything, please say so. Otherwise, if we agree on the >> above approach then we can start turning this into a PR against the >> current spec. > Yes. Let's set a deadline on now()+1 week (that is 2013-12-11) for consensus on the approach. My two centimes: > * Consensus on point 1) above Yes, dezippering should be kept in the spec > * Consensus on point 2) above yes (edge cases are bad and all need to be tested, which is harder than no edge cases) > * Consensus in principle on point 3) above, excluding detailed > agreement on how we will define it for each/all parameters. OK in principle but the details do matter; I can see exp ramp being a common approach but also (depending on the parameter) a linear ramp may be more suitable so i would not like to see the spec preclude this. I would also not like to see deliberate quantization (as an effect) being precluded. Must support expramp and may support other methods would be one way, though in general I don't like optional parts. -- Best regards, Chris mailto:chris@w3.org
Received on Thursday, 5 December 2013 17:48:58 UTC