Return to Answer

It sounds like you were asking Vue to convert these Tone synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of unnecessary mutations in your Vuex data store.

A simple solution is to keep those Tone objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, and even bind it to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their names as property names in the data object).

As an example, let's say you want some range inputs to control parameters of a Tone Synth. You could v-bind those inputs to computed setters in your component to automatically your Vuex Store, and also watch those same properties to perform Tone object updates.

The larger point here is you probably shouldn't track code you didn't write unless you have sufficient reason to because who knows how much extra work it could generate. Additionally, in this case, Tone objects are the boundaries of your reactivity systems in that nothing in your app code is dependent on them. Their job is to communicate with the browser internals.

It sounds like you were asking Vue to convert these Tone synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of unnecessary mutations in your Vuex data store.

A simple solution is to keep those Tone objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, and even bind it to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their names as property names in the data object).

As an example, let's say you want some range inputs to control parameters of a Tone Synth. You could v-bind those inputs to computed setters in your component to automatically update your Vuex Store, and also watch those same properties to perform Tone object updates.

The larger point here is you probably shouldn't track code you didn't write unless you have sufficient reason to because who knows how much extra work it could generate. Additionally, in this case, Tone objects are the boundaries of your reactivity systems in that nothing in your app code is dependent on them. Their job is to communicate with the browser internals and the surrounding operating system to produce sound.

It sounds like you were asking Vue to convert these Tone.js synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of mutations in your Vuex data store.

The solution is to keep those Tone.js objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, even if it's bound to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their names as property names in the data object).

But let's say you want to offer inputs to control the parameters of a Tone.js Synth. In this case, put the parameters into your vuex store, but still exclude the Synth. You can use the 'watch' feature on a given component to update your Tone.js objects when the reactive parameters change.

The larger point here is: don't track code you didn't write unless you have sufficient reason to. Here, you don't have sufficient reason to track it because it's a boundary of your application that interfaces with the master output and the surrounding operating system. Nothing else in your application has it as a dependency.

It sounds like you were asking Vue to convert these Tone synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of unnecessary mutations in your Vuex data store.

A simple solution is to keep those Tone objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, and even bind it to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their names as property names in the data object).

As an example, let's say you want some range inputs to control parameters of a Tone Synth. You could v-bind those inputs to computed setters in your component to automatically your Vuex Store, and also watch those same properties to perform Tone object updates.

The larger point here is you probably shouldn't track code you didn't write unless you have sufficient reason to because who knows how much extra work it could generate. Additionally, in this case, Tone objects are the boundaries of your reactivity systems in that nothing in your app code is dependent on them. Their job is to communicate with the browser internals.

It sounds like you were asking Vue to convert these Tone.js synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of mutations in your Vuex data store.

The solution is to keep those Tone.js objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, even if it's bound to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their property names in the data object).

But let's say you want to offer inputs to control the parameters of a Tone.js Synth. In this case, put the parameters into your application state, but still not the Synth. You can use the 'watch' feature on a given component to update your Tone.js objects when the reactive parameters change.

The larger point here is: don't track code you didn't write unless you have sufficient reason to. Here, you don't have sufficient reason to track it because it's a boundary of your application that interfaces with the master output and the surrounding operating system. Nothing else in your application has it as a dependency.

It sounds like you were asking Vue to convert these Tone.js synth objects into reactive objects, which means it descends into them and wraps every property into a getter and setter so it can keep track of any mutations. When you call a method on a synth, it modifies its own properties, creating a whole chain of mutations in your Vuex data store.

The solution is to keep those Tone.js objects out of your Vuex data store. You can import them, instantiate them, and call methods on them from within a component, even if it's bound to the component, but just make sure they're not made reactive (you can, e.g., instantiate/bind them to the component in the created lifecycle hook, but make sure not to include their names as property names in the data object).

But let's say you want to offer inputs to control the parameters of a Tone.js Synth. In this case, put the parameters into your vuex store, but still exclude the Synth. You can use the 'watch' feature on a given component to update your Tone.js objects when the reactive parameters change.

The larger point here is: don't track code you didn't write unless you have sufficient reason to. Here, you don't have sufficient reason to track it because it's a boundary of your application that interfaces with the master output and the surrounding operating system. Nothing else in your application has it as a dependency.