nick rothwell | project cassiel

problem-with-tims-xcode-example

On 16 Jan 2006, at 18:42, Nick Rothwell wrote:

Oh, I should add that it's also the 4.5.5 SDK, downloaded yesterday 

nick rothwell -- composition, systems, performance -- 

Oh, I should add that it's also the 4.5.5 SDK, downloaded yesterday  
or thereabouts.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


On around Jan 16, 2006, at 19:42, Nick Rothwell said something like:

> I've been following Tim's Xcode example at

https://cycling74.com/story/2005/10/5/82341/3928

> and I get an external .mxo built OK, but when I try to instantiate it 

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 

The funny thing was, thereafter Max was able to find the object without 

| Litter Power & Litter Bundle for Jitter

pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building

http://www.dspaudio.com/software/software.html

On around Jan 16, 2006, at 19:42, Nick Rothwell said something like:
> I've been following Tim's Xcode example at
>
> 	https://cycling74.com/story/2005/10/5/82341/3928
>
> 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.

I tried to install it via the file menu, but it doesn't work any better. I still get the error message mentioned above.

Now, I must admit it's not really a problem since I'm far from developing my own externals, but I was really curious to try this tutorial... :(

I tried to install it via the file menu, but it doesn't work any better. I still get the error message mentioned above. 

I get the same problem described. Trying install didn't help. Anyone figure out how to get it to work?

I've run into the same issue and have had no luck fixing it. I'm using XCode 2.2, MaxSDK 4.5.5, Max 4.6, OS10.4.3

I've run into the same issue and have had no luck fixing it.  I'm using XCode 2.2, MaxSDK 4.5.5, Max 4.6, OS10.4.3

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 

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

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 

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 

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.

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.

Hi - yes I was at the NAMM show and not able to keep up while out of town - sorry for the delay.

I think the problem can be fixed by adding the -lmx option to the "Other Linker Flags" in the target settings.

Let me know if that doesn't solve the problem.

Let me know if that doesn't solve the problem.
Thanks!
  -Tim


I tried that and it didn't work for me. Just to make sure I did the right thing:

Project > Edit Active Target > Build Tab > Other Linker Flags > add value "-lmx"

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:anonymous@cvs.sourceforge.net:/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...

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:anonymous@cvs.sourceforge.net:/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.
   -Tim


> 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 

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'

> 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:anonymous@cvs.sourceforge.net:/cvsroot/ 

> 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)

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

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'

> 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:anonymous@cvs.sourceforge.net:/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.

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.

Has anyone else experenced (and then hopefully solved) this problem?

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.

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.

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.

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.
>
> Davis
>
----------------------------------------------------


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.

Anyone have an idea where I might be going wrong?

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
File".

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).

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 

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)

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.  
alternately:

open SubEthaEdit.app/Contents/Info.plist
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  
dictionary
reboot (logging out doesn't cut it for some reason)

Thanks jitter, now that I've removed SubEthaEdit

I'm seeing the .mxo as a Max object. (Boy, that's an

I still get the "missing arguments" problem, and File->Install

Thanks jitter, now that I've removed SubEthaEdit
I'm seeing the .mxo as a Max object. (Boy, that's an
odd one).

I still get the "missing arguments" problem, and File->Install
doesn't solve that one. Hmmm....


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 

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 

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 

>> 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 

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.

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
>> File".

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 
single item.

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 
idea.

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.

Okay, I've got Ichiro Fujinaga's thru~ example built and running

so I have a known working xcode project. Tim's round project

still doesn't work, but at least I'm on the right track. Thanks

Okay, I've got Ichiro Fujinaga's thru~ example built and running
so I have a known working xcode project. Tim's round project
still doesn't work, but at least I'm on the right track. Thanks
K


Interesting. I've also got the thru~ example working, but with a warning:

The object itself works fine, however (Max/MSP4.5.5).

I am having similar problems to the above with Tim's examples, but many of the Fujinaga ones are good.

Interesting.  I've also got the thru~ example working, but with a warning:

I am having similar problems to the above with Tim's examples, but many of the Fujinaga ones are good.


Problem with Tim's Xcode example