@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.

@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.

@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.

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...?

@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!

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.

Now includes searching of a Pd-extended path if provided.

Thanks for the good suggestions.

To me, it sounds like a job for Python! https://github.com/baffalop/skrypts

Hi, I wonder if there exists something like a linter which can scan a patch or directory, looking for non-Vanilla objects and preferably saying which external library each belongs to?

When you're looking to check the portability of your patches, what do you use?

@whale-av Thanks for the suggestion, but I couldn't even see how to add a path by text - a file browser window was opened every time.

I have switched to using Purr-Data, and it's pretty nice. Doesn't break on adding search paths.