• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AU host properties
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU host properties


  • Subject: Re: AU host properties
  • From: Chris Reed <email@hidden>
  • Date: Mon, 5 May 2003 14:20:08 -0500

On Monday, May 5, 2003, at 08:57 US/Central, Marc Poirier wrote:

There is currently no way in the AU API to get the hosts preferred knob
action setting. (linear or circular). This is something that bugs me
every once in a while.

'though why anyone in their right mind would want circular is entirely a
mystery :-)

Heh heh, my thoughts exactly. ;-)

Same here...

And not to poke at Urs too much, but part of the reason I brought this up is that I want to use Zoyd etc with linear knobs! ;-)


I can't remember if there were any other host
settings like this that VST provides access to that are actually useful,
mostly since I am not too familiar with the VST API.

Can't think of any off the top of my head.. though I agree this is a useful
thing to provide... you could also ask the host whether it favours a
certain style of UI (Aqua, brushed-metal, "Apple creative apps"
FCP4/Soundtrack look), and whether it favours multitimbral or monotimbral
operation.

Painting the window theme (metal, stripes) should be done by the host
anyway. Unless I'm misunderstanding your suggestion...

I think Angus meant that an AU could switch between several skins depending on the host interface style, to look similar..


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..

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.

Does anyone think that this would also be useful for the CarbonEditView components? There's the host identifier, and Angus' idea about a host's preferred UI style. If so, it might be a good idea to change the inUnit to an inComponent of type Component so the host could share one callback for both the DSP and UI component instances.

Perhaps that's not necessary at all, and the UI can simply be required to read the host property callback from its AU if it needs any host infos.

cheers
-chris
_______________________________________________
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.

  • Follow-Ups:
    • Re: AU host properties
      • From: Urs Heckmann <email@hidden>
    • Re: AU host properties
      • From: Marc Poirier <email@hidden>
  • Prev by Date: Audio Unit -> QuickTime Broadcaster
  • Next by Date: Re: AU host properties
  • Previous by thread: Re: AU host properties
  • Next by thread: Re: AU host properties
  • Index(es):
    • Date
    • Thread