NDI support?

[newmediarecordings]

I have tried this on my m1 and intel macs, both same issue, and have also tried to update ndi, still an issue. I have tried to put the exact file in the Gem folder, still same. Can anyone help?

Here is the prompt I'm given:

[GEM:recordNDI] Please (re)install the NewTek NDI Runtimes to use this plugin. need to find the library 'libndi.4.dylib' get it from http://new.tk/NDIRedistV4Apple GEM: video record plugins: PNM [GEM:videoNDI] Please (re)install the NewTek NDI Runtimes to use this plugin. need to find the library 'libndi.4.dylib' get it from http://new.tk/NDIRedistV4Apple GEM: video capture plugins: AVF NDI decklink

[giulianobici]

Hi @newmediarecordings I have the same issue on macbook Ventura 2,3 GHz Dual-Core Intel Core i5 Intel Iris Plus Graphics 640 1536 MB Macos Ventura 13.2.1 (22D68)

[umlaeute]

i don't think (I've never tested this on anything but Linux) the libndi.4.dylib should be in the Gem folder, but instead in some system--wide folder, most likely in /usr/local/lib/.

alternatively set the NDILIB_REDIST_FOLDER envvar to the place where the libndi.4.dylib file is located and restart Gem (no, I have no clue how to set envvars on macOS so they have an effect for applications started from the desktop).

it would probably be good to automatically set the NDI_RUNTIME_DIR_V4 (if it is not set explicitly by the user) to point to the Gem installation path...

[umlaeute]

sidenote: I also noticed that NDI has obviously bumped the soname version to 5, which probably indicates that the there's some API incompatibility...

[umlaeute]

i just noticed, that (at least on Linux), it's indeed enough to copy the libndi.so* files besides the gem_videoNDI.so (or simply: the Gem-binary, which lives in the same path).

So the issue is most likely simply that the soname bump is responsible for not being able to use the NDI dylibs.

i'll push an update to the NDI SDK v5.

[umlaeute]

some more update: it seems that on macOS, the libndi.dylib gets installed into /usr/local/lib/, which - for whatever reasons - is not searched for by dlopen() (which is used to open the dylib file).

so far the only way to make it work (afaict) is to explicitely set the NDI_RUNTIME_DIR_V5 (or NDI_RUNTIME_DIR_V4) env-var to /usr/local/lib before starting Gem.

EDIT this can be done with running the following in a terminal:

launchctl setenv NDI_RUNTIME_DIR_V5 /usr/local/lib

After than, newly started Applications should see the envvar and be able to properly load NDI (if you start Pd from the terminal, you probably have to restart the Terminal.app)

[umlaeute]

Fixed with f17c966077b26020a1f27376b5eb25e057c67da7