@rxc, my apologies for the months-long wait in replying. I've always compiled the externals using the Build action in XCode (rather than running Makefile).

I don't know if this might make a difference, but can you try doing that and then loading the external in the debug scheme?

There may be a bit of config to do to make the XCode project build the external correctly. This includes using the correct architecture, and also some options that can be found in the link that I had posted at the very top of this thread:

http://cooperbaker.com/home/code/pd xcode/xcode 3.2.2 pd tutorial/

Also, I am not using XCode 13 (still on 12, really dreading the upgrade, as I know this will break many things on my other projects), but I suspect that the configurations for a dynamic library will be very similar and should therefore work using the same guidelines (this has been my experience when migrating my projects from XCode 9 through 12, and even making the jump from 32- to 64-bit--the build settings are pretty much the same).

Let me know if this helps!

For anyone interested, I was able to figure out how to do it using the original guide for earlier Xcode versions. The mistake I was making was to attach the full package of Pure Data to the debugging scheme as the executable. The correct way of doing it is to link the actual executable file as described below.

In Xcode (this is v 12.3):

1. Create a new debugging scheme
   

2. Edit the new scheme:
   

3. In the Executable drop-down menu, select Other...

4. Find the executable for pd (e.g. /Applications/Pd-0.51-3.app/Contents/Resources/bin/pd)

The settings for the scheme should look like this (notice the setting for Launch - Automatically)

5. Build and run the external. This will start Pd. The actual debugging will begin when you instantiate the external object inside a patch.

In my case, I added a breakpoint inside the bang() method. Upon receiving the bang, the breakpoint is reached:

I'm wondering if anyone knows a way to use Xcode 12 to debug an external with e.g. breakpoints while the external runs in PD?

I've only been able to find guides like the one below, which reference earlier Xcode versions:
http://cooperbaker.com/home/code/pd xcode/xcode 3.2.2 pd tutorial/

My version of Xcode is 12.3. I am using PD Vanilla 0.51.3.

Great to hear, @me-andmymonkey! Make sure to share the externals. Best luck,

afsacp

Hey @me-andmymonkey, I found another option, which should work. Follow these steps (try first with the 32bit, tell me what happens):

1. In Finder, go to Applications folder.
2. Right- or control-click on Pd-extended
3. Click on "show package contents"
4. Navigate to Contents -> Resources -> extra
5. Create a folder with the exact name of the external (impact_modalb~)
6. Put the file impact_modalb~.pd_darwin in that folder.
7. Open Pd (close first if open), then load the same example file you tried earlier.

I did all the above and it worked.

afsacp

@me-andmymonkey, check the folder again. A subfolder now contains the 64bit version. It should be noted that building this version raised a lot of flags regarding data type conversion. I'm frankly a bit fuzzy on this, but the idea is that different data types require different sizes, and the compiler builds it according to that and to the architecture selected, so that an integer in 32bit arch should be 4 bytes, but in 64bit should be 8bytes, and so on. So this could raise issues with precision, rounding off errors, etc. Like I said, fuzzy.

In any case, try to work with the 32bit version first, attempting to find a suitable location for the externals. I'll keep looking through my references.

OK. I'll try rebuilding at 64bit. However... the message you get is typical of Pd not being able to find the object. If the architecture was wrong, like if the external was built for x86-64 instead of the i386 (which is 32bit), Pd would complain:

/Library/Pd/impact_modalb~.pd_darwin: dlopen(/Library/Pd/impact_modalb~.pd_darwin, 10): no suitable image found. Did find:
/Library/Pd/impact_modalb~.pd_darwin: mach-o, but wrong architecture

Perhaps some other members can pitch in with regards to potential location of the externals. The location I suggested has worked for me from first try. Good luck!

@niku & @me-andmymonkey, I can point you to some of the documents to create working dynamic libraries in Xcode for use as externals:

http://puredata.info/docs/developer/PdExternalsInXcode

The link below has become the reference for writing externals in C.

http://pdstatic.iem.at/externals-HOWTO/

The actual compiling is relatively easy if you've done some of it already. But the solution might be relatively simple (I hope!), and it might be that Pd can't see the external yet. Which is why learning the behavior of Pd upon attempting to instantiate the external is so crucial. Let me know!

@me-andmymonkey, it might be helpful to know the following:

1. What OSX version you're using
2. What kind of error message you get when trying to instantiate the external in Pd
3. What version of Pd you are using

Great point, @niku! I use:
OSX 10.8.5
Pd 0.43.4-extended
Xcode 4.6.2
Externals are compiled at 32 bits.

Hi @me-andmymonkey, I was able to compile the object impact_modalb~ using xcode, so it is usable in OSX. I tried using the included impact_modalb_example.pd, and it worked, and it is pretty awesome!

Find the pd_darwin external here:

https://www.dropbox.com/sh/fb2uoqmg5w58rq7/AABrJ7vErKA4ajRVvmdDU8-La?dl=0

If it doesn't exist yet (in my case, it didn't), you must create a folder called Pd under the Library folder, which is itself on the root directory, so that you have the following path:

/Library/Pd/impact_modalb~.pd_darwin

Open impact_modalb_example.pd, which is part of the zip file you must have downloaded. Let me know if it doesn't work...if it does, I could try to compile some of the others.

afsacp

Thanks all for the great answers. @EEight, I downloaded MIDI Monitor, and used it both with the patch and without it (but with Pd open). In both cases it reported messages from controllers that were not being touched. It seems the issue is, as @NoDSP suggested, the quality of the device. I have another controller, a Samson Graphite M32, hooked up, and it doesn't seem to send any undesired messages, so that would confirm it. I do remember the AKAI being on sale at Guitar Center when I bought it... I'll try with the mapping abstractions suggested by @EEight. In any case, this was tremendously helpful.

I've been using an AKAI APC mini for about 6 months now to control various parameters. I have way more parameters to control than faders that the APC mini has (only nine), so I built a small external to switch between "scenes" of the faders, so I could control as many as I need.

I find that occasionally the controller will update the value of its faders without actually touching it. This wouldn't be a problem if the faders were permanently assigned to one and only one parameter, but since the assignment is constantly changing, the updated value potentially messes up an entire scene, especially since I'm not even touching it.

Has anyone experienced a similar issue? Is it something to do with midi controllers in general? Or with the way Pd interacts with the controller?

Obliged.