Hi all. I've recently become a committed Purr-data (Pd-l2ork) user; curved patchcords alone are something I have become very attached to. However, I have been struggling to add new externals, until I chanced upon some stuff suggesting I would have to compile any externals I wanted to add myself. I just wanted to understand why this might be the case, and what the going solutions/alternatives are. (eg. is it possible to use Deken?)

I'm on MacOS 64-bit; I have downloaded (and added to my search paths) the xplay library containing .pd_darwin files. I can see from running file xplay.pd_darwin that it accommodates i386 architecture... and so I don't quite understand why I would need to compile it myself to get it to work.

Could someone please provide an explanation for that, and any suggestions for how to most easily add externals? Apologies if this has already been covered multiple times, but my search results were scattered and inconclusive.

I'm new to purr-data and not a mac user, but according to the documentation you can install externals simply by putting them in the right directory (see: https://agraef.github.io/purr-data-intro/Purr-Data-Intro.html and scroll down to "Installing externals"), but it would seem you have done that already.

The readme file of the xsample says this though: "xsample is a library containing several external objects. You should load it at PD startup by adding "-lib xsample" to the PD command line. (If you forgot to do that, you can load the library by creating an [xsample] dummy object.)" Seems worth a try.

@bocanegra 🤦‍♀️ You are entirely right. I didn't know the distinction between singular externals and libraries (though I noticed it didn't have a .pd_darwin file for each object and thought that was rather nifty). Everything is working now. Thanks for doing my reading for me!

I spoke a little too soon... When I say it worked, I actually tried it for a different library I was also trying to load. So that's great: I can load external libraries.

With xsample though, I get xsample: can't load library. I've tried both adding -lib xsample to the startup flags, and adding 'xsample' to the libraries list. Any ideas...?

In a terminal window try file foo.pd_darwin where "foo.pd_darwin" is the external library file.

My guess would be you have a 32-bit external lib for xsample and are trying to load it in a 64-bit Purr Data binary.

AFAIK xample is only available in 64-bit for linux... -> https://puredata.info/downloads/xsample/releases/0.3.2 --> "libdir for GNU/Linux i386 and x86_64, Mac OS X i386/PowerPC, and Windows 32-bit" --- I guess that mean you'll have to compile the source ball manually. But, hey, it's not that scary. only thing I'd worry about is that the library is still in beta, and seems to have been unmaintained for a year or more. Also, apart from the 'groove~' object (which I'm not sure what does), you can do sampling and playback easypeasy with pd vanilla objects, so I wonder if it's worth the trouble...?

@bocanegra You're quite right. I had done file on the file in question, but was confused about what i386 means. Now I know, I'm looking out for the keywords x86_64 or just some mention of 64-bit. Well perhaps I will try to compile it myself... (deep breath)

As for why it's worth the trouble - I'm trying to solve an issue with audio artefacts resulting from precision errors in the index signal sent to [tabread4~]. The other library I successfully loaded was iem_dp to get double-precision [phasor~~] and [tabread4~~] objects. That solves it, but using the xsample objects would be simpler.

@baffalop You are probably going to hit a brick wall, even with your compiled objects.
What is possible in analogue audio is not always possible in digital.
The question is "how do you interpolate white noise?" and the answer to that simple question tells you that with any unpredictable signal (not a sine wave) you will always have artefacts.
(Of course with a very complex signal they will be less noticeable).
https://forum.pdpatchrepo.info/topic/11353/tabread4-example-or-alternative/8
The whole thread, and links, are worth a read.
David.

@whale-av I am actually coming off the back of exactly that thread in trying this solution. The issue under question is not interpolation error: I can live with that, and it should only become noticeable at extreme playback rates. The issue is the precision of the index signal sent to [tabread4~], which for longer tables results in truncation error - in effect, bit-crushing. I am using iem_dp as per beep.beep's solution in that thread.

However, I hadn't actually looked into the B15 and B16 tutorials, but was encouraged by your response to do so. So there is a fix for this in Pd-vanilla! It looks excessively clever (as all of Puckette's best ideas are), and I will need some time to wrap my head round it. Will definitely work towards implementing. The weak link seems to be the low-frequency polling of the phase via [metro]. I suppose that's the limitation that drove beep.beep to use iem_dp after all.

@baffalop You can try one of the "purr-double-trouble" builds:

https://github.com/jonwwilkes/purr-data/releases

These use 64-bit floating point for the numbers in Pd, so you won't run into the problem that Miller's extra inlet is trying to solve.

Do note the "trouble" part-- these are initial releases with just the core. I haven't shipped the externals yet.

@jancsika Niice, glad to know this is in the works! I might check it out, but at the same time, portability is a concern for me. I'd like to be able to load this patch onto the Organelle eventually.