Re: Stopping synthesis cleanly

Ian, good point.  Yes, we should probably have both.

On Mon, Oct 18, 2010 at 1:54 PM, Ian Ni-Lewis <ilewis@google.com> wrote:

> What about reverb tails etc? Should there be a distinction between "all
> notes off" and "entire graph off"?
> Ian
>
>
> On Mon, Oct 18, 2010 at 1:34 PM, Joseph Berkovitz <joe@noteflight.com>wrote:
>
>> Sounds good.
>>
>> ...j
>>
>> On Oct 18, 2010, at 4:09 PM, Chris Rogers wrote:
>>
>> Joe,
>>
>> I was thinking that "notes" scheduled to play in the future would be
>> cancelled, and probably any notes currently playing would be issued
>> "note-off" commands.  I suppose this would be similar to the MIDI "all notes
>> off" command.  Currently, if there are any JS references to a source
>> AudioNode then it will not be disconnected automatically from the graph even
>> if it has stopped playing.  My idea there is that it might be interesting to
>> play the note again.
>>
>> Chris
>>
>> On Mon, Oct 18, 2010 at 12:14 PM, Joseph Berkovitz <joe@noteflight.com>wrote:
>>
>>> Chris,
>>>
>>> I think it's fine to just cancel everything that's scheduled -- the point
>>> is to stop all sound.  However the spec should answer the question, "does
>>> this action actually break any connections in the graph?"  In other words,
>>> if you invoke this function, then look at some AudioNode and see if it's
>>> still connected to context.destination, what is the result?
>>>
>>> If there is no additional state added to AudioContext, I would expect the
>>> connections to disappear so that the graph reflects the reality of
>>> everything having stopped.
>>>
>>> But there is another way, which is to have some kind of
>>> AudioContext.active boolean attribute which can be set to false to disable
>>> all sound output.  This would leave the graph intact, but cause the
>>> AudioContext to simply ignore it.  I'm not sure if that is a good idea,
>>> however, because it raises questions about what would happen if you set the
>>> active flag back to true again.  I guess it doesn't really "take out the
>>> garbage" in the way that a stop-everything sort of function would do.
>>>
>>> ...joe
>>>
>>>
>>> On Oct 18, 2010, at 3:04 PM, Chris Rogers wrote:
>>>
>>> Joe, this is simply an omission in the current spec, but it definitely
>>> should be there.  Do you think it's sufficient to have a way to "cancel all"
>>> scheduled events on the whole context, or do we need to have finer-grained
>>> control over specific AudioNodes?
>>>
>>> Chris
>>>
>>> On Mon, Oct 18, 2010 at 9:57 AM, Joseph Berkovitz <joe@noteflight.com>wrote:
>>>
>>>> I'm not sure if I missed it, but in the proposed API I couldn't find a
>>>> simple way to stop all output and clean out the AudioContext.  In our
>>>> notation playback demo, I had to manually do bookkeeping on all the nodes
>>>> connected to the destination and disconnect them in case the user clicked
>>>> "Stop".  I would imagine that for more complex apps this could become a real
>>>> pain point.
>>>>
>>>> Is there a good way to do this?  If not, is this a feature that merits
>>>> addition to the spec?
>>>>
>>>>      ... .  .    .       Joe
>>>>
>>>> *Joe Berkovitz*
>>>> President
>>>> Noteflight LLC
>>>> 160 Sidney St, Cambridge, MA 02139
>>>> phone: +1 978 314 6271
>>>> www.noteflight.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>      ... .  .    .       Joe
>>>
>>> *Joe Berkovitz*
>>> President
>>> Noteflight LLC
>>> 160 Sidney St, Cambridge, MA 02139
>>> phone: +1 978 314 6271
>>> www.noteflight.com
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>      ... .  .    .       Joe
>>
>> *Joe Berkovitz*
>> President
>> Noteflight LLC
>> 160 Sidney St, Cambridge, MA 02139
>> phone: +1 978 314 6271
>> www.noteflight.com
>>
>>
>>
>>
>>
>>
>
>
> --
> Ian Ni-Lewis
> Developer Advocate
> Google Game Developer Relations
>
>