Re: Having some problems with envelopes

> You would need to cancelScheduledValues, then setValueAtTime(now,
param.value);

I don't see how i can do that if i schedule something in the future. Am i
overlooking something? From what i see now, that hack seems the only way to
get this to work correctly.


2014-07-08 11:19 GMT+02:00 Peter van der Noord <peterdunord@gmail.com>:

> It absolutely is a hack, but from what i see it's the only way i can get
> that to work, since i don't have something like getValueAtTime.
>
>
> 2014-07-07 17:42 GMT+02:00 Chris Wilson <cwilso@google.com>:
>
> That is a hack, though - the onended callback will happen in the main JS
>> thread, so it's not guaranteed to get called before the next block of audio
>> is processed (if the main thread is congested).
>>
>> You would need to cancelScheduledValues, then setValueAtTime(now,
>> param.value);
>>
>>
>> On Fri, Jul 4, 2014 at 4:07 PM, Peter van der Noord <
>> peterdunord@gmail.com> wrote:
>>
>>> A very helpful user on ##webaudio helped me with this issue, and made a
>>> workaround for it.
>>>
>>> http://petervandernoord.nl/js/webaudio/
>>>
>>> It's playing predefined sequences that are scheduled ahead in time here
>>> http://petervandernoord.nl/js/webaudio/inc/script/app/sound/Scheduler.js
>>>
>>> ...which calles the scheduleNote function on the synth, which is at the
>>> bottom here (it just uses a simple AD envelope for now)
>>>
>>> http://petervandernoord.nl/js/webaudio/inc/script/app/sound/instrument/MultiOscSynth.js
>>>
>>> ...and that function goes to the actual workaround here:
>>>
>>> http://petervandernoord.nl/js/webaudio/inc/script/app/sound/AudioManager.js
>>>
>>> What happens is that for each audioparam-change that i want to schedule
>>> in the future, it creates an oscillator containing 1 sample, schedules it
>>> to play at that time in the future, and uses the onended callback (as
>>> defined in the MultiOscSynth) to actually do the param changes. Because of
>>> the callback, the param-changes will be done (at a later point) in the
>>> 'now', so i can use the audioParam.value to stop a (possibly) ramping
>>> audioParam and have it start a new ramp from exactly that value.
>>>
>>> Big thanks to root66
>>>
>>>
>>>
>>> 2014-07-04 1:37 GMT+02:00 Karl Tomlinson <karlt+public-audio@karlt.net>:
>>>
>>> Peter van der Noord writes:
>>>>
>>>> > I'm currently having some issues regarding envelopes, which seems to
>>>> be
>>>> > exacty what is described here:
>>>> >
>>>> > http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0053.html
>>>> >
>>>> > I'm playing sequences that i schedule ahead in time, but i don't see
>>>> any
>>>> > way to get the envelopes right. Some questions:
>>>> >
>>>> > - what happens exactly when i cancel scheduled param-changes? it's
>>>> totally
>>>> > unclear for me from the specs what happens to the value when i
>>>> schedule a
>>>> > cancel on a moment when it will be in the middle of a change (a
>>>> linear ramp
>>>> > for example)
>>>>
>>>> I'm guessing the intention was that
>>>> cancelScheduledValues(startTime) would remove the scheduled events
>>>> from the equation.  Those events would no longer have any effect,
>>>> even for times < startTime.  If an event, such as a linear ramp,
>>>> has already begun taking effect, then I'm not clear what the
>>>> expected behavior is.
>>>>
>>>> > - is it currently impossible to implement a correctly working
>>>> envelope when
>>>> > scheduling ahead in time?
>>>>
>>>> I think it is possible but may be inelegantly awkward if values for
>>>> setValueAtTime() need to be calculated by the client.
>>>>
>>>> Consider this function from [1]:
>>>>
>>>> function triggerAttack (time) {
>>>>   param.setValueAtTime(*SOME VALUE?*, time);
>>>>   param.linearRampToValue(1, time+attackTime);
>>>>   param.linearRampToValue(sustainValue, time+attackTime+decayTime);
>>>> }
>>>>
>>>> We want a way to say where the linear ramp for the attack should
>>>> start.  i.e. we want to schedule an event that has no effect
>>>> except to mark the start for the effect of subsequent events or an
>>>> end to the effects of previous events.  (IIUC this is a little
>>>> simpler than what is proposed in [2].)
>>>>
>>>> setTargetAtTime() already does pretty much what is wanted here
>>>> because it does not change that value at startTime.
>>>>
>>>> Unfortunately, though, the spec isn't clear which equation should
>>>> be used between a setTargetAtTime event and a
>>>> linearRampToValueAtTime event.  This was raised in [3], but I
>>>> don't find where it has been addressed.  I would have expected the
>>>> linear ramp equation to apply, because otherwise the linear ramp
>>>> will become a step function at its endTime, but Gecko is applying
>>>> the exponential from setTargetAtTime.
>>>>
>>>> > - is there any way to access the queued/scheduled param-changes on an
>>>> > audioparam?
>>>>
>>>> Not currently, at least.
>>>>
>>>> [1]
>>>> http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0055.html
>>>> [2]
>>>> http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0075.html
>>>> [3] https://github.com/WebAudio/web-audio-api/issues/216
>>>>
>>>
>>>
>>
>