On around Jan 16, 2006, at 19:42, Nick Rothwell said something like:
> I've been following Tim's Xcode example at
> and I get an external .mxo built OK, but when I try to instantiate it
> I get
I had difficulties at first, too. I got my .mxo, but I couldn't get Max
to recognize it: it was in the search path, even had a unique name. I
even tried double-clicking from the desktop to install it. No go.
Then I used File->Install... and all of a sudden Max was happy to
instantiate the object.
The funny thing was, thereafter Max was able to find the object without
add'l coaxing on my part.
On around Jan 24, 2006, at 23:00, loic kessous said something like:
> just an idea.....I didn't have time to try right now but it's maybe
> related to the use of gcc 4.0 , I don't know how now but maybe
> compiling with gcc 3.0 could work.....
Interesting point. My trial was with Jaguar XCode (1.5 or whatever). As
I said, the external worked but only after using File->Install from
inside Max (only had to do this one time, after that I could restart
Max and everything was happy).
I expect Tim may be with the other Cyclers at NAMM, in which case he
may not be able to respond until post-Anaheim. Just guessing.
Sometimes (and sometimes without apparent reason) it is helpful to tell Xcode to do a "Clean" first before you build - especially if you are playing with settings. So that would be the first thing I would try. It is becoming a matter of habit for me to do that now...
When you try to build, Xcode should also produce both a list of errors and warnings, as well as a build log. If you are able to post those, I can take a look at them to see if I spot anything. In this case, it might also be helpful to have you Zip up your Xcode project and send it.
If you would like to see some example Xcode projects, the externals in the Jamoma package have been updated to use Xcode 2.2. To get the projects, go to the terminal and type this:
cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/jamoma co -P Jamoma
The projects are in the Jamoma/library/externals folder. They include plain Max objects, MSP objects, and even a UI external. Some of the projects (the audio objects) have an external dependency on TTBlue (also available from SourceForge) but the rest should compile okay *if you change the prefix header settings in the target*. Why Xcode doesn't seem to save this, I am not sure. If should be that the Prefix Header is set to "../jmod.prefix.pch".
Needless to say, I think there are still a few wrinkles in Xcode - or at least in my understanding of it.
> Sometimes (and sometimes without apparent reason) it is helpful to
> tell Xcode to do a "Clean" first before you build - especially if
> you are playing with settings. So that would be the first thing I
> would try. It is becoming a matter of habit for me to do that now...
Tried it. No luck.
> When you try to build, Xcode should also produce both a list of
> errors and warnings, as well as a build log. If you are able to
> post those, I can take a look at them to see if I spot anything.
> In this case, it might also be helpful to have you Zip up your
> Xcode project and send it.
Here are the warnings I get:
drh.round.c:26: warning: return type of 'main' is not 'int'
drh.round.c:27: warning: unused variable 'attrflags'
drh.round.c:29: warning: unused variable 'attr'
I'll send you a zip offlist.
> If you would like to see some example Xcode projects, the externals
> in the Jamoma package have been updated to use Xcode 2.2. To get
> the projects, go to the terminal and type this:
> cvs -z3 -d:pserver:email@example.com:/cvsroot/
> jamoma co -P Jamoma
> The projects are in the Jamoma/library/externals folder. They
> include plain Max objects, MSP objects, and even a UI external.
> Some of the projects (the audio objects) have an external
> dependency on TTBlue (also available from SourceForge) but the rest
> should compile okay *if you change the prefix header settings in
> the target*. Why Xcode doesn't seem to save this, I am not sure.
> If should be that the Prefix Header is set to "../jmod.prefix.pch".
I compiled one of these. It claims to fail, but did in fact produce a
working external. Here's the error for that if you're interested:
jmod.change.cpp:45: warning: unused variable 'attrflags'
jmod.change.cpp:47: warning: unused variable 'attr'
Tool:0: Command /bin/sh failed with exit code 136
Tool:0: failed to resolve one of the sources (-120)
Those warnings are harmless, and the project you sent me compiles fine here. The external works just like it is supposed to on my machine.
The Jamoma object compiled fine for you, but it failed on a custom post-build step where the extern is automatically copied into another folder (which you don't have) - so that's what is happening there.
Thanks, but that didn't work either. I guess my computer's just broke.
Quote: Davis Pyon wrote on Thu, 02 February 2006 08:28
> A while back, I posted a message concerning a problem with MaxMSP Runtime. MaxMSP was able to find my Mach-O external, but Runtime kept reporting "no object found". There was no response.
> After some fiddling around, I decided to change the name of my external, and that solved my problem (though I still don't know why). Maybe that will work for you.
> Double-click on the target to edit it. Change the name of the target (General tab), product name (Build tab), and the executable (Properties tab). I hope this helps.
I'm trying to build an MSP example (lores~) under Xcode 2.2.
Following Tim's example, and adding the MaxAudioAPI framework, I
can compile and link without errors. I'm unclear what the final
product is and where it should be placed. My .mxo is a folder, not a file, and Max won't File->Install it. Nor will it see or install
the lores~ executable, which appears to be of kind "Unix Executable
I must be missing some critical step, but I've double- and triple-checked my compiler/linker options and everything looks groovy.
hi mark. an .mxo file is a mach-o (os X only [ie os X native] )
application bundle (or in this case plug-in bundle). bundles are,
of course nothing but folders which osX in most cases disguises to
not look like folders (but which any user can right-click on and say
"show bundle contents" revealing the 'hidden' structure of the
application bundle). a .mxo object can simply be placed into your
max externals directory and it will be loaded just like all other
externals as long as you are running a later version of max which
supports mach-o externals. (max 4.5 for example) if it doesn't load
then there's something wrong in your code. examine it closely. as
far as I know it is impossible to debug a mach-o external in max (the
carbon to mach shim makes this impossible).
if .mxo bundles are showing up in the finder as folders, make sure
you don't have subethaedit installed. the subethaedit file type
registry includes an entry for .mxo which renders them unusable.
look for a CFBundleDocumentTypes array, which contains 3 dictionaries
one dictionary has a CFBundleTypeName of PlainTextType, and includes
an array of 147 CFBundleTypeExtensions
trim the array as you see fit (i.e. remove .mxo), or delete the whole
reboot (logging out doesn't cut it for some reason)
On around Feb 27, 2006, at 16:26, ritchie said something like:
> if .mxo bundles are showing up in the finder as folders, make sure you
> don't have subethaedit installed.
If it were only that easy.
It is useful to know that SubEthaEdit is an additional source of
entropy in the .mxo equation, but reading this thread in its entirety
(and yes, I do mean going back to January) indicates that there is
other grisgris at play.
On around Feb 24, 2006, at 7:18 PM, Mark Trayle said something like:
>> My .mxo is a folder, not a file, and Max won't File->Install it. Nor
>> will it see or install
>> the lores~ executable, which appears to be of kind "Unix Executable
I assume you realize that a Bundle is nothing more than a folder that
has a bit set in the file system so that the Finder displays it as a
I don't know why XCode is not setting this bit when it builds your
project, but that seems to happen sometimes. Check compiler settings
(sorry, I don't know which one; yes I know there are a lot of them).
It is right and proper (apparently) that inside your .mxo, in
.../Contents/MacOS/, you will find a file with the name of your
external (w/out the .mxo suffix) that appears to be either an untyped
file or a Unix Executable. If you do an ls -l on it in the Terminal I
believe it should turn up permissions 755 (Finder Get Info
unfortuntately doesn't tell you that the execute bits are set). If
you're going to build with XCode, you'll need to get used to using the
Terminal to find out stuff like this. Don't blame me, it wasn't my
Even when XCode properly sets the bundle bit, there appear to be some
configurations under which Max does not recognize your .mxo. Again, do
check the earlier messages.