• 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: ClassInfo & PresentPreset confusion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ClassInfo & PresentPreset confusion


  • Subject: Re: ClassInfo & PresentPreset confusion
  • From: Michael Kleps <email@hidden>
  • Date: Mon, 10 Oct 2005 18:57:14 +0200

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.

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?

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?

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.

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
  • Follow-Ups:
    • Re: ClassInfo & PresentPreset confusion
      • From: Pavol Markovic <email@hidden>
    • Re: ClassInfo & PresentPreset confusion
      • From: William Stewart <email@hidden>
References: 
 >ClassInfo & PresentPreset confusion (From: Michael Kleps <email@hidden>)
 >Re: ClassInfo & PresentPreset confusion (From: Marc Poirier <email@hidden>)
 >Re: ClassInfo & PresentPreset confusion (From: Michael Kleps <email@hidden>)
 >Re: ClassInfo & PresentPreset confusion (From: Marc Poirier <email@hidden>)

  • Prev by Date: Audio Units - newbie questions
  • Next by Date: Re: Audio Midi Setup App
  • Previous by thread: Re: ClassInfo & PresentPreset confusion
  • Next by thread: Re: ClassInfo & PresentPreset confusion
  • Index(es):
    • Date
    • Thread