Tone.connect does not seem to work

[maximedupre]

The Tone.connect method isn't listed in the doc. However I did find the method doc by navigating to the url directly (https://tonejs.github.io/docs/14.7.39/fn/connect).

As you can see in this fiddle, I can't seem to connect a native gain node to a Tone gain. If I understand, the Tone.connect method's purpose is to connect a native audio node to a tone node, right?

[tambien]

As long as that context is wrapped in the standardized-audio-context wrapper (so don't take the private property _nativeContext) then that's how it should work. Tone.connect still requires the same AudioContext and in the situation that you've given, it's actually a subtly different AudioContext. Tone.context.rawContext is an instance of StandardizedAudioContext and Tone.context.rawContext._nativeContext is an instance of the browser's native AudioContext.

If you'd like to connect things up in the latter way, then you'd have to use Tone.setContext(yourNativeAudioContext), but you'd lose all of the benefits of standardized-audio-context's cross-browser compatibility.

so to modify your code so that it works would look like this:

const toneNativeAudioContext = Tone.getContext().rawContext;
const nativeGain = toneNativeAudioContext.createGain()
console.log(nativeGain instanceof AudioNode)
Tone.connect(nativeGain, new Tone.Gain());

nativeGain instanceof AudioNode now would return false, but if that's an important check you could use std-audio-context's isAnyAudioNode instead.

[maximedupre]

Thanks for the answer.

My use case involves an AudioWorkletNode. Unsurprisingly, the browser throws an error when attempting to create an AudioWorkletNode with a StandardizedAudioContext: new AudioWorkletNode(Tone.getContext().rawContext, 'someName');

I see that tone solves this problem with https://tonejs.github.io/docs/14.7.39/Context#createAudioWorkletNode. However, I'm using a custom AudioWorkletNode, e.g. class CustomAudioWorkletNode extends AudioWorkletNode { ... }. Is this feature currently supported? If not, does a workaround come to mind?

Edit 1

I guess it is supported by doing this: class CustomAudioWorkletNode extends Tone.getContext().rawContext.audioWorklet { ... }. Will report back. Cheers!

Edit 2

Yeah that doesn't work, I thought Tone.getContext().rawContext.audioWorklet would be the AudioWorkletNode class, but of course that doesn't make sense lol.

Edit 3

import {AudioWorkletNode} from 'standardized-audio-context'

class CustomAudioWorkletNode extends AudioWorkletNode {}

This works. @tambien Do you think that Tone should expose AudioWorkletNode from its own API? Tone.getContext().AudioWorkletNode?

Edit 4

If you think that exposing AudioWorkletNode from Tone is a bad idea, and if you would like Tone to support custom AudioWorkletNodes, then you would need to add standardized-audio-context as a peer dependency instead. If two different versions of standardized-audio-context are installed, this will break things as each version would have it's own "audio context store" (which is what I just experienced).

[tambien]

I think Edit 3 is the approach that i'd recommend. Here's a small example which is working well for me and seems to be pretty readable.

[maximedupre]

@tambien As I said, Edit 3 will work, as long as the AudioContext it uses comes from the same standardized-audio-context "audio context store". Imagine a scenario where you are installing a library that exports a 'CustomAudioWorkletNode". If this library uses a different version of standardized-audio-context, it will not be possible to connect CustomAudioWorkletNode to any other tone node, because they are originating from two different audio context stores. The solution to that would be to add "standardized-audio-context" as a peerDependency instead of a dependency. This might have already been clear to you, but I just wanted to make sure I explained the problem fully. Whatever you decide is fine with me, I am in control of the other said library, so I can add standardized-audio-context as a peer dep of this other library. But that might not always be the case for other people. Cheers!