Re: auval and you
Re: auval and you
- Subject: Re: auval and you
- From: "Angus F. Hewlett" <email@hidden>
- Date: Thu, 22 Mar 2007 05:57:07 +0000
Hi Brian,
Brian Willoughby wrote:
For one, you seem to be complaining that auval is not a perfectly
all-encompassing test - that there is much which is left out. Feel
free to write a better AU validation suite, but in the mean time, I
would prefer that we take full advantage of what we have, not cripple
it for an additional number of years because it isn't finding all
possible bugs.
I'm not for a moment suggesting that we cripple AUVal as a developer
tool -- I'm suggesting that putting it in the users' hands as part of
application bootup is not necessarily the right approach. I suppose
Apple's concern is that any weaker sanction (e.g. web site database of
passing AUs, seperate validator application that doesn't disable stuff
in apps) doesn't have strong enough teeth for developers to stand up and
take notice?
The real problem you are experiencing is twofold: first, that
developers of AudioUnits are ignoring auval for years until it
eventually gets into their users hands
Not necessarily ignoring it (although no doubt some do) -- more that I
can readily envisage a situation where it's unreasonable to expect
developers to issue fixes with a turnaround of months. If I'm in the
middle of a major refactoring or version upgrade exercise - which could
realistically take 18 months - or a product is simply on the back
burner, it costs much more time and money than you might imagine to
issue fixes for even a rather simple bug. Yes, for a product that's
awake and in the middle of an update cycle, this sort of thing is
inexpensive and minor to deal with, but a lot of the smaller commercial
devs' business models are predicated on being able to put products to
sleep for a year or two between releases. Maybe that's just unrealistic
for the AU world (in which case that should be in the FAQ).
I think it's reasonable to ask that Apple manage these end user releases
in a way that reasonably minimizes costs for third party developers, and
the only way to do that is to allow a grace period that's long enough to
fit in with the developers' update/upgrade cycle. Not to beat a dead
horse but, there are a lot of cool things in music-software that haven't
been able to happen over the past few years because 3rd party developers
have had to spend vast amounts of time keeping up with Apple's changes.
I'm not bashing, just pointing out a genuine issue that has been much
more of a problem on this platform than on the other one with all the
silly security alerts -- and plugin developers get hit by this harder
than everyone else, because the bridges on offer inevitably don't work
for plug-ins (yes, I know getting Classic or Rosetta work across the
plugin API boundary would not be a cost-effective use of engineering
resources -- we looked at it too!)
Another point I disagree on is your assertion that users will blame a
plugin (which fails auval) for bugs that are actually present in other
(passing) AUs or in the host itself. Any user who is trying to assign
blame had better be smart enough to disable plugins which fail auval
before making any assumptions about where bugs lie.
If only that were true. LOL!
Either way, you can address the problem by releasing a new AU which
passes auval.
Of course -- but see above.
As you point out, there are many bugs that auval cannot find. What we
need are more test suites which can find these additional bugs, or
extensions to auval to find additional bugs.
Absolutely, I agree 100% -- but such tools are only fit for developers,
not for end users -- most of whom, in my experience, can barely even
operate the file system, never mind read a crash log or troubleshoot
effectively.
Best regards,
Angus.
_______________________________________________
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