Re: AUMonotimbralInstrumentBase (synthesiser) best design practices
Re: AUMonotimbralInstrumentBase (synthesiser) best design practices
- Subject: Re: AUMonotimbralInstrumentBase (synthesiser) best design practices
- From: Douglas Scott <email@hidden>
- Date: Mon, 21 Jun 2010 17:03:49 -0700
On Jun 17, 2010, at 11:15 AM, Jon Crooke wrote:
> hi all,
>
> i'm finally getting properly stuck into my CS synthesiser project now, and have spent some time examining the AU instrument template in xcode, performed quite a few experiments, and am more or less ready to get stuck into the nuts and bolts of designing my instrument
>
> i did, however, want to take advantage of the experience on here with regards to design. i certainly want to make my instrument as portable as possible, and was wondering the best way to go about this. from what i can see, a Note class (subclass of SynthNote) will define a single voice of the instrument. since i would like the instrument to be loosely coupled to the AU framework, i'm wondering what the most appropriate design pattern would be:
>
> at the moment i'm thinking of making creating a Voice class, which with be a member of the Note (SynthNote subclass). this class will probably encapsulate a single synthesiser voice, in this way the Note class is just a wrapper. i imagine i'll need to store a pointer back to the Note as well, in order to take advantage of the inherited SynthNode member functions?
I am having a bit of trouble visualizing this. Is this what you mean:
class Voice {
Voice(Note *inNote); // constructor is passed the object which refers to us
// custom, loosely coupled implementation of a synth voice
...
public:
void DoKillOperation(UInt32 inFrame); // example of a public method called through from wrapper
...
private:
Note *mNote;
...
};
class Note : public SynthNote {
...
Voice *mVoice;
...
public:
void Kill(UInt32 inFrame) { SynthNote::Kill(inFrame); mVoice->DoKillOperation(inFrame); }
};
If this is what you mean, the biggest problem is that this "proxy" design pattern is very useful if the base class (SynthNote in this case) is nearly or entirely abstract. This allows all the virtual public member functions on the base class to be redefined to call through to your Voice class. Unfortunately, that is not the case with SynthNote -- it contains a large amount of state, and many member functions which are not virtual. It's not that what you propose is necessarily impossible -- just much more complicated than using inheritance. You will constantly have to refer back to the referenced Note.
>
> also, i was wondering why the TestNote "class" is defined as a struct in the provided AU instrument template. are there performance benefits? a convention? or just because all members should be public? sorry, my C++ isn't the best!
Using class vs. struct does not effect anything other than the default access level to the members of the object. No convention either. If you want my advise, don't use structs which can encourage direct manipulation of the object's state. Use a class and create inline methods to control access to the state.
>
> apologies for the newbie questions! i hope someone can't let me know if i'm on the right path, or save me wasting a lot of my time!
>
I don't know if I put you on or off the path with this -- if my diagram does represent what you propose, just think through the entire use case set for your proxy class to make sure you don't get stuck way down the road.
-Doug Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden