Re: ABSN reversed playback behavior

This behavior seems most logical to me.

On Fri, Mar 3, 2017 at 8:03 AM, Raymond Toy <rtoy@google.com> wrote:

> 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/5d4a6e8b1c3603
>> b5a923f7b0361e2f2078c25389/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
>>
>
>