The HOADecSATO class additionall has the following class variables:
speakerPositions: an array of Cartesian points of the speaker positions in meters as provided in ~spkrPos above.
sweeterPositions: an array of Cartesian points of the speaker positions in meters relative to the sweetspot.
The wrapper class (HOADecSATO... in our case) created using HOAAmbiDecoderHelper has two classvar's (speakerPosition and sweeterPositions) that contain an array of Cartesian objects. Cartesian is part of the MathLib quark, which means that your generated classes depend on MathLib. This kind of dependancy can lead to breakage. Users who install a decoder must have MathLib installed before moving any files into their Extensions folder. Failure to do so will result in a broken class library. They'll have to manually move the MathLib files into their downloaded-quarks folder in order to be able to use SC again.
Could the positions simply be kept as arrays of floats, rather than proper Cartesian points?
From HOA Tutorial Exercise 14:
The wrapper class (HOADecSATO... in our case) created using HOAAmbiDecoderHelper has two classvar's (speakerPosition and sweeterPositions) that contain an array of Cartesian objects. Cartesian is part of the MathLib quark, which means that your generated classes depend on MathLib. This kind of dependancy can lead to breakage. Users who install a decoder must have MathLib installed before moving any files into their Extensions folder. Failure to do so will result in a broken class library. They'll have to manually move the MathLib files into their downloaded-quarks folder in order to be able to use SC again.
Could the positions simply be kept as arrays of floats, rather than proper Cartesian points?