Community Q&A

Where Wwise users help each other out!

Audiokinetic's Community Q&A is the forum where Wwise users ask and answer questions within the Wwise community. If you would like to get an answer from Audiokinetic's Technical support team, make sure you use the Support Tickets page.

How to synchronize properties in a plugin

0 votes
For a custom Wwise mixer plugin we would like to give our sound designers the option to specify speaker locations in either Cartesian (X,Y,Z) or spherical (r,theta,phi) coordinates. For each speaker there are thus 6 defined property fields. The problem we are encountering now is how to keep these fields synchronized, so that changing one set of coordinates will update the other set accordingly.

Looking at the Wwise documentation I do not see a single good entry point that would allow us to modify properties both in the authoring plugin and the runtime/sound engine plugin.

The authoring plugin receives NotifyPropertyChanged() callbacks where we could calculate coordinates and then use IPluginPropertySet::SetValue() to update all affected fields. Obviously NotifyPropertyChanged() is authoring-time only and would not be called during gameplay.

The runtime/sound engine plugin receives SetParam() calls. Because the IAKPluginParam class has no pointer to the sound engine plugin I cannot directly update the other coordinate fields in response to SetParam calls. Looking at some of the sample code I see that one option is monitoring changes to any parameters and then inside of OnFrameEnd() recalculate all the fields. However, OnFrameEnd() is only called while the plugin is processing sounds, so it would not be called while the user is typing values into the text fields.

We can work around this in a couple of ways but that would mean either losing RTPC capabilities or duplicating code. What is the best approach here?
asked Apr 22 in General Discussion by Marco G. (100 points)

1 Answer

0 votes
Given that you have two sets of related properties (Cartesian and Spherical 3-values coordinates), I would expect your model (the properties defined in your XML) to only have one of those two representations and compute the other set on-the-fly. Having two sets of properties for essentially the "same" properties will not play well with things like undo and may create lag when synchronization is not done on the same frame. Instead, I suggest to use a single representation, typically the one used to do the heavy lifting in your runtime implementation.

On the UI side, that implies to indeed update the value of the fields manually using something like NotifyPropertyChanged(). Another option would be to allow your users to switch between the two representations and specify in your model the format in which your properties are currently set and do the conversion to the runtime format at bank write time and in SetParam/SetParamBlock.

Hope this helps.
answered May 22 by Samuel L. (Audiokinetic) (640 points)
...