SpatialSource.h

Go to the documentation of this file.
00001 //
00002 //  SpeakerSource.h -- Spatial Sound Source
00003 //  See the copyright notice and acknowledgment of authors in the file COPYRIGHT
00004 //  Created by Jorge Castellanos on 6/16/06. Hacked 8/09 by STP.
00005 //
00007 
00008 #ifndef SOUND_SOURCE_H
00009 #define SOUND_SOURCE_H
00010 
00011 #include "CSL_Core.h"
00012 #include "CPoint.h"
00013 
00014 namespace csl {
00015 
00016 //class SpatialProperties {
00017 //public:
00018 //  SpatialProperties() : mPosition(0.f), mRoot(NULL), mPositionChanged(true) { };
00019 //  ~SpatialProperties() { };
00020 //
00021 //  float mPosition;
00022 //  UnitGenerator *mRoot;
00023 //  bool mPositionChanged;      //< true if this source's position has changed
00024 //  
00025 //};
00026 
00028 
00029 class SpatialSource : public UnitGenerator, public virtual Scalable {
00030 public:
00031     SpatialSource();                        
00032     SpatialSource(UnitGenerator &input, float azi = 0.0, float ele = 0.0, float dist = 1.0);
00033     virtual ~SpatialSource();
00035     virtual void setPosition(CPoint pos); 
00036     virtual void setPosition(float x = 0., float y = 0., float z = 0.); 
00037     virtual void setPosition(double x = 0., double y = 0., double z = 0.); 
00038 
00040     virtual void setPosition(char s, float azi = 0, float ele = 0, float dist = 1.0) ;
00041     virtual void setPosition(char s, double azi = 0, double ele = 0, double dist = 1.0) ;
00042     CPoint & getPosition() { return ( * mPosition); };
00043 
00044 #ifdef DIRECTIONAL_SOURCES
00046     void setOrientation(float horizontalAngle, float verticalAngle); 
00048     void setDirectivity(float innerConeAngle, float outerConeAngle); 
00050 #endif
00051 
00052     void setAzimuth(float val)  { mPosition->setAzimuth(val); };        
00053     void setElevation(float val) { mPosition->setElevation(val); };     
00054     void setDistance(float val) { mPosition->setMagnitude(val); };      
00055         
00056     float azimuth() { return mPosition->theta(); };                     
00057     float elevation() { return mPosition->ele(); };                     
00058     float distance() { return mPosition->r(); };                        
00059 
00060     CPoint *position(unsigned channelNum = 0);
00061 
00063     virtual bool positionChanged() { return mPositionChanged; };
00064 
00065     virtual void nextBuffer(Buffer & outputBuffer, unsigned outBufNum) throw (CException);
00066     virtual void nextBuffer(Buffer & outputBuffer) throw (CException);
00067 
00068     void dump();
00069 
00070 protected:
00071     CPoint *mPosition;                  
00072     bool mPositionChanged;              
00073 
00074 #ifdef DIRECTIONAL_SOURCES
00075     float mInnerCone;
00076     float mOuterCone;
00077     float mHorizontalOrientation;
00078     float mVerticalOrientation;
00079 #endif
00080     
00081 };
00082 
00083 /*
00084     DESIGN THOUGHTS:
00085     Possibly Source could be called PositionableSource and be the base class of other Spatial Sources.
00086     For example, a subclass could include directivity and radiation pattern, wich is less common than position
00087     Also, different ways of sound radiation could be implemented by subclasses. 
00088     
00089     A second option is to specify sound radiation directly to the object that does the actual computation.
00090     This way the different processors could accept their very particular way of doing things.
00091     This approach would break with the concept of having the sound source KNOW its own characteristics.
00092     Cons: not only the processors of directivity, but also procesors of room acoustics would make use of 
00093     such info, so user would have to specify it twice (this could be a feature, as it would allow different
00094     types, one simpler for reflections, and a possibly complex one for the direct sound. 
00095     
00096     Maybe the answer is that sound radiation is not just a record class, but it responds with an actual value
00097     (or filter?) when asked for the value at x angle. That way the different types of pattern would know how to
00098     do their shit, but mantaining a common interface and return type, so it can be processed.
00099     
00100     Or.. should I just decide for one method and stick to it? That would defeat the purpose of an extensible
00101     framework made to be used for research, as well as for making content.
00102     
00103 */
00104 }
00105 
00106 #endif

Generated on Thu Sep 17 23:14:16 2009 for CSL by  doxygen 1.5.8