Re: Coreaudio-api Digest, Vol 6, Issue 365
Re: Coreaudio-api Digest, Vol 6, Issue 365
- Subject: Re: Coreaudio-api Digest, Vol 6, Issue 365
- From: Ian Kemmish <email@hidden>
- Date: Wed, 23 Sep 2009 19:07:48 +0100
On 22 Sep 2009, at 12:07, Taylor Holliday <email@hidden> wrote:
etc). My inference from reading the Audio Unit programming guide is
that such complex interactions between view and model can be
facilitated by AudioUnitProperties and their associated events. Is
that correct? How are these sorts of more complex interactions
typically handled?
Yes.
There are two choices, I think - you can have a small number of
properties, each of which corresponds to a nasty structure (e.g. one
per module); or you can have a larger number of properties, each of
which corresponds to a quantity manipulated by a single UI control (so
each module owns a whole cluster of properties). I chose the second,
since property IDs are plentiful (and it makes user input and property
listener code a lot easier to read).
The way I did it was I first of all decided how many different kinds
of things I wanted the UI to handle. (For example, in my synth,
envelopes are a separate kind of object, not part of a module; when a
module needs an envelope it asks the synth for one and gets a handle
to a separate envelope object - so for me the UI deals with modules
and envelopes separately, although of course the user doesn't notice.)
Then I divided the universe of valid property IDs up into suitable
sized chunks for each kind of thing - so for example, property IDs
between 100000000 and 200000000 might apply to oscillator modules.
Property IDs can be sparse - you don't need to start at 65537
(remember to leave room for Apple's property IDS!) and count up.
Oscillator modules will have a few "standard" properties common to all
of them - name, type, UI colour and position, number of oscillators
(mine's an additive synth), and so on - as well as a few which are
peculiar to each module type (e.g. harmonic, inharmonic, resynthesis
etc.)
So for example, property 100000000 might be the name of the first
oscillator module, 100000001 its common UI stuff, 100000002 its number
of oscillators, 100000003 its type, 100000004 - 1000000xx its type-
specific properties, 1000000xx + 1 the name of the second oscillator
module, and so on....
Each type of module has an objective-C class which implements the UI
for that module. Then you only need to give each instance of that
editor class the base property ID for the module instance (100000001,
100000014, ..... in the above example) and let the editor get on with
it.
Higher levels of the UI - module creation, patching, and deletion,
only deal with the "standard" properties for the modules and ignore
the private properties.
I can only think of one gotcha I encountered doing this: you may need
to review the sample property listener code in the base AU classes.
The sample code (or at least the old version I started with) uses
fairly straightforward C++ stuff for maintaining the lists of
listeners; I found that - because of the particular way I wrote my UI
- when I deleted a module, I ended up calling
AudioUnitRemovePropertyListener() from within a property listener
proc. That broke the sample code, but its easy enough to fix up if
you need it to be more sophisticated.
Hope this helps.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44 7952
854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
_______________________________________________
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