Re: Channels and frames
Re: Channels and frames
- Subject: Re: Channels and frames
- From: Marc Poirier <email@hidden>
- Date: Tue, 1 Nov 2005 09:12:32 -0500
On Nov 1, 2005, at 7:00 AM, john smith wrote:
Yes, this is what I would have thought as well. Why make the user
go through all of this - and this will in any case be broken with
any other host that uses the version number to cache information,
unless you have a way for a user to invalidate this cache.
Because it's a cross-platform product.
A problem that has been tackled many times before. It's called
branching your code when necessary.
Then, of course, you have to - ad infinitum - explain to every
user how to do this with every host they use
Yes, that's a problem with the solution I was offered. We would
need to explain for each host. Hmm, that's not good.
So, it looks to me like a version number of 0 is the only option...
Except that that will only work for Logic, as pointed out. That's
not a standard AU feature, just a little convenience debug thing that
Logic threw in. Probably even subject to change within Logic.
- How do you tell a GB user for instance, to do this?
Sorry, GB?
GarageBand.
A Digital Performer user
Digital Performer has VST support, right?
Wrong.
etc,.. A "solution" that is
targeted at a specific host app is not going to be sufficient for
broad usage of your AU.
I agree. So, what's the option? As I said in a previous mail, if we
remove it from the interface, then we have to explain in the manual
that "there's a setting for output channels, which can, bla. bla,
expect for AU hosts". Or something like that.
It just strikes me as unnecasary complicated, and the user will be
asking himself "why not, what's wrong with AU".
Then you'll have to explain what's wrong with your AU, not what's
wrong with AU.
As a general comment if you are sharing code between VST and AUs
I think you need to do this with a respect for the nuances of
the various specifications, rather than trying to bend one
solution to fit badly... This is of course, one of the big
challenges of supporting multiple formats or hosts, and we
certainly recognise that this is something all AU developers have
to deal with in one way or another.
I do it with respect for the nuances, when (and only when) it makes
sense. That sentence was not about this situation, just like I
assume your sentence wasn't.
Of course it's about this situation, that's what people are trying to
give you advice about. There is a fundamental difference between AU
and VST here: AU provides a clear mechanism for format negotiation,
VST does not. That's why you need an awkward workaround for VST to
implement your feature. For your AU version, you do not need to use
that. You simply publish your supported channel configurations with
SupportedNumChannels() and then accept those channel count changes if
and when the host tries to set them.
So, currently for an AU you should either publish your channel
capabilities as they are, or, every time you change your channel
capabilities, you should return a different version number for
your AU **AND** you need to edit the version number contained in
the component resource.
Hmm, it was recommended by some other guy (gretscher) that I
shouldn't do that. Strikes me as a bad solution as well (seems too
much of a hack).
Which one? There are two options above. I agree that the changing
the version number thing is a bit of a hack perhaps (though I'm not
positive I'm interpreting it correctly), but the first suggestion
most certainly is not a hack, it's just "the way AUs work."
On Nov 1, 2005, at 6:47 AM, john smith wrote:
it occurs to me that the only option left is for our plug-ins to
consistently use a version number of 0.
No, because you'd fail auval (and rightly so).
But why does it matter if I fail auval? It still shows up in Logic,
right?
Wrong.
Also, you'd be severing Logics launch time by having to rescan
your AU at every start.
But it's a solution that works.
If by "works" you means "works in Logic currently, but maybe not in
the future, and not in many other applications" (as has been pointed
out to you already)...
Marc
_______________________________________________
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