Re: Thoughts and questions on the API from a modular synth point of view

On Thu, Aug 2, 2012 at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Aug 3, 2012 at 4:41 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> Chris and I have talked through many different "pausing" behaviors - and
>> I'm quite sure he's thought about it even more.  The problem is there isn't
>> one logical solution - for example, your "I want to stop audiocontext from
>> asking for more buffers [temporarily]": how does that deal with an upstream
>> source from a microphone input (via getUserMedia)?  Is it really "pausing"
>> - i.e. recording like a DVR?  How much time can it buffer?  You'd probably
>> also want a fast-forward API then... and this starts looking less tenable.
>>  It would also be a confusing challenge when audiocontext.currentTime
>> doesn't always proceed forward at a steady rate - or (more likely) when
>> branches of the audio graph want to get out of sync (because you really
>> want to "pause" branches, not always the whole graph - that's what the
>> Fieldrunners guys wanted<http://www.html5rocks.com/en/tutorials/webaudio/fieldrunners/>,
>> so they could pause the game effects but keep the menu effects going).
>>
>
> These problems can all be solved:
> 1) Support currentTime on each AudioNode.
>

Gah.  I can envision what you'd need to code around this solution, and yes,
exposing the currentTime on every AudioNode would be part of it; my point
was that it's not just adding "pause", it completely changes the concept of
one monotonically proceeding audio clock.


> 2) When a getUserMedia stream feeds into a paused node, drop data. For
> authors who actually want DVR-like buffering we probably should invent an
> entirely new kind of MediaStream that specifically does that.
>

How does it drop data, exactly?  Because that's probably going to sound
like a glitch.


> 3) When a media element stream feeds into a paused node, you have the
> option of either pausing the media element or dropping data. We could
> expose API to give the author control (c.f. the blockInput flag from MSP)
> 4) For each connection within in audio graph, you could provide the
> equivalent of blockInput/blockOutput from MSP. Sensible defaults might be
> to say that blockInput is true and blockOutput is false, i.e., a paused
> stream feeding into a non-paused stream is treated as silence, but any
> stream feeding into a paused stream is forced to pause.
>

My intent was not to say "this is impossible" - just "this makes a lot of
things complex, just to make a single scenario very easy - and it's not
impossible now."