PDA

View Full Version : Problems with a patched /modified IPlug on OSX


Soundbytes
03-20-2010, 03:41 PM
I just found that the auval tool puts out a lengthy list of warnings whenever two or more IPlug based Audio Units are present in the system.
(If you have more than one IPlug based AU installed open terminal and
run auval -a)
Is this a common problem or could it be it caused by the way I included the swell source within my project?

olilarkin
03-21-2010, 07:24 AM
i have noticed this too. is it like this?

aumf IplM oliL - OliLarkin: Looper
objc[591]: Class IGraphicsCocoa_v1002 is implemented in both /Library/Audio/Plug-Ins/Components/IPlugEffect.component/Contents/MacOS/IPlugEffect and /Library/Audio/Plug-Ins/Components/Looper.component/Contents/MacOS/Looper. One of the two will be used. Which one is undefined.
objc[591]: Class SWELL_APP_PREFIX_sdh is implemented in both /Library/Audio/Plug-Ins/Components/IPlugEffect.component/Contents/MacOS/IPlugEffect and /Library/Audio/Plug-Ins/Components/Looper.component/Contents/MacOS/Looper. One of the two will be used. Which one is undefined.

Soundbytes
03-21-2010, 08:17 AM
I suspect this could quickly become a problem if one is using a modified version of the IPlug framework (that is what I intended to do) or if a modified version of The framework is used by another plugin that is installed in the system.

I think the only clean solution to avoid any conflicts would be not to use the precompiled IPlug library. Instead one would have to
- add the entire IPlug/Lice/Swell code to the project
- then one could add a custom prefix to all objective C classes as well as to all obj-C functions (not required for member functions)

Recompile time could still be kept short by including all IPlug headers within the precompiled header file.

Any other/better Ideas how to solve this? (or is that a problem at all?)

Andreas

stahlwerk
03-21-2010, 02:41 PM
Yes, this could really be a problem, I guess including all the source code is the only sensible setup. I looked around a bit, and saw that Juice uses this method, and uses a #define, JUCE_ObjCExtraSuffix, to make internal ObjC names unique to each plugin. Something like that would work without being to cumbersome.

cc_
03-22-2010, 12:30 AM
schwa already dealt with this. If you look in IGraphicsCocoa.h there's this line:


#define IGRAPHICS_COCOA IGraphicsCocoa_v1002


Just bump the version if you make any changes - in my modified IPlug I changed it to 1003.

cc_
03-22-2010, 02:27 AM
I just remembered there's another source of confusion not related to ObjC. By default all the IPlug symbols are set to visible in the xcode project because the OSX VST entry point is not declared properly, see here:

http://forum.cockos.com/showthread.php?t=37082

This is one of the changes in my IPlug version, but you'll have to change the XCode project yourself.

Soundbytes
03-23-2010, 12:50 AM
I believe you need a unique prefix to effectively deal with the problem.
What if another person had the same Idea and labeled their modified IPlug versions 1002, 1003 ...?


schwa already dealt with this. If you look in IGraphicsCocoa.h there's this line:


#define IGRAPHICS_COCOA IGraphicsCocoa_v1002


Just bump the version if you make any changes - in my modified IPlug I changed it to 1003.

cc_
03-23-2010, 01:03 AM
Sure, if you change the IGraphicsCocoa code you can change that define to anything you like to be certain only your code is used.

Or are you saying something else is needed besides that define?

Soundbytes
03-23-2010, 06:31 AM
Or are you saying something else is needed besides that define?

No. I just prefer to be on the safe side with these things. :-)
BTW: thanks for the hint regarding the symbol visibility!

olilarkin
10-15-2010, 01:11 AM
aumf IplM oliL - OliLarkin: Looper
objc[591]: Class IGraphicsCocoa_v1002 is implemented in both /Library/Audio/Plug-Ins/Components/IPlugEffect.component/Contents/MacOS/IPlugEffect and /Library/Audio/Plug-Ins/Components/Looper.component/Contents/MacOS/Looper. One of the two will be used. Which one is undefined.
objc[591]: Class SWELL_APP_PREFIX_sdh is implemented in both /Library/Audio/Plug-Ins/Components/IPlugEffect.component/Contents/MacOS/IPlugEffect and /Library/Audio/Plug-Ins/Components/Looper.component/Contents/MacOS/Looper. One of the two will be used. Which one is undefined.

anyone know how to get rid of these errors and still statically link libiplug.a?

cerberus
10-15-2010, 06:34 AM
i don't know if i can reproduce this problem or not... so far i haven't noticed the reported conflict. #define IGRAPHICS_COCOA IGraphicsCocoa_ is not present in my IGraphicsCocoa. http://gyazo.com/d223edd34d1660910ed8aa91ee923945.png

Tale
10-27-2010, 08:34 AM
You will find the #define IGRAPHICS_COCOA IGraphicsCocoa_v1002 line in IGraphicsCocoa.h.

I have added a (hopefully) unique ID to this define in my IPlug edition. However, if someone would download my repository, and then make some changes but leave IGRAPHICS_COCOA unchanged, could this result in conflicts with that person's and my own plug-ins?

cc_
10-28-2010, 05:13 AM
You will find the #define IGRAPHICS_COCOA IGraphicsCocoa_v1002 line in IGraphicsCocoa.h.

I have added a (hopefully) unique ID to this define in my IPlug edition. However, if someone would download my repository, and then make some changes but leave IGRAPHICS_COCOA unchanged, could this result in conflicts with that person's and my own plug-ins?

Yes, I worried about that too. I have mine set differently in the code I use than the source I release.

Tale
11-06-2010, 02:58 AM
I am thinking of doing a 32-bit OS X 10.0.4 build, and a 32/64-bit OS X 10.0.5 build alongside it. I guess I will have to assign these two builds different class names, right?

EDIT: To fix this I have now added a shell script to the Xcode project that updates IGraphicsCocoa.h with a random suffix for the IGRAPHICS_COCOA #define. This script will run automatically each time IPlug is (re)built.