Re: AU host properties
Re: AU host properties
- Subject: Re: AU host properties
- From: Marc Poirier <email@hidden>
- Date: Tue, 6 May 2003 02:33:33 +0200 (CEST)
>
>> It's also useful to be able to identify the host... VST has
>
>> host::getProductString and host::getVendorString, not sure if there's
>
>> an equivalent in AU so far.
>
>
>
> I requested this many months ago and then was asked why I wanted that
>
> feature. I said that we have it with VST and sometimes hosts don't do
>
> something correctly and you need to provide workarounds for that. I
>
> was then told that hosts should simply follow the API and we should
>
> not need such hacks, and that if any host fails, then they will need
>
> to correct their mistakes and can't rely on plugins to do selective
>
> workarounds. So in other words, the request was rejected, which
>
> probably is all the better...
>
>
It's true that you should write your plugin to the spec, and then
>
identify hosts that break (and get the developers to acknowledge it).
>
But when it comes down to shipping time and you have a plugin that you
>
know is right, and a host app that you know is wrong but with many
>
users... who wouldn't put in a workaround? Having the host identifier
>
property would simply make it easier to target workaounds at specific
>
broken versions of hosts..
Right, of course. But I'm just saying that that has already been
acknowledged, and rejected. There are arguments for both positions, and
the CA folks took the plugin-is-blind-to-the-host position. But maybe
they'll change their mind now, I dunno...
>
It would probably be good to break host identifier info into several
>
pieces. Maybe vendor, product, version (maybe with numeric versions as
>
well), and creator code.
>
>
So, here's how I imagine this would all work. This is designed within
>
the current system. It could be certainly easier if certain existing
>
API calls were extended, but that's probably bad.
>
>
1. create AU instance
>
2. during initialisation, the host optionally sets a
>
kAudioUnitProperty_HostPropertyCallback value
>
>
the callback should look similar to:
>
>
OSStatus HostPropertyCallback(AudioUnit inUnit, AudioUnitPropertyID
>
inProperty, CFTypeRef* outValue);
>
>
I think CF types are sufficient. Any needed property data can be
>
wrapped up in one, and most will probably already need to be a CF type.
>
>
Then AUBase could add a new member function:
>
>
OSStatus GetHostProperty(AudioUnitPropertyID inProperty, CFTypeRef*
>
outValue) const;
>
>
Although it would require a change to the current scheme, we could move
>
the beat and time callback to be a property. This would make it easier
>
on the host because it would only have to set and implement one
>
callback. And you could even break out the values returned by the
>
beat/time callback... for instance to be able to just get the current
>
tempo.
Whether or not the general idea of hosts providing identifying info to
plugins is good or not, I will at least say that I don't think, if it's
implemented, it should be implemented with callbacks. Why would this info
need to be a callback? It's not dynamic or context sensitive. Just make
a kAudioUnitProperty_HostIdentityInfo property (or something like that)
which the host app Sets. You could add a struct to the API, something
like this:
struct AUHostIdentityInfo {
CFStringRef hostAppName;
CFStringRef hostCompanyName;
UInt32 hostCreatorCode;
UInt32 hostVersionNumber;
etc...
};
and then the host passes along a struct like that (all filled in) when it
Sets that property, which the host should do upon creating the AU. That
makes more sense to me then using a callback. That is, if it even is a
good idea to give a way for the host to supply this info to plugs...
Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.