Re: BufferSourceNode to AudioParam Connection

Thanks for all of the awesome explanations everyone. I spent some time
working through some ideas from Chris Wilson (thanks Chris!) and decided on
a pretty simple solution that gives the results I was looking for (demo
here: http://nick-thompson.github.com/examples/sidechain/). The approach is
to construct an estimate of the envelope of the sidechain input buffer (in
my examples, the drum beat), and use that estimate to fire setTargetAtTime
calls to the gain audioparam controlling the other input through a
JavaScriptNode. This way you avoid the direct ring-modulation effect from
multiplying the input by the sidechain. I'd be interested to hear what you
guys think of this.

Also, after working through this, I think that a nice feature for
audioparam automation would be the ability to schedule repeating events.
Something to the effect of "setTargetAtTime(1.0, 10.0n /* every 10 seconds
*/, 0.1);", but which would obviously require different syntax. That's just
food for thought.

Thanks again!

Best,
Nick


On Tue, Nov 6, 2012 at 1:34 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> On Mon, Nov 5, 2012 at 5:40 PM, Nick Thompson <ncthom91@gmail.com> wrote:
>
>> Hey all,
>>
>> I'm currently experimenting with sidechain implementations, and I've
>> noticed a discrepancy in the way AudioNode's connect to AudioParams.
>>
>> If you route an Oscillator into an audioparam, the output of the
>> Oscillator does not reach AudioContext.destination unless you specifically
>> connect it thereto. Example: http://jsfiddle.net/Ddz3y/1/ In this
>> example, the output of one oscillator simply modulates the gain on the
>> output of another oscillator, as you would expect.
>>
>> However, if you route a BufferSourceNode into an AudioParam, the output
>> of the BufferSourceNode still reaches AudioContext.destination even if you
>> don't specifically make that connection. Example:
>> http://jsfiddle.net/VdLf6/ Here, you'll notice the same setup as in the
>> previous example, and you'll notice that the output of the OscillatorNode
>> is clearly audible when the buffer sample's kick drum is played, but at the
>> same time, the buffer itself is fully audible even though I did not specify
>> a connection to AudioContext.destination (unless you're counting the
>> connection from bufferNode -> gain.gain, gain -> context.destination).
>>
>> I'm not sure what to make of the discrepancy here. A bug in the
>> implementation? Or perhaps that's the expected behavior? If that's the
>> case, I feel the documentation should be updated to reflect that, as it was
>> pretty unexpected. Or maybe I'm just approaching/using this feature
>> incorrectly? If that's so, please correct me!
>>
>
> Hi Nick, cool demo!  I'm pretty sure it's working correctly and what
> you're hearing is the frequency-shifted (higher and lower) versions of the
> drum beat.  This is ring-modulation and it's normal for it to sound this
> way.  Notice that if you tweak the oscillator frequency much higher (like
> 8000), the character of the drum is very different.  Also keep in mind that
> with an AudioGainNode, it doesn't matter which one is the input and which
> one is controlling the .gain param since the two signals are just being
> multiplied.  In other words, x*y is the same as y*x
>
> So, there is no "direct" sound of the drums, and what you're hearing is a
> processed version.
>
> Cheers,
> Chris
>
>
>>
>> Thanks
>> -Nick
>>
>
>