• 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: Making a waterfall display
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a waterfall display


  • Subject: Re: Making a waterfall display
  • From: Brian Willoughby <email@hidden>
  • Date: Mon, 28 Apr 2008 20:06:13 -0700

Rick,

There are both advantages and disadvantages to implementing an AudioUnit in a situation like the one you describe.

If you are only interested in showing the waterfall in your own application, or if you are willing to live with that restriction, then you may find it easier to avoid AudioUnits. The UI coding will be more challenging in the AU context, and you will need to learn the esoteric rules for communication between audio engine and UI that the AudioUnit API demands. Also, you would need to make your own application an AudioUnit host before you can even use your own waterfall display code. In this case, you'd find it much easier to just create a Cocoa application that is dedicated to your waterfall display.

However, if you are specifically interested in adding a waterfall display to other AudioUnit hosting software, then you must use AU, obviously. There are some advantages here, because you won't need to bother writing any code for accessing the audio data, since the host application will have standard means for opening files or input devices and feeding the data to any AU. In this respect, the tradeoff is that you don't have to write an entire application, just the specific core of your display code.

If you have no preference at all between the two options above, then it comes down to whether you'll find it harder to write an application which deals with a variety of audio sources, or learning the AudioUnit API (hosting, UI, etc.). Many programmers, even some seasoned individuals, find AudioUnits difficult to learn. If all of this is new to you, then you might enjoy quicker success with an integrated Cocoa application. My apologies if you're not a beginner, I'm merely making that assumption based on the typical questions that come through this list, and the brevity of your question.

Of course, an AudioUnit is certainly a valid choice, it's just not necessarily "the" choice - it all depends upon your other needs.

Brian Willoughby
Sound Consulting


On Apr 28, 2008, at 15:31, Rick Mann wrote:
I'd like to make a waterfall display (sourced from files or input device). Is an Audio Unit the appropriate place (along with its associated UI) to do this?


_______________________________________________
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


  • Follow-Ups:
    • Re: Making a waterfall display
      • From: Rick Mann <email@hidden>
References: 
 >Making a waterfall display (From: Rick Mann <email@hidden>)

  • Prev by Date: AU outIsPlaying parameter problems
  • Next by Date: AudioQueueNewOutput return value
  • Previous by thread: Re: Making a waterfall display
  • Next by thread: Re: Making a waterfall display
  • Index(es):
    • Date
    • Thread