Re: [VST2.4 -> AU] host and property notifications
Re: [VST2.4 -> AU] host and property notifications
- Subject: Re: [VST2.4 -> AU] host and property notifications
- From: Brian Willoughby <email@hidden>
- Date: Thu, 07 Mar 2013 01:57:19 -0800
On Mar 7, 2013, at 01:19, Domagoj Saric wrote:
I'm currently upgrading our internal plugin framework to support
AUs and am bypassing the CoreAudio SDK (the old "virtual and new
everything" design, and error codes mixed with exceptions and
gotos, doesn't quite fit nicely with a more modern CRTP-like
approach we use internally and adds too much fat for the help it
provides) and am having a number of questions/problems so please
help me out ;)
Good luck bypassing the CoreAudio SDK. It is theoretically possible,
but I am not aware of anyone who has ever done it. You're setting
yourself up for a huge development effort as your first attempt at an
AU if you do this.
The VST2.4 protocol, as bad as it is, at least defines a minimal
set of notifications that one can "send" to a host. If, for
example, a user changes (through the GUI) the input/output format/
number of channels/buses or loads a preset (which changes the
parameter list and/or the parameter information for existing
parameters) I can only issue a property change notification but
nothing guarantees that a host will actually register a listener
for the particular property and that even if a listener is
registered that it is in fact the hosts listener (and not some
other AU 'listening' to my AU) and that the host actually accepted
the property change. For some 'properties', like the IO format/
configuration, it is crucial that the plugin/AU and the host are in
sync (otherwise the host might provide less channels then the
plugin expects...)...
Am I missing something, or should user changes/"from within the AU"
of such properties simply be forbidden for AU builds?
The AU is not the pilot or navigator of an audio application, it is a
passenger. The AU Host is the pilot/navigator, and it controls
crucial settings like format and configuration. These are handled at
the time of Initialize() and cannot be changed until Cleanup() and
Uninitialize(). Don't worry, a proper AU never is out of sync with
it's host, but it's not because the AU makes it so - besides,
multiple AUs would fight over the configuration if the host weren't
in charge.
As for number of channels, the AudioUnits specification spells out
how to mark your AU as needing a particular number of channels. In
other words, this particular information - channel requirements - are
not communicated to the host by notifications, but by returning the
correctly initialized structures when the AU Host requests them.
A related question is about property change notifications in
general. There seems to be more than one mechanism:
- property change listeners
- AudioUnitEvent and AUEventListenerNotify with
kAudioUnitEvent_PropertyChange as described here http://
developer.apple.com/library/mac/#technotes/tn2104/_index.html
The latter seems like a "happier" solution (that could possibly
solve some of the earlier mentioned concerns) but the documentation
for AUEventListenerNotify says: "This is only to be used for
notifications about parameter changes (and gestures). It can not be
used for notifying changes to property values as these are internal
to an audio unit and should not be issued outside of the audio unit
itself."
And indeed AUEventListenerNotify fails if I try it with
kAudioUnitEvent_PropertyChange...
I found this problem discussed for example here:
http://lists.apple.com/archives/coreaudio-api/2009/Dec/msg00224.html
http://www.kvraudio.com/forum/viewtopic.php?p=2832575
If kAudioUnitEvent_PropertyChange cannot be used why is it there in
the first place?
The logical corollary to "should not be issued outside of the audio
unit itself" is that property changes should be issued within an
audio unit. In other words, the GUI and DSP engine communicate with
each other via properties, and it's even possible for the GUI and DSP
to each be running on a different processor or machine. I may be
missing something here, but all the documentation means is that the
host cannot be aware of the opaque data payload in a property, and
thus the host and AU cannot communicate via property changes. But, as
I mentioned above, this does not preclude the GUI and DSP from
communicating property values.
On Mar 7, 2013, at 01:26, Domagoj Saric wrote:
How can one specify that a parameter cannot take just any value
between its minimum and maximum values?
For example, a power-of-two like parameter (e.g. DFT size) cannot
be set to 513...
If the AU protocol does not provide a way to specify such
behaviour, how should an AU handle this? Check for values in
setParameter() and reject invalid ones with the (nonexistent)
kAudioUnitErr_InvalidParameterValue error code?
In that case, I would recommend making the parameter be the power, as
an integer, and calculate the actual value internal to the AU (as
well as in the GUI). You can even use a string table to display the
calculated value to the user without requiring a custom GUI.
The AudioUnits specification also allows one parameter to be defined
as dependent upon another parameter, such that you could have both
the power itself and the calculated value as parameters.
I'm not really sure about discontiguous parameters, but it might be
possible to return an error code for illegal, in-between values.
Brian Willoughby
Sound Consulting
_______________________________________________
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