OSC module won't add anything to Napkin


I am trying to use OSC communication in my application. I am running Mac OS. I have already done the following:

  1. Added mod_naposc into my project.json dependencies
  2. Run ./regenerate from the project folder
  3. Opened the Xcode project and run Build

I see no errors in any of the above steps.

But when I run Napkin, I get an error about OSC library (and no OSC resources/components are available in Napkin):

[warn] Failed to load module /Users/stephen/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib: dlopen(/Users/stephen/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib, 1): Library not loaded: @rpath/liboscpack.1.1.0.dylib
      Referenced from: /Users/stephen/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib
      Reason: image not found

Curiously, running otool -L napkin produces no mention of OSC at all:

	@rpath/libmod_nappython.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmod_napvideo.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmod_napaudio.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/../../../../thirdparty/Qt/lib//QtOpenGL (compatibility version 5.11.0, current version 5.11.2)
	@executable_path/../../../../thirdparty/Qt/lib//QtWidgets (compatibility version 5.11.0, current version 5.11.2)
	@executable_path/../../../../thirdparty/Qt/lib//QtGui (compatibility version 5.11.0, current version 5.11.2)
	@executable_path/../../../../thirdparty/Qt/lib//QtCore (compatibility version 5.11.0, current version 5.11.2)
	@rpath/libmod_naprender.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libSDL2-2.0.0.dylib (compatibility version 1.0.0, current version 10.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libGLEW.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libfreeimage-3.17.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libassimp.3.dylib (compatibility version 3.0.0, current version 3.3.1)
	@rpath/libmod_napfont.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libfreetype.6.dylib (compatibility version 6.0.0, current version 6.16.0)
	@rpath/libmod_napscene.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmod_napmath.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libnapcore.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libnaprtti.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libpython3.6m.dylib (compatibility version 3.6.0, current version 3.6.0)
	@rpath/librttr_core_d.0.9.6.dylib (compatibility version 0.9.6, current version 0.9.6)
	@rpath/libportaudio.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	@rpath/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.28.0)
	@rpath/libmpg123.dylib (compatibility version 45.0.0, current version 45.5.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 934.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
	@rpath/libavcodec.57.107.100.dylib (compatibility version 57.0.0, current version 57.107.100)
	@rpath/libavformat.57.83.100.dylib (compatibility version 57.0.0, current version 57.83.100)
	@rpath/libavutil.55.78.100.dylib (compatibility version 55.0.0, current version 55.78.100)
	@rpath/libswresample.2.9.100.dylib (compatibility version 2.0.0, current version 2.9.100)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)


Relevant detail: the exact same setup runs just fine on Ubuntu. So either this is Mac-specific or something machine-specific (conflicting packages?).


Can you run the midi / OSC demo on your mac? If so, that would imply a problem with the current setup.

Alternatively, looking at the osc demo, the osc module is not linked into the project.json directly but into the module that is created for the demo. Can you try linking in osc into your project module?


Yes, I can run the MIDI OSC demo just fine, so I’m sure there is a problem with my own setup, but I just cannot see where.

I can’t link OSC into my project module, because I don’t have a project module. (This is not currently supported, apparently.) So for now, we have mashed everything together into a single user module which is effectively the project module.

So I have tried the experiment anyway (i.e. adding mod_naposc into the module dependencies rather than the project itself) and this “solves” the problem (although the same error message appears when launching Napkin)… So… OK.

Why would a module’s resources/components be usable via Napkin when included as part of another module, but not in the project itself? And, moreover, why would this work on one machine just fine (the Ubuntu PC, in my case) but not on the Mac?

Still not really sure what is causing the problem.



If the demo runs fine it means the OSC library is functioning correctly. Can you also open the oscmidi.json file in napkin? If that is the case napkin correctly loads the osc midi library.

What i’m after is to see if the app that reads your .json file on init() can also be read by json. It could be worth adding this:

        "Type": "nap::OSCReceiver",
        "mID": "OSCReceiver",
        "Port": 7000,
        "EnableDebugOutput": false
        "Type": "nap::OSCSender",
        "mID": "OSCSender",
        "IpAddress": "localhost",
        "Port": 7000

to your .json file and start the application. If the app doesn’t fail to initialize it means osc is available for your app. Next step is to check if napkin can load that file as well. It could be useful to change a line of code and recompile your project. On windows, all the dll’s (dylibs) are copied into the resulting bin directory after compilation:

Regarding your previous comment of running o-tool: this applies to the libraries linked to from napkin directly, ie: what napkin uses internally. It makes sense that mod_naposc is not visible because napkin scans the directory it sits in to locate possible dll’s it can open and inspect. Napkin doesn’t rely on mod_naposc to run, it only knows it can create resources / components etc. that are exposed inside the mod_naposc library through RTTI. When napkin finds a library (say mod_naprender or mod_naposc) and manages to open it, napkin will extract all the components and resources and adds them to a list of valid objects to create.

Now, if napkin fails to open your json that you just modified(added the receiver / sender to) it means something is wrong with napkin, ie: the app can’t open the dll for inspection. If that is the case an error message appears in the logger of napkin when the json is loaded:

[debug] Looking for 'C:/naivi/nap/NAP-0.2.3-Win64/demos/oscmidi/bin/MSVC-x86_64-Debug/config.json'...
[error] Unknown object type nap::MidiHandlerComponent encountered.

This implies that an object that is encountered in the .json file is not part of any module loaded by napkin, ie: in this case I removed mod_naposc from the bin directory.

Is mod_naposc present in your output directory after compilation of your project? If so, and napkin doesn’t find it it means something is probably wrong with the path napkin uses to find and load the dll. In that case we have something more accurate to debug.

Hopefully this explains a bit more and helps you locate your problem.

Cheers Coen


This ties into my previous comment, Napkin does not inspect the project.json file or any configuration file. It simply loads all the libraries available to it that sit in the same directory on startup and extracts all the exposed resources and components. @stijnvanbeek uses osc regularly on OSX and can help your if you keep running into this problem.


After thinking about this some more I think the RPATH reference to liboscpack.1.1.0.dylib is incorrect. What I find odd is that other OSX users are working with OSC and didn’t encounter this issue.

It does seem to pick up the mod_naposc library but that library needs liboscpack to function correctly but can’t find it though its RPATH reference. Can you figure out if the path mod_naposc uses to points to liboscpack.1.1.0.dylib is correct. A quick fix would be to change the path and see if it picks it up.

@chris might have some other suggestions, as this seems to be related to packaging.


Adding the OSCReceiver/OSCSender objects directly to the JSON causes errors when launching Napkin:

[error] Unknown object type nap::OSCReceiver encountered.

So, as you say, this suggests that Napkin is unable to load the module.

But then you ask:

Is mod_naposc present in your output directory after compilation of your project?

Where is the “output directory” of my project? There is an xcode folder and a bin folder, but none of these seem to contain anything that looks like nap modules?


This seems correct based on the error message you mentioned earlier, mod_naposc can’t be loaded because mod_naposc.dylib depends on liboscpack.1.1.0.dylib. So Napkin does successfully locate the .dylib and tries to load it but fails because the RPATH to liboscpack.1.1.0.dylib is incorrect from the location that is used to probably start napkin.

But you can run the app with the sender and receiver present in your .json file? In that case the RPATH is incorrect when napkin tries to load mod_naposc, which relies on a third party library.

Try inspecting the RPATH and see if the path is correct. @chris, any ideas?


The executable is compiled to your bin folder, but my previous statement is incorrect for OSX users, so you can neglect that one. I think the problem is now clear, as mentioned above.


I would need to investigate it.

One thing that comes to mind is whether you’re able to use work on the oscmidi demo project structure using Napkin? (using Napkin launched from oscmidi/bin//). @steveb?

Differences in RPATH management across platforms could be one cause of things not playing smoothly across platforms.


Yes, as I said, that works just fine.


OK thanks. I wasn’t sure as I thought you’d only referred to being able to run the demo, not necessarily using Napkin.


So, just to confirm…

What works for me:

  1. OSCMidi demo application
  2. OSCMidi demo Napkin
  3. Adding mod_naposc to my project dependencies on Mac: application works, Napkin doesn’t (won’t load OSC resources/components)
  4. Adding mod_naposc to my module dependencies on Mac: application works, Napkin works too
  5. All of the above works on Linux PC


Thanks Steve that’s great info, I’ll have a look at this on or before Monday


@steveb This build fixes this issue. Let me know if you have any trouble with it.

@stijnvanbeek Please use this build on Monday :slightly_smiling_face:

Napkin fails to launch, incorrect checksum, abort trap 6

Thanks @chris and @stijnvanbeek but since there seem to be issues with this new build (see Napkin fails to launch, incorrect checksum, abort trap 6) I might just wait until these are resolved first.


As mentioned over there, it’s possible to provide you a build ASAP without the render target changes if that resolves all issues for today. It would be great to be able to verify that all of your Napkin loading issues are gone.


That sounds all right… Can we name these “releases” more carefully so that we are clear on the differences? Already we are dealing with 3 different versions of 0.2.3…


Done, here :slight_smile: