Forums > Dev

Problem with Tim's Xcode example

January 16, 2006 | 6:42 pm


January 16, 2006 | 11:53 pm

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

> This is Max/MSP 4.5.6, Xcode 2.2.

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

– N.

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


January 17, 2006 | 12:15 am

On around Jan 16, 2006, at 19:42, Nick Rothwell said something like:
> I’ve been following Tim’s Xcode example at
>
> http://www.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.

– Peter

>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html



jln
January 20, 2006 | 12:52 am

hi,

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… :(

Did someone else succed?


January 23, 2006 | 6:06 am

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

Damon


January 24, 2006 | 3:26 am

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

Thanks for any advice,

-Jesse

.


January 24, 2006 | 12:01 pm

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


January 24, 2006 | 1:36 pm

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.

– P.

>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


January 26, 2006 | 3:33 pm

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.
Thanks!
-Tim


January 27, 2006 | 2:37 am

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"

Thanks,
Damon


January 27, 2006 | 4:47 am

Yes, that is correct.

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


January 27, 2006 | 7:18 am

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

Thanks for your help,
Damon


January 27, 2006 | 4:58 pm

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.

best,
Tim


January 30, 2006 | 2:03 am

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

Damon


February 2, 2006 | 1:28 pm

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


February 6, 2006 | 8:46 am

Thanks, but that didn’t work either. I guess my computer’s just broke.

Damon

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


February 24, 2006 | 6:18 pm

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

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?

thanks,
Mark


February 27, 2006 | 2:52 pm

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

|K<
kent [at] clelland.de


February 27, 2006 | 3:26 pm

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)

best,
r.


February 27, 2006 | 6:17 pm

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


February 27, 2006 | 6:26 pm

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

Good luck,
Peter

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 27, 2006 | 7:06 pm

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


March 1, 2006 | 3:08 pm

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

"return type of ‘main’ is not ‘int’"

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.


Viewing 23 posts - 1 through 23 (of 23 total)