How do you host the PitchShift Audio Unit plugin correctly in its own window?
I am developing a Mac app that hosts Apple’s system supplied Audio Unit plugins. With the new OSX 10.7 Lion, some of the plugins have updated views. PitchShift is one of these.
PitchShift and a few others have new knobs to change there parameters. When a knob is being turned with the mouse, a horizontal bar showing the knob’s parameter value is displayed below the knob.
This bar stays on screen after the knob is released and even after the window is closed. If I click one of the knobs, thus creating a rogue value bar, and move the window the PitchShift view is in, the bar stays where the window used to be. And if I click the knob again at this point, a new bar appears, but both bars are actively updated with the changing knob parameter value information. This happens every time I repeat this process with more bars staying on screen.
After a few times with this happening, my app exits with bad access at NSApplicaionMain() call in the main.m file.
I checked in Logic 9, and this does not happen there. The bar seems to be tied directly to the knob, and thus disappears immediately after you let the knob go with the mouse.
I set the PitchSHift view to be the contentView of a dedicated NSWindow.
How is Logic keeping this from happening, or just how can I?
I’ve tried seeing if the parameter value bars where subviews of the PitchShift view, but they don’t seem to be.
Any help would be greatly appreciated.
EDIT: When the a value bar first appears, I get the following output in the console from my program: Circle and line do not intersect
So I’ve found that it is using core-animations CALayers. The problem now is that the value bar layers aren’t a part of the PitchShiftView’s layer hierarchy. In other words, I can find all the other layers that build up the pitchShiftView, but not the layers for the value bars. Which seems like it might be the whole problem to begin with.
I finally figured it out. The parameter value bars are child windows of the window that owns the audio unit view.
To solve the problem, I catch the mouse up events for the window in my subclass of NSApplication, and I then close the child window (aka the value bar) so that they don’t stay on screen.
This did not stop the exit bad access. I now think that is a separate issue that only appeared to be related to these lingering child windows.