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: Domagoj Saric <email@hidden>
- Date: Mon, 25 Mar 2013 17:09:39 +0100
On 7.3.2013. 10:57, Brian Willoughby wrote:
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.
Well, the Symbiosis VST2.4->AU wrapper bypasses it and I've pretty much done it
too (with support for more AU 'peculiarities' than Symbiosis, and the plugin
binary actually turned out even slightly smaller than when it only supported
VST2.4 ;)
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.
This is all great in theory, the idea of plugins reporting their capabilities
and the hosts doing the management is certainly much cleaner than the mixed bag
of patches that the VST2.4 is. Unfortunately the AU is not quite clean here either:
- an AU reports its supported channel configurations and the host does the
"managing" but not its supported bus/element configurations...so a plugin that
optionally supports/requires side channel/bus input (like SpectrumWorx) still
has to notify the host that it has enabled/disabled a bus but it has no
guarantee that a particular host will be listening for
kAudioUnitProperty_ElementCount property changes...
- the "callback" vs "connection" distinction (that I still don't understand
why it exits) also makes a difference here: when a hosts "connects" two AUs it
is the duty of the downstream AU to synchronize its stream format with the other
AU (IOW the host _does not_ manage the stream format in this case)
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.
This ("properties, as such, are purely internal to a plugin and its GUI")
"cannot be true" because of the large number of Apple predefined properties,
some of which are obligatory for an AU to handle for it to pass validation and
which hosts (have to) use to communicate with and setup plugins.
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.
That's something along the lines I already had to do for VST2.4 and having to do
to this for AU too breaks my 'dream' that at least in AU I'll have simple,
direct mappings between automation and 'actual' parameter values :/
I'm not really sure about discontiguous parameters, but it might be possible to
return an error code for illegal, in-between values.
Well it certainly is 'possible' but since it is not explicitly discussed in the
documentation it will either be handled differently by each host or not
handled/expected at all so one can't actually rely on this...
--
Domagoj Saric
Software Architect
www.LittleEndian.com
_______________________________________________
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