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: Admiral Quality <email@hidden>
- Date: Thu, 07 Mar 2013 08:03:32 -0500
If you prefer VST over AU and want to maintain only one code base, use
Symbiosis...
https://code.google.com/p/symbiosis-au-vst/
- AQ
On Thu, Mar 7, 2013 at 4:57 AM, Brian Willoughby <email@hidden> wrote:
>
> 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
_______________________________________________
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