Re: ABSN reversed playback behavior

Thanks for putting this together.  This, indeed, is the source of my
confusion!

Option 2 was my naive interpretation of what I thought looping should do.
Having never used any other music application digital or otherwise, I would
encourage people to weigh in on what looping should do with negative
playback.

I have not yet looked at your new changes, but I will get to it shortly.

On Fri, Mar 3, 2017 at 6:45 AM, Joe Berkovitz <joe@noteflight.com> wrote:

> Hi Ray and group,
>
> I thought I'd try to put out an explanation of the latest revisions to
> https://github.com/WebAudio/web-audio-api/pull/1143 and why I think it
> addresses the issues that came up in yesterday's call. I also think this
> issue should be made more visible to observers of the WG's activity.
>
> To recap: we have a conflict between two alternate interpretations of what
> should happen when playbackRate is reversed on an ABSN that is playing, and
> whose playhead position is currently within the looped portion of the
> buffer:
>
> 1. *The node should play the exact reverse of everything that it has
> played up since it started*. In this behavior, the looped portion is played
> backwards for only as many iterations as it has already played forwards
> (which could be 1 or fewer). This behavior is useful for, say, playing a
> musical note that incorporates both an attack and a looped section in a way
> that "sounds backwards".
>
> 2. *The node should play the loop in reverse, indefinitely*. This is
> useful for playing a looped section in reverse for an indefinite period,
> like a DJ "scrubbing" a looped sound on a turntable by spinning it
> backwards, or a repeating sound effect being played backwards over and over
> again.
>
> There are clearly two somewhat incompatible use cases here. My argument
> for (1) was that it is a simple, literal interpretation of "backwards".
> However Ray has made some compelling arguments for (2):
>
> - Without this behavior, there is no practical way to achieve indefinite
> backwards looping. I had argued for setting an arbitrary large "offset"
> value, but I now realize that this violates the sense of "offset" as an
> actual offset constrained by the buffer's physical length.
>
> - It is possible to achieve the effect of (1) without prescribing any
> special ABSN behavior, by either unrolling the looped samples or by playing
> two ABSNs in juxtaposed sequence, one with the reversed loop and the other
> with the reversed attack.
>
> The most recent revision to PR #1143 now specifies behavior compatible
> with (2) (I hope!) so that we can evaluate what people think of this
> approach. The changes I made were simple: there is a new "enteredLoop" flag
> that tracks whether the playhead has ever entered the loop. If this flag is
> true, then effectiveBufferTime is allowed to wrap *forward*, mapping
> playhead positions prior to actualLoopStart to their corresponding wrapped
> positions prior to actualLoopEnd.
>
> In Ray's test case, the enteredLoop flag becomes true immediately because
> the offset parameter places the playhead within the loop from the start of
> playback. Consequently, the loop will play backwards indefinitely.
>
> In cases where the playhead lies within the "attack" phase of a looped
> note sample, though, the playhead would simply play the attack backwards.
> So this does partially support the goals of behavior (1).
>
> See https://rawgit.com/WebAudio/web-audio-api/
> 5d4a6e8b1c3603b5a923f7b0361e2f2078c25389/index.html#
> playback-AudioBufferSourceNode for details.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> Founder
> Noteflight LLC
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com
>