Re: ClassInfo & PresentPreset confusion
Re: ClassInfo & PresentPreset confusion
- Subject: Re: ClassInfo & PresentPreset confusion
- From: William Stewart <email@hidden>
- Date: Mon, 10 Oct 2005 14:16:57 -0700
I'll try to clarify some of the issues here.
On 10/10/2005, at 9:57 AM, Michael Kleps wrote:
I use "printf" to do debug-outputs and although Save/RestoreState
ARE called (sorry, my bad), no GetProperty/SetProperty calls to
change anything about the preset (CurrentPreset or PresentPreset)
are made at all.
Right:
CurrentPreset is deprecated in favour of PresentPreset, so that's all
I'll talk about (see the reference Marc listed earlier) - oh, I
should also add; everything Marc said about this was true.
PresentPreset and the ClassInfo property work in tandem. For an AU,
we have a general notion of presets - some saved state of the AU.
This is broken down into two broad categories -
(i) factory presets - shipped with the AU. There is a separate
property to get a list of these
(ii) user presets - this is saved state and as Marc said, *any* AU
can and will have its state saved at some time.
Presets have names - factory presets are a list of AUPresetInfo - a
number and a name - and these are set using the PresentPreset call -
where the number (>=0) is used to select which factory preset to set.
A user preset is set with the ClassInfo property - which goes down to
Save/RestoreState calls in AUBase. The name of the user preset is an
entry in the ClassInfo dictionary.
In both of these cases, AFTER a factory or user preset is set, the
PresentPreset property is expected to reflect the name of the preset
that was set. So, in AUBase's RestoreState code there is logic to
release the name of the preset and set the new one. In AUBase's code
to Set the factory preset with the PresetPreset property, there is
code to release the name of the preset and set the new one.
Ok - so that's the background, so should make this easier to
understand what is going on.
I'd also add that Marc's suggestion of calling AUBase's
implementation is a great way to just avoid having to deal with this
yourself, but we've said that a number of times, and people just
ignore us anyway...
So am I right in assuming that the AU validation tool sets the
preset-name without notifiying the plugin, calls SaveState, changes
the name again, calls RestoreState and then checks if the name was
preserved?
nope - you are wrong. It is explicitly set in the RestoreState call
from the value of the <name> field in the dictionary. Have a look
through AUBase::RestoreState and you will see this in action
If that is indeed the case, I can use aformentioned code to prevent
it, but why is the plugin NOT informed about the name change? To me
that seems like doing something behind my back and then complaining
that I didn't know. That's just stupid. Every other change
(samplerate, number of buffers etc.) I get notifications about, but
not about the preset-name? What else should I poll instead of
relying on the notification system?
All of this is wrong. see above.
Marc, I know that this will proberbly upset you and that you will
also proberbly never answer to my posts again, but this is actually
the first time I find one of your posts not patronizing and
arrogant. Like AU and it's inner working are common knowledge every
six year old should know by heart, when in reality *very* good
programmers have REAL difficulties understanding basic concepts of
it. How can it be that several good developers release several good
products, all working fine, doing high-level stuff, but then can't
get the most basic AU stuff to work? There simply are no good
documentation and examples available. SinSynth is a good first
step, but far from being useable as a skeletton for real projects.
To much stuff missing. Some of the AU stuff is simply non-obvious
and some stuff is not even proberbly defined, yet.
In this case I'd really have to say you are dead wrong. All of these
points you are making are being made essentially because you do not
understand what is going on with the implementation. I could say that
if you'd followed Marc's suggestion to look (and even use) the
implementation provided for you in AUBase, you could have debugged
this yourself, but that would probably be bad form on my behalf.
Oh, and I'm the first to admit that we (Apple) could do a better job
with documentation.
So, here's how it works. If you don't understand something, ask a
question. If you don't understand the answer, ask for clarification.
Its not helpful to flame people who are trying to help, in fact its
downright rude. Many people, (Apple engineers, experienced long-time
CA developers like Marc) spend alot of time on this list to help out
people because they understand that this isn't a perfect world, and
that it is better to fix problems than complain about them.
Bill
A good example are the questions Dave from Muon just posted. I also
would like to know how to tell the host about different output
configurations, and no, I don't want what YOU think is best for the
rest of the world, I would like a solution to MY problem.
My AU can also use a stereo channel or four stereo pairs as
outputs. How should I specify my supported configurations? I don't
want two stereo outs or three, I want either ONE or FOUR. How does
the plugin learn about which configuration was chosen by the host?
How can I tell the host which configations are available?
Regards,
Mike
Am 10.10.2005 um 17:18 schrieb Marc Poirier:
On Oct 10, 2005, at 10:43 AM, Michael Kleps wrote:
The very first thing I do is call the default implementation
(AUBase::RestoreState and AUBase::SaveState). BTW, none of these
methods (Restore or SaveState) are even called by the AU
Validation tool...
The ClassInfo property is Set and Get by auval on my AUs, so
there's a sign that something's going wrong in your case. Could
it be some virtual method error (getting the function prototype
wrong in some respect so that you're hiding the parent version)?
Or perhaps you are doing something wrong in the way that you are
monitoring whether this happens or not?
Marc, I am afraid that you are more guessing then knowing, but
your quick reaction and your right use of the terminology gives
most developer here the impression that your answers are right
and that looking into this isn't necessary.
???
If neither property is set/get, no savestate/restorestate is
called, how can the AU Validation tool possibly check for any
changed names?
But that is not true. What makes you think that is true?
I don't have ANY au_presets...
So the code you just posted basicly get the current preset
(although I have none?), and then sets the "name" of in my State
dictionary to the name of the preset that shouldn't exist in the
first place?
Note that the PresentPreset/CurrentPreset property is not strictly
about factory presets. It stores the name of whatever the current
AU settings state is, whether that be a user setting applied via
the ClassInfo property, or a factory preset. So yes, the property
applies to yours and every AU, regardless of whether the AU
provides factory presets. See:
/Developer/Examples/CoreAudio/Documentation/AudioUnits/Topics/
au_properties.html#AudioUnitPresetsandPersistence
/Developer/Examples/CoreAudio/Documentation/AudioUnits/Topics/
au_properties.html#kAudioUnitProperty_CurrentPreset
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
--
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
________________________________________________________________________
__
_______________________________________________
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