W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17390] (Joe Berkovitz): Loop start/stop points

From: <bugzilla@jessica.w3.org>
Date: Mon, 30 Jul 2012 21:06:00 +0000
Message-Id: <E1SvxA8-0004dD-HB@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17390

--- Comment #4 from Joe Berkovitz / NF <joe@noteflight.com> 2012-07-30 21:05:59 UTC ---
(In reply to comment #3)
> 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Monday, 30 July 2012 21:06:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 July 2012 21:06:02 GMT