- From: Olivier Thereaux <notifications@github.com>
- Date: Wed, 11 Sep 2013 07:30:03 -0700
- To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
- Message-ID: <WebAudio/web-audio-api/issues/157/24244595@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390#7) by Joe Berkovitz / NF on W3C Bugzilla. Wed, 12 Sep 2012 16:57:28 GMT Amending to reflect discussion: no loop mode in V1 start and end == 0 implies whole-sample loop and these are default values clamping of start/end reflctd in loop behavior not readable values type of start/end attributes to be float to support future subsample loops non-subsample impls to round start/end to integral values > I've been corresponding with Chris Rogers, and we have agreed on an approach > that defers some of his previous suggestions to a V2 API. So here's a concrete > spec that lines up with this thinking: > > The following elements are added to the AudioBufferSourceNode interface: > > const unsigned short LOOP_ENTIRE_SAMPLE = 0; // looping applies to entire > sample > const unsigned short LOOP_START_END = 1; // looping repeats from > loopStart to loopEnd until stop() is called > // (In the future, may support other modes, e.g. exit loop and play to end > after stop() is called > // or crossfade at start/end repeat boundary) > > // looping mode to be employed if the existing loop attribute is true. > Default value is LOOP_ENTIRE_SAMPLE. > attribute unsigned short loopMode; > > // start and endpoints as zero-based frame offsets within AudioBuffer for > an *inclusive* loop range. > // Only used if loop == true and loopMode == LOOP_START_END > attribute unsigned long loopStart; > attribute unsigned long loopEnd; > > The new loopMode attribute determines the behavior of playback when the loop > flag on the node is true. The default value of LOOP_ENTIRE_SAMPLE preserves > the legacy behavior of looping the entire sample. Setting loopMode to > LOOP_START_END, however, will cause loopStart and loopEnd to drive looping > playback as follows: > > - loopStart and loopEnd are clipped to the range [0..buffer.length-1] > - the sample frame at element [loopStart] of the underlying AudioBuffer is > considered the successor of the element [loopEnd]. Thus the playback order of > all frames in the buffer is taken as [0..loopEnd-1], [loopStart..loopEnd-1], > [loopStart..loopEnd-1], ... > - if playback is attempted at an offset at loopEnd or greater by a call to > startGrain(), no playback occurs > - if stop() is called, output from the node ceases at the requested time > regardless of what sample frame offset is being rendered > > Note that loopStart/loopEnd are integral frame offsets in the buffer, not time > offsets in seconds. That's because loops are really properties of the wave data > in the underlying buffer, which makes them independent of playbackRate and thus > not defined in terms of temporal units. Changing the playbackRate of a sample > with loop points will alter the pitch of the sample, but not the nature of its > loop. --- Reply to this email directly or view it on GitHub: https://github.com/WebAudio/web-audio-api/issues/157#issuecomment-24244595
Received on Wednesday, 11 September 2013 14:31:16 UTC