• 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: FINAL CUT PRO crashing with audio units
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FINAL CUT PRO crashing with audio units


  • Subject: Re: FINAL CUT PRO crashing with audio units
  • From: Bill Stewart <email@hidden>
  • Date: Thu, 25 Sep 2003 17:56:49 -0700

On Wednesday, September 24, 2003, at 08:20 PM, Cyril Blanc wrote:

Dear Apple audio expert !


Can you help Final cut pro's programmers to be able to run AUDIO units
without crashing.

The AU I have tried are working with Logic audio !

The problem is essentially not with Final Cut, but with the AU's in question - ie, the AU's aren't implemented to the specification. This can't be used as a metric to judge an AU's quality, completeness, conformance, or robustness. If an AU works in a particular host app, does not mean that the AU is both well behaved or suitable for general usage.

Before you start flaming, please read the remainder of this email :)

We've been developing a validation tool for Audio Units that puts any AU through a set of compliance tests. We felt this was necessary given two areas of concern over the last few months:
(1) Some implementations of AU's are based not on the CoreAudio SDK, but on other interpretations of this (and some of those interpretations are incorrect), thus the resulting AU's are not compliant with API usage/definitions. We've worked closely with developers whilst implementing the validation tool to both understand where those inconsistencies are, to have the validation tool catch these errors, and have these AU's (or their base implementations) revised to be correct

(2) During the early part of this year (and the latter part of last year) we went through some revisions with AU developers (you can look through the list archives for some of these), that we also thought was important to codify and enforce for the sake both of clarity and usability.

Of course, the overriding concern here is to have a tool that provides some definitive and demonstrable usage scenarios for AU's - no amount of documentation, etc, can demonstrate this to every(any)one's satisfaction. Thus, the validation tool, thus you either pass or fail it.

At this point the validation tool is essentially complete and we're just going through the process of making this available to anyone.

There is *no* host that represents the complete and definitive implementation of AU hosting; different hosts use the AUs in different ways according to their needs, etc. The intention of the validation tool is to capture as much of the AU API as possible, verifying both correctness, conformance and stability. If an AU passes validation then that provides a certain degree of confidence that this AU will work in *any* host environment.

The validation tool will not catch semantic "problems". For instance, AU's provide a rich parameter mechanism that we believe to be useful and reasonable (and extensible). But, an AU can pass validation by publishing all of its parameters as "generic" with a 0-1 range. In some usage scenarios, this makes the AU essentially unusable . I don't want to debate the merits of this - we've agreed to disagree here I think. The point I want to make is that the validation tool does not make "value" judgments. It checks your grammar, but not your meaning.

Apple's AU's in Panther (and with the Jaguar Quicktime 6.4 release) pass the validation tool (as you'd hope and expect!). AU's from 3rd parties that are based on our April release of the CoreAudio SDK essentially pass the validation tests. Developers that are working with the validation tool have found this I think an extremely useful tool to both understand the expectations we have and to fix their implementations (particularly where those implementations are not based on the most recent CoreAudio SDK base classes).

Finally, this is an area of concern for us; one that we care deeply about to fix. We will continue to lend support, etc, as needed to ensure that AU plugins represent a predictable and robust format for Audio plugins on Mac OS X across a variety of applications and usage scenarios.

Bill



Thanks in advance.

Best regards

Cyril Blanc
France

If you want to be sure I read your answer leave my name in it !
Spam mails are directly going to trash
_______________________________________________
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.


-- mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __
_______________________________________________
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:
    • Validation Tool (was Re: FINAL CUT PRO crashing with audio units)
      • From: Neil Johnson <email@hidden>
    • Re: FINAL CUT PRO crashing with audio units
      • From: Cyril Blanc <email@hidden>
References: 
 >FINAL CUT PRO crashing with audio units (From: Cyril Blanc <email@hidden>)

  • Prev by Date: Output card
  • Next by Date: Re: FINAL CUT PRO crashing with audio units
  • Previous by thread: FINAL CUT PRO crashing with audio units
  • Next by thread: Re: FINAL CUT PRO crashing with audio units
  • Index(es):
    • Date
    • Thread