Re: [web-audio-api] Loop start/stop points (#157)

> [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