Re: Stopping synthesis cleanly

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