I recently heard about the Zig programming language and wanted to see if I could make Pd externals with it, so I put together a "hello world" external, which showcases things like printing to console, working with symbols, and sending floats through an outlet.

Getting it to work required using a local copy of m_pd.h and making a small change to the t_text struct, since Zig's C-translator apparently doesn't like bit fields.:

-    unsigned int te_type:2;     /* from defs below */
+    unsigned char te_type;       /* from defs below */

Currently, the build file is catered to a Linux installation, but probably all that would need to be changed for a different platform is the system include path and the library extension.

To do a build, just run:

zig build -Doptimize=ReleaseFast

EDIT: Changed the struct to an extern struct to guarantee the ordering of its fields.

EDIT2: Functions are now inside the struct. This seems to be more idiomatic to Zig, plus it looks nicer.

EDIT3: Link with libc during the build process.
This keeps the external's size small, even when adding math functions like log or exp to it. Otherwise, there's an increase of about 115KB because those functions get baked right into the external.

EDIT4: Replace m_pd.h with custom definitions that allow many functions to be called as methods. Some examples:

adding a method to a class:

pd.class_addbang(myclass, @ptrCast(&bang)); // old way
myclass.addBang(@ptrCast(&bang)); // new way

creating a new instance of an object

// old way
const self: *Self = @ptrCast(pd.pd_new(myclass));
_ = pd.outlet_new(&self.obj, &pd.s_float);
self.sym = pd.gensym("world");

// new way
const self: *Self = @ptrCast(myclass.new());
_ = self.obj.outlet(pd.s.float);
self.sym = pd.symbol("world");

sending a float through the main outlet:

pd.outlet_float(self.obj.te_outlet, f * 2); // old way
self.obj.out.float(f * 2); // new way

hello-zig.zip

repo: https://github.com/myQwil/pd-zig-external

More examples can be found on my library's Zig rewrite branch:
https://github.com/myQwil/pd-quilt/tree/zig-rewrite

@pajzd said:

so, what does this mean for os X

Same thing. It should work for both OS X and macOS.

If gme(s) are not working as expected, let me know. There's a gme post where we can continue that discussion: https://forum.pdpatchrepo.info/topic/11828/gme-gmes-game-music-emu

Also, bear in mind that the latest version of the quilt library switched from using ffmpeg@4 to just ffmpeg. That's if you download the library through deken, which I would recommend from now on.

@tatsuya_yamada That would probably prove to be quite difficult. The packets would have to be retrieved in reverse order, but FFmpeg doesn't index the packets. So for the time being, reverse playback is not a feature.

@whale-av You should be able to find those missing objects in the original zip of the first post

Performing a static build is also an option. That would make it so that the libraries are built into the external. I've always been on the fence about distributing a static build though because I've read that some of the decoders used in the ffmpeg library are proprietary. Their site talks about that near the bottom of this page: https://www.ffmpeg.org/legal.html

It sounds like it's only a problem if someone, as they put it, "starts trying to make money from patented technologies" but since this is being distributed freely, it's probably not an issue.

Okay, I think I've found out the problem. Here's the list of dependencies of ffplay~.m_amd64:
avcodec-58.dll
avformat-58.dll
avutil-56.dll
swresample-3.dll

But all the libraries have been updated since I built it, so the version numbers in their names have been incremented to 59, 57, and 4.

So, you could probably just rename the dll's and my guess is it'll still work.

My guess is it either needs a fresh build or it's missing some other dependency from MSYS2/MinGW.
I recommend trying Dependency Walker. It might be able to shed some light on which dependencies aren't being met. Their site: https://www.dependencywalker.com/

If that doesn't work, I'll see about doing a fresh build tomorrow

ffplay~.m_amd64 can be found inside of ffplay.zip
It's basically a dll with a special naming convention so that 64 and 32-bit builds of the same external can reside in the same folder

Also, thank you for sharing your OSX build

This should be what you need for the Windows version: https://www.gyan.dev/ffmpeg/builds/ffmpeg-release-full-shared.7z

Inside the zip, there's a 'bin' folder and you just need to extract the .dll files and place them in the same folder as ffplay~.m_amd64. I'm assuming it'll still work. Even though the ffmpeg libraries are newer than when I built it, no big changes have been made to how any of the functions are called.