Compiling only TimbreId against pd (not compiling pd source).

To load timbreIDLib, list the path to the timbreIDLib library file in Pd's startup dialog (e.g., /home/yourname/pd_libs/timbreID/timbreIDLib).

timbreID version 0.7 requires the FFTW library, available at http://www.fftw.org.

FFTW is included pre-compiled with timbreID's Windows binary package available through deken. It's fine to simply leave libfftw3f-3.dll in the timbreID directory for use as a shared library. For Linux and Macintosh, FFTW is statically linked with the timbreIDLib library file, so there is no need for compiling or obtaining FFTW.

If you are compliling FFTW yourself, it must be compiled in single precision. To do so in Linux, configure FFTW like this:

./configure CFLAGS="-fPIC" --enable-float

and like this on a Macintosh:

./configure CFLAGS="-arch i386 -arch x86_64" --enable-float

Then run:

make
sudo make install

The FFTW library for Windows is available precompiled at:

http://www.fftw.org/install/windows.html

You will need the 32-bit version, and the single precision version specifically. The provided zip file contains several compiled versions of FFTW, but only libfftw3f-3.dll is required for timbreID version 0.7.

On Linux and Macintosh, the FFTW library files should be installed to /usr/local/lib by default. Once FFTW is properly built and installed, you can make timbreID using the included Makefile by running:

make

You must specify the location of your Pure Data source code directory in the Makefile beforehand. Compilation from source on Windows can be done with the same Makefile if you use MinGW: http://www.mingw.org

On Linux and Macintosh, timbreIDLib will statically link the FFTW library. On Windows, you will either have to set up an environment variable to point to the location of libfftw3f-3.dll, or simply put libfftw3f-3.dll directly in the timbreID directory.

Cheers~

So here's the error message I get on $ make. Nothing at all exotic about the install (Lubuntu, 16.04). Jack installed, but currently just using pulseaudio.

fatal error: alsa/asoundlib.h: No such file or directory
compilation terminated.
Makefile:709: recipe for target 'portaudio/src/hostapi/alsa/pa_linux_alsa.lo' failed
make[2]: *** [portaudio/src/hostapi/alsa/pa_linux_alsa.lo] Error 1
make[2]: Leaving directory '/home/greg/pd-0.48-0/portaudio'
Makefile:496: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/greg/pd-0.48-0'
Makefile:420: recipe for target 'all' failed
make: *** [all] Error 2

@weightless

Hi there,

Indeed, if you’ve read the long thread above you know that this was my first time compiling as well, so I can definitely relate to the feeling of flying blind!

5 months later I can’t quite remember which edits I made to the bsaylor makefile, but I’m pretty sure this one is the final version that ended up working for me:

Makefile

If memory serves, I removed all objects other than pvoc~.c and partconv~.c from “SOURCES” (I think because the others were already working in 64 bit?), and also made sure the path pointed to “PD_PATH = /Applications/Pd-0.47-1-64bit.app/Contents/Resources”. Then I ran “make” (with the patched pvoc~.c in the same directory as the makefile, and fftw installed as noted), and got my new pvoc~.pd_darwin file to replace the old (non-64 bit) version in my bsaylor folder.

It was rather satisfying to successfully compile, but I still can’t say that I understand most of the errors that pop up during the process. It’s also entirely possible I’m forgetting other key steps that I took, as I was beating my head against this for days at the time. If it helps, here’s the darwin file that I got working on 64 bit:

pvoc~.pd_darwin

OK, so applying the pvoc~ 64-bit patch was rather easy:

patch pvoc~.c < bsaylor_pvoc~.c.patch

But unfortunately I'm back to my original problem—the makefile that is included with bsaylor throws a bunch of errors when I try to compile the library, and I don't have any expertise (besides a few days ago with iem_dp) to guide my troubleshooting. I spent a good chunk of the day editing everything I could make sense of in the makefile (changing the path from Pd-extended.app to Pd-0.47-1-64bit.app, deleting things that seemed to be causing warnings), but still no luck.

clang: error: unknown argument: '-ftree-vectorizer-verbose=2'

...

fatal error: 'm_pd.h' file not found

...

/usr/include/sys/cdefs.h:761:2: error: Unsupported architecture

...

In file included from /usr/include/stdint.h:52:
/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */

In file included from /usr/include/stdint.h:52:
/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */

Does anybody know of a very simple step-by-step beginner's guide to compiling objects/libraries from source? I see the words "just recompile for your system" quite a bit, but even with several days of unguided googling, I can't say I feel like I understand even the basics. (other than running a makefile & hoping for the best...) I'm not averse to rolling up my sleeves & learning how to do it, rather than bug everyone for help every time I run into an error.

The errors come from the source code of the symtodp object, nothing to do with the makefile. I'm no C guru but it seems strange to me why an unused parameter would cause an error and compilation fails (all four errors have to do with unused parameters in that object). Maybe it has to do with the compiler you're using, but that's only an assumption I make that kind of makes sense to me, I could be completely wrong here.
Looking at the makefile, symtodp is the first .c file, which means that even if you skip that object, you'll might get similar errors in other objects as well.
One question, which Pd are you using and how is it named in your /Applications directory? Is it Pd-0.47-1.app? If so you'll probably have to change one line in the makefile, line 5, which reads:
PD_INSTALL_PATH = "/Applications/Pd.app/Contents/Resources"
If you haven't changed that, change it to:
PD_INSTALL_PATH = "/Applications/Pd-0.47-1.app/Contents/Resources"
so that your compiler can find the header files Pd uses.

NoteL makefile_d_fat is also a makefile for OS X, but I think they are more or less the same (if you use that, the same change in line 5 should be included).

Hope that helps.

Ok, so I installed automake and libtool sepearately; both the autogen.sh and configure.ac files unloaded fine when I ran them, but the final command 'make' generated a whole lotta text ending with the following:

../libtool: line 1737: g++: command not found
Makefile:699: recipe for target 'pd' failed
make[2]: *** [pd] Error 127
make[2]: Leaving directory '/home/brendan/Documents/pd-0.46-7/src'
Makefile:925: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/brendan/Documents/pd-0.46-7'
Makefile:825: recipe for target 'all' failed
make: *** [all] Error 2

Maybe I need to take this to a Fedora forum ? ?

Brendan

Well, this is the generic Makefile provided by Hans-Cristoph Steiner iirc. It's funny that you get this error (which comes from line 94) because I've compiled some objects on OS X without problems. Usually the only thing you need to check is in line 93, where you specify the path to Pd's files (like m_pd.h). In this Makefile it says that there's no need to change anything beyond line 42, but this Makefile was for Pd-extended which is now dead, so you should probably change line 93 to make the Makefile point to the directory of vanilla's files (if you're using vanilla).
I really don't know why this creates an error. Make an online search and see if you need to set something else instead of that. Which OS X are you using?
Try to comment that line out (by putting a # at the beginning of the line) and give it another try. Dunno, maybe it will work... I'm not a compiling-savvy guy, so there might be something I'm missing....

@Pierre-Guillot

so I think the linker should be set to -lCicmWrapper but I got conflicts and undefined
can you help me out ?

cc   -rdynamic -shared -L"D:/WORK/DSP/pd-0.46-7/src" -L"D:/WORK/DSP/pd-0.46-7/bin" -o "src/adsr.dll" "src/adsr.o"  -L"D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs" -lCicmWrapper  -lc -lpd  
D:/WORK/DSP/pd-0.46-7/bin/pd.lib(pd.dll):(.text+0x0): multiple definition of `error'
/usr/lib/libc.a(t-d000927.o):fake:(.text+0x0): first defined here
D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs/libCicmWrapper.a(libCicmWrapper_la-ecommon.o): In function `epd_add_folder':
/cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:578: undefined reference to `sys_searchpath'
/cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `sys_staticpath'
/cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `namelist_append_files'
/cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `sys_staticpath'
/cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `namelist_append_files'```

I am having issues compiling the [dssi~] external on an up-to-date Arch Linux (i386) box, also on Arch Linux Arm. Dependencies listed in Readme are all satisfied.

Code:
cc: error: suppress: No such file or directory
cc: error: unrecognized command line option ‘-bundle’
cc: error: unrecognized command line option ‘-flat_namespace’
makefile:48: recipe for target 'src/dssi~.pd_darwin' failed

The Makefile for dssi~ is unlike the Makefiles for [hid] and [plugin~].

dssi~ seems perhaps deprecated. Did [pluginhost~] actually materialize? Is there a preferred object to host dssi plugins?
`]

I'm going to post what I just had to do to compile pd from source in Ubuntu here, because it's the second or third time I've done it, and I still find it a total ordeal. (If nothing else, I'll probably refer back to this post myself if I ever have to do it again.) This is probably too late to help whoever originally posted this thread, and it might be redundant, since there are instructions on the page linked above, but I had problems with those, and I'm going to post what worked for me. Moreover, the documentation inside the tar itself for the build system (in terms of INSTALLs, READMEs and so on) is, in my opinion, fairly confusing, contradictory, and weak. Additionally, these instructions are going to be for compiling pd-extended from source, which I found much harder than just vanilla. So here goes:

firstly, I'm going to assume that you've downloaded and unzipped the tarball available here ('pd-extended for all platforms'): http://puredata.info/community/projects/software/pd-extended

Now, direct your terminal to the directory you unzipped it to, and execute the following:
cd ./packages/linux_make
(note: some sources, including the readme in the root directory, suggest that you should use the makefile in the pd/src directory. I found that this led in my case to a messy, half-broken installation without any properly functioning externals. The one in packages/linux_make seems to work much better for extended.)
make install
(this one will take a while!)
cd ./build
sudo cp -r usr /

IF you run across an error in make with one of the abstraction or external libraries, it may be possible to bypass this by editing the relevant makefile (found in either the externals or abstractions subfolder of the folder you unzipped, naturally). Basically, just open the makefile in question in a textfile, run a ctrl+f search for the name of the library you're having trouble with, and judiciously remove the instance of it which looks like it's telling make to install it. Some judgment is required on this one, but one clue is that it will probably occur in a list with a bunch of other library names around it.

I know the above is a little idiosyncratic, but it's the best way I found to install from source (after exploring many dead ends). I hope this post will be found useful by someone and won't just be considered redundant thread-bumping.