Libpd and Juce - from a noob's perspective!

Hi All,

I’ve always struggled with anything more lowlevel than Arduino/Processing/Openframeworks so forgive the dumb question.

I’ve come here through libpd and after watching hours of Juce conference videos but still not really having a great understanding of Juce. To my knowledge it appears to be a layer of abstraction between the OS and your application that takes care of all the audio glue. But if so, why would anyone want to combine libpd with juice, since that’s also what libpd does?

There is even a thread in this forum talking about the possibility of embedding Juce into Pure Data! Now I’m really confused.

JUCE is an OS level abstraction library, covering not just audio, but all of the major OS API’s, file system, UI, process/thread control, etc. While I believe libpd is Pure Data without the GUI? So, I assume it operates on PD objects, and can lod PD patches, etc. It seems one would want to use libpd if they want to either create, and/or load and use PD patches in their app. So, embedding it in a JUCE app makes total sense in that context.

Yes, I see now. It’s handy if you specifically want ‘PD patches’ in your app. Maybe as a feature for end users, but I guess once you go to the trouble of coding a JUCE app, you might as well port all of your DSP to JUCE since libpd/PD is not very CPU friendly.

I was able to get the Pd Pulp (libpd based) project linking and running as an AU plugin on macOS 10.14.4 and I was also
able to get a simple libpd native iOS app running based on cheetomoskeeto’s youtube tutorial:

4 years ago Fabian posted this video regarding the Pd Pulp project. It seems to me there are two major problems - 1) libpd is said to be “inefficient” for signal processing and 2) libpd can only exist in one plugin instance. Does anybody have any more recent information on this?
Douglass Barr mentioned something about the heavy hvcc compiler for Pure Data patches, but these folks say the repo is not being maintained:

Then there’s Camomile: https://github./pierreguillot/Camomile but hasn’t been updated in a year.

libpd itself: is still active and has about 35 contributors.

So is pursuing libpd for a new cross platform JUCE app worth the trouble?

  • Nick

I always found libpd a little bit of a pain to get up and running. The fact that it has so much global stuff makes it a little restrictive in terms of what you can do with it. However, I have built Android apps with it, and it worked fine. I guess it depends on what you want to do.

For what it’s worth, I use Csound in the same way I imagine you would like to use libpd. Its API is quite easy to work with and it doesn’t have any of the limitations you find with libpd. And it runs across a huge range of platforms. Of course, it doesn’t provide a GUI environment like Pd, but when that’s ultimately hidden from the end-user it doesn’t make any difference.

Camomile is apparently still developed, there are some commits in a branch from this year.

libpd probably isn’t worth it, if you are not planning to allow the end users to edit their own patches. Are you planning on that or is there some other reason you are interested in using PD’s code?

Thanks for the responses folks. As Rory says the global stuff in PD is probably going to make it very hard to use in the context of a an AUv3 plugin - I bet the crashes Fabian was mentioning 4 years ago have something to do with that. And yes, it’s probably right that using a PD patch as inspiration is the best way to go, and then come up with a way to rewrite it it JUCE. I’ll take a closer look at CSound and report back to you all. Thanks-

  • Nick