Hello all,

I have recently stumbled into some problems compiling PD externals. I figured I would post here, it's a two part question

Compiling on/for Windows:
The first, and likely easier question, is I am trying to compile this external for the ES-5 encoder provided by Expert Sleepers for their DC coupled Eurorack interface:
https://github.com/expertsleepersltd/externals/tree/master/pd/es5encoder~

However, when I attempted to run the makefile I am encountering numerous errors that lead me to believe my environment isn't setup for compiling PD externals. Is there somewhere that outlines how to compile an external like this where there is limited/no documentation in the README? I don't know how generic of a process it is and if it's fairly standardized.

Second question:
I have a library that I would like to use with PDParty (iemmatrix) and I need to compile this into a static library to be able to use it on iOS. Is compiling to a static library drastically different than to a dynamic one? Are there limitations design wise that particular libraries might be incompatible with?

Sorry if the wording here is confusing at all. I haven't dealt much with compiling libraries for different platforms so I am a bit lost on some of the basics.

Any help, as always, is greatly appreciated

on the windows makefile question: depends what the errors are, but from glancing at it it seems like the makefile was created w/ a very specific directory layout in mind..

afaict when you link with a static library the entire machine code of the necessary translation units (.c files) is just included in the binary you're compiling. That's opposed to dynamic/shared libraries that are stored in their own binaries and loaded (dynamically) at runtime.
To me it makes sense to use a shared library when you have multiple programs that need to use the same library. I think this cuts down on space and ram..
But it makes sense to use a static library if you're distributing a single binary application for instance, and you aren't sure if the necessary dynamic/shared lib exists on the user's computer yet.
If you use dynamic/shared libs you also have to point the binaries that use them to them. (like set rpath)

@seb-harmonik.ar I noticed that as well. Is this something that automake could potentially handle? I recall compiling an external a while back that used that, but I don't know how usable such a tool is for compiling PD externals.

Ahh that makes sense. Thanks for the explanation, when I was hearing static my instinct was it would have some sort of limitation similar to a static function.

@lo94 you might want to look into converting the whole thing into pd-lib-builder https://github.com/pure-data/pd-lib-builder
personally I always compiled stuff on windows using msys2/mingw64. seems like this project is using some visual studio based situation

basically, for compiling externals you have to include the m_pd.h header somewhere. There are some other flags that are used often
this guy https://github.com/grrrr also has some c++ externals, for reference..

@seb-harmonik.ar Oh awesome, I had no idea this existed. Thanks for the tip, if this works reliably seems like a great tool

Awesome thanks. Looks like he has some pretty cool externals on there as well that I'll have to snag.

@seb-harmonik.ar Okay so I managed to get it compiling using the pd-lib-builder! Thank you

However, I am encountering an error that perhaps you could help with. I added the directory of the external to my PD path, and added the library to load on PD startup in the startup menu. However, when attempting to load the library it throws the following error:

load_object: Symbol "es5encoder_setup" not found

I see that the main.cpp file for this encoder does contain a es5encoder_tilde_setup method, but not a es5encoder_setup method. I am assuming this required for external libraries? I'm wondering if maybe this was a change in more recent builds of PD, as this external appears to have been last updated about 9 years ago.

@lo94 did you create it with [es5encoder] or [es5encoder~]? you have to do the latter I think
edit: I don't think it's a library so much as individual objects..

@seb-harmonik.ar Ahhh thank you! So when a library is compiled to a .dll, the compiled .dll itself needs to have the tilde symbol? Just trying to figure out how PureData actually loads/parses all of this

@lo94 one issue is the multiple coexisting uses of the term 'library'.. in pd terms 'library' is usually a set of distributed classes, whether those are abstractions or compiled objects.

however, compiled objects can come either in a single binary (usually with the name of the library) or multiple binaries.

If they come in a single binary (like zexy these days), then you can load the classes in that binary with the 'library' startup option or [declare] it.

But if the classes come as separate binaries or abstractions you can just use the class's name to load the class & create an object if it is in the path. (and if not you can add the path with the path startup option or [declare] it as well)

If you try to create an object with a certain name pd will look for it to see if it's already loaded, then it will look for binaries with that name and call a corresponding setup function in the binary if it finds one. So if the setup function has _tilde then the binary it's in must also have a tilde and the object must be created with one too (if the classes are distributed in separate binaries).

However in single-binary libraries you can register alternate ways to create objects of a certain class when the library loads. (zexy uses this for instance, you can use either [demux] or [demultiplex] to create an object of the demultiplex class)

@seb-harmonik.ar Thanks for the concise explanation, that's extremely useful, definitely keeping this thread bookmarked for a while while still getting my head wrapped around all this