To register and login, use your Google, Twitter, Facebook, LinkedIn, or OpenID credentials.

This is allowing us to stop most spam registrations. We've deleted most of the spam accounts that got through, and we're closely watching for more.

Building pd and libpd from source on non iOS or Android platforms

NoPoNickNoPoNick Posts: 1
edited December 2012 in Pd Everywhere

Hello, this question is about building vanilla pd (and libpd) from source to use on an embedded processor.

I am interested in using libpd on an embedded DSP processor, specifically, an Analog Devices SHARC DSP (266 MHz, native floating point), a part I’m familiar with. I’ve read the instructions and tutorials available for getting started with libpd, but some things are still not clear to me, and some instructions remain unclear for my purposes.

First, most of the instructions for using libpd are understandably focused on iOS and Android, and typically involve executing some sort of makefile command to kick off some initial compilation. Since I want to use libpd on an embedded processor with its own unique compiler/linker, it seems like I’ll need to build vanilla pd / libpd without these makefiles, and instead directly from source in the tools for the DSP.

I haven’t been able to find instructions on how best to do this. For example, I’ve had success using the embeddable scripting language Lua follow these instructions ( ) which indicate how to build the Lua library, compiler, and interpreter from source if you want to run in a native C, but not Window/Linux environment. Are there similar instructions for building pd/libpd?

A second more general question I have is in regards to vanilla pd, and the version of pd supplied with the libpd source. I assume that typical vanilla pd source includes basic graphics source files necessary for using pd in the typical way, but the vanilla pd source supplied with libpd removes this, and only includes the audio processing/messaging/etc source. Is this accurate? Can I build vanilla pd from the source supplied with libpd by itself, or must the libpd layer also be included?

Thanks for any help or information you can provide to point me in the right direction!


  • owenooweno Posts: 4

    I'm very interested in running libpd directly on an embedded board as well. I've so far been using embedded Linux boards (most recently the Raspberry Pi), and it compiles easily.

    Running it directly on processor without an OS would be more of challenge since pd/libpd depends on some OS functionality, like like opening files. So I guess the DSP would have to provide things like a file system, but maybe this isn't so difficult ?

  • reakinatorreakinator Posts: 301


    libpd is just C, so if the compiler you need supports that, there should be a way.

    The pd source in libpd can essentially be thought of as 'Pd Core' - the stuff that processes audio, control data, parses patches, and maintains the audio graph. This part of libpd is exactly the same as Pd Vanilla (Peter is pretty deligent about keeping it in sync), and Pd Vanilla comes with the tcl/tk layer + audio / midi drivers so that it can be a standalone system. It also drivers the 'ticker' in pd, which is up to you and your audio sdk when using libpd.

    There is an extra layer that libpd adds on top of Pd Vanilla, which you'll find in the 'libpd_wrapper' folder - z_libpd.h is the important one to lookat. It conveninetly exposes messaging hooks, handles audio processing callbacks, and does other things like send / receive midi.

    To get this to work on your board (assuming you can get the code compiled for it), it may help to first look at the 'PdBase' classes in each of the language wrappers - they all rely on z_libpd.h/c and add higher-level, language specific functionality on top.

    @oweno makes a good point as well; currently pd relies on fopen to access pd patches - there's no getting around that that I can see, without modifying a very tricky part of the source (patch parsing). It would be great, however, if there was an alternative method that took in a string, or someone found a workaround for this. If not and this proves to be a roadblock for you, a feature request should be filed on the pd sourceforge page.

    Hope you make some progress! Please let us know how it goes.

  • pbrinkmannpbrinkmann Posts: 685 ✭✭

    What @reakinator said; also, take a look at libpd/Makefile. That one builds the basic C library for Linux, Mac, and Windows. It'll get you started as far as source files and compiler/linker options are concerned. Good luck, and keep us posted!

  • NwPdxRichNwPdxRich Posts: 1
    edited January 2013

    I'm working with NoPoNick on this project. Our agreed upon first step is to get the code building in a visual studio project in windows. So, last night I took all of the files referenced in the libpd/Makefile (plus all related header files) and put them into an empty visual c++ project. I then added the two folders that all of the files are located in into the project's include paths. In this state, the project did not build, so I went through and compiled each file individually and found that only 6 of the 79 files don't compile. Here are the six files:

    g_canvas.c m_class.c s_file.c z_libpd.c m_sched.c d_soundfile.c

    First of all, I was getting tons of the following warnings: warning C4273: 'pd_objectmaker' : inconsistent dll linkage

    which seem like they are because I'm not actually building a DLL so the function prototypes that are externed for dll purposes have nowhere to go. We may have to address that eventually because they might be errors on the SHARC, but i'm not too worried about that for now. Regardless, I disabled warnings in the compiler so that I could see the actual errors without having to filter through a bunch of warnings.

    z_libpd.c seemed to be choking on macros. There are a bunch of macros are defined at the top of the file, and it didn't appears that the compiler is inserting them correctly. I've seen this before with C89 compilers, which is what visual studio uses by default for .c files, so i renamed the file to .cpp and all of the macro-related errors went away. A few errors still remained and they all seemed to be type errors, so i casted to the expected type in the five or so places where there were errors and the file compiled.

    As a side note (to those that are interested), the errors in .c versions of the files were mostly c2099-"initializer is not a constant", which is explained here:

    Since it is a C89/C90 issue, renaming to .cpp forces the visual studio tools to use a c++ compiler.

    I did the same thing in s_file.c and m_class.c--renamed to .cpp and fixed a couple of casting issues and they compiled. So far, so good.

    Upon minimal inspection, it seems like a lot of the files referenced in the make file are for GUI stuff, which we don't need. My theory is that everything in the pure-data/src folder prefixed with "g_" is graphics stuff. Given that and the fact that I was having isues getting g_canvas.c to build even after making it a .cpp file and adding some casts, i just removed all g_* code from the project. This leads me to my first question--what's the meaning of all of the different file name prefixes? And, am I correct in assuming that g_* files are for graphics?

    So that left m_sched.c and d_soundfile.c which are both looking for pthread.h which isn't anywhere in the libpd archive. Wikipedia tells me this:

    In our target embedded application we will be managing the different threads in our framework. This leads me to think that we can get by without the threading/os stuff. Note that we do have the fopen stuff and other file related functions under control on the embedded processor (or so we think), so by 'os' i mainly mean the 'processing framework.' This brings me to my final question--if we just want to be able to load and process a pd patch which files of the 76 are related to that. Are there any that we don't need to worry about including in the project?

    Any wisdom is appreciated. Thanks!


Sign In or Register to comment.