Re: Having some problems with envelopes

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