• 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: AU - avoiding crash when unregistering control class
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU - avoiding crash when unregistering control class


  • Subject: Re: AU - avoiding crash when unregistering control class
  • From: Howard Moon <email@hidden>
  • Date: Thu, 9 Jan 2003 12:24:17 -0800

Airy,

the reason I would have several instances is because I have several custom controls on my form. Each of my rotary knobs is a custom control that overlays our bitmapped background image. I had thought I could register the toolbox class once, keep the same handle for all my knobs, and use the data passed to the callback to identify the specific knob being accessed. However, since there is no call to see if the class is already registered (and get its handle), and since unregistering does not work, I need to register each control knob with a different name so that it gets a unique handle. To do that, I loop, generating a new name, until the call to register the toolbox class no longer gets the "already registered" error.

Also, the user is certainly allowed to remove the plug-in when running under Logic Audio, and (as you point out) if they then instantiate it again, there are no longer any valid handles for my controls.

So...for now I will just keep generating unique names in order to generate unique (and valid) handles for each control. What I would really like is to have a reference-counted mechanism for toolbox object classes so that when the last control using the handle is destroyed, the toolbox class object is unregistered.

Howard


On Thursday, January 9, 2003, at 12:00 PM, Airy Andri wrote:

Unless there is something wrong with the plugin loading part, there should
be only one instance of the code, even if you have several instances of the
plugin. So you should have no need to register your control with a different
ID for every instance you load.
Then, since I think the GUI code is loaded at the same time as the DSP part, as long
as you do not remove all of the instances of your plugin from the host, I see
no reason why the address of your code would change. So, there should be
no risk of crash when your open the GUI window.

The only case I see where you could have a crash is if you load you plugin,
remove it, then reload it again. Then it could be load at a different address.

But I did not look in details to the plugin loading mechanism so I could be
completely wrong...

Airy

Le jeudi, 9 jan 2003, ` 02:06 Europe/Paris, Marc Poirier a icrit :

Ack! Then what the heck good is it??? I'll still have to generate a
new name for the class every time in instantiate it in order to
register the control class then, right? What a bummer!

I guess that we need to no matter what because, with plugins, we could
have multiple instances running side by side. But I think that
unregistering the class, when possible, avoids some memory leakage at
least...

Marc
_______________________________________________
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.
_______________________________________________
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.

References: 
 >Re: AU - avoiding crash when unregistering control class (From: Airy André <email@hidden>)

  • Prev by Date: Re: AU Components on the fly
  • Next by Date: Some CoreAudio properties not accessible via Java API?
  • Previous by thread: Re: AU - avoiding crash when unregistering control class
  • Next by thread: What happened to factory presets?
  • Index(es):
    • Date
    • Thread