Re: Having some problems with envelopes

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
>>
>
>