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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390#3) by Joe Berkovitz / NF on W3C Bugzilla. Mon, 30 Jul 2012 21:05:59 GMT

(In reply to [comment #3](#issuecomment-24244567))
> Joe, I agree this is important for implementing sample-playback synths
> (SoundFonts, etc.).  The one point I'd like to make sure we figure out is how
> to deal with the sample data *after* the loopEnd attribute.  For example, in
> SoundFonts the loopEnd is often (but not always) set to end of the total sample
> data.  But when it's not, upon receiving a note-off command, the loop is
> expected to "exit" and proceed with sample playback all the way through to the
> end of the sample data (finally playing the sample data after the loopEnd).

In my experience the scenario of "loop exits" is quite rare with actual instrument samples, because one usually has few viable choices for internal loop points that are glitch-free -- making it that much less likely that a loop endpoint will also feed into (or be grafted onto) a naturally recorded and well-timed note release. Instead, a release envelope is applied to the continuing loop, beginning at the time that the musical effect of a "note off" is desired (i.e. the start of the release). The actual noteOff() on the AudioBufferPlaybackNode can be scheduled for the time at which the release envelope reaches an inaudible level.

So I feel that support for these less-common loop modes is not needed in V1, given the use case of playback of looped instrument samples.

However, we should certainly consider how to deal with loop modes.  One suggestion is that we adopt a [future?] loopMode attribute that is enumerable between these various options:
1. disable looping
2. once loop is entered, play continuously until noteOff()
3. once loop is entered, exit loop end after noteOff() and play rest of sample

#3 raises a sticky point. As I implied above, samplers tend to equate the concept of "note off" with the start of a release phase, not with the cessation of sound.  So it might also be worth considering whether the Web Audio API's noteOff() is the right way of conveying this concept of starting the release, particularly in the loop-exit case where exiting the loop occurs before sound ceases. Given the above definitions of loopMode, one would have to call noteOff() at very different times in the case of #2 and #3, because in #3 noteOff() doesn't actually stop the sound: it merely begins the process of stopping the sound, and in a rather difficult-to-predict way (since one doesn't easily know where in the loop one is going to be at some specific time, given the vagaries of playbackRate, etc).  It might be better to add a new, schedulable AudioParam whose purpose is to indicate that any internal loop is to be exited.

Make that another argument to attack this in V2.

Finally, some samplers also support the ability to optionally crossfade the end of the loop into the start of the loop with a specified time window, and also to "bounce" the loop by playing it successively backwards and forwards.  To me these are V2 features although the crossfade would be very welcome.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/157#issuecomment-24244574