• 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
"generic" views
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"generic" views


  • Subject: "generic" views
  • From: Bjorn Roche <email@hidden>
  • Date: Sun, 30 Apr 2006 10:53:37 -0400 (EDT)

Hey all,

I have a multi-process audio app that I'd like to add audio unit support to. The problem is that the GUI and actual audio processing are in two separate precesses. I've asked about this before, and got a nice response from William Stewart:

http://lists.apple.com/archives/coreaudio-api/2006/Mar/msg00114.html

(I think I forgot to thank you, so let me do that now: Thank you, William).


Reading up on this a bit more, it seems like it's possible to create useful -- possibly very useful -- support for audio units by building my own GUIs using the parameter info data structures provided by the Audio Unit. I would basically be creating a "generic" view of the effect (a processes which is mentioned here: http://developer.apple.com/audio/audiounits.html)[1]



So three questions remain before I start hammering away at code:

1. Is it possible to perform metering this way? Is metering generally done in a sufficiently "generic" way for me to provide meters required by, for example, apple's multi-band compressor? I'm not finding info on how metering is usually implemented in an Audio Unit (I presume through a read-only parameter with some special designation, which would be great). Obviously, many effects will be useless without metering.

2. Does anyone have a sense of how many plugins won't work with this? My impression is that apple's built-in plugins will work and many if not most commercial plugins will work (assuming an affirmative answer to question #1), though, obviously, they won't look as slick. On a related but less important note: can plugin types be converted from other types, such as VST, be expected to work with generic views?

3. Any other thoughts, opinions, or comments that might be helpful? (this includes telling me I am completely off my rocker, if that's the case.)


Thanks in advance!

	bjorn


[1] building generic views is done in order to support Audio Units that have no views, or have a view that is incompatible with the host. eg. carbon host opens an audio unit with a cocoa gui. I imagine pro apps provide AU hosting by taking the advice given here: /Developer/Examples/CoreAudio/Documentation/AudioUnits/CarbonViewCocoaWindow.rtfd but perhaps most AU are written using either cocoa or carbon and pro apps only support one or the other. I'd be interested in comments about that as eventually I'd like to add "real" support for Audio Units.




-------------
Bjorn Roche
Check out my CD Mastering Software
for Mac OS X : http://www.xowave.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
  • Prev by Date: inOffsetSampleFrame?
  • Next by Date: loading plug-in prevents host from hiding
  • Previous by thread: inOffsetSampleFrame?
  • Next by thread: loading plug-in prevents host from hiding
  • Index(es):
    • Date
    • Thread