Success! My internet has been down for a week, so had to wait until today before I could try installing fftw via Homebrew. I was able to do so without much trouble, and after re-editing the bsaylor makefile & recompiling, the patched version of pvoc~.pd_darwin is up & running properly in 64-bit!
I really appreciate your help! I wouldn't have known where to begin without your helpful advice.
Thanks for those links to compiling info, much appreciated!
I think I'm getting closer... I realized that the makefile is pointing to /include because that's where m_pd.h is located in Pd-Extended, but that file is in /src in the vanilla versions I'm using. I tried changing that path, and also tried pointing to a version of Pd-Extended that I have, but now I get this:
fatal error: 'fftw3.h' file not found
The bsaylor library comes with a /libs folder containing libfftw3.3.dylib and libfftw3f.3.dylib (required for partconv~ and pvoc~). Perhaps the makefile is looking for these libraries when compiling? I don't see a fftw3.h file anywhere in the source code of pd (including extended).
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.
Aha! You're correct, I was pointing to the 32 bit version of Pd-0.47-1. I tried once again with Pd-0.47-1-64bit (updating the PD_INSTALL_PATH in the makefile), and it seems to have compiled successfully! But, as you point out, the library can only load in the 64 bit version of pd.
The only reason I've been temporarily sticking with the 32 bit version is because my main performance patch uses a few libraries & objects which don't seem to work in 64 bit. But I would like to migrate at some point, as it seems like CPU performance is somewhat better in 64 bit (and maybe also other benefits that I don't know about?).
Unfortunately that brings me back to a similar noob problem: I use bsaylor's pvoc~ quite a bit, and although there is a fix which updates it to be 64-bit compliant (https://lists.puredata.info/pipermail/pd-list/2015-06/110377.html), I don't know how to apply a .patch file to a .c file & compile for my platform. I'll keep searching online & see if I can teach myself, but if anyone has any quick pointers for how to pull this off, I'd be very grateful!
Thanks for the idea; I removed -Werror from the makefile_darwin CFLAGS and tried it again. As you indicated, the unused parameter warnings didn't generate errors, so the process went as far as creating .0 files for every object in the library.
But here's where it seems to have run into more trouble (I think):
touch iem_dp.c cc -DPD -DUNIX -g -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -O2 -fno-strict-aliasing -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -DPD -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -c -o iem_dp.o iem_dp.c :: symtodp.o dptosym.o dptohex.o ftohex.o vline~~.o samphold~~.o wrap~~.o phasor~~.o print~~.o add__.o sub__.o mul__.o div__.o add~~.o sub~~.o mul~~.o div~~.o tabwrite_dp.o tabread_dp.o tabread4_dp.o tabwrite~~.o tabread~~.o tabread4~~.o max__.o min__.o max~~.o min~~.o random__.o delay~~.o iem_dp.o cc -bundle -bundle_loader "/Applications/Pd-0.47-1.app/Contents/Resources"/bin/pd -o iem_dp.pd_darwin *.o -ldl -lm -lpthread ld: warning: ignoring file /Applications/Pd-0.47-1.app/Contents/Resources/bin/pd, missing required architecture x86_64 in file /Applications/Pd-0.47-1.app/Contents/Resources/bin/pd (2 slices) Undefined symbols for architecture x86_64: "_atom_getfloatarg", referenced from: _add___new in add__.o _add_tilde_tilde_new in add~~.o _delread_tilde_tilde_new in delay~~.o _div___new in div__.o _div_tilde_tilde_new in div~~.o _max_dp_new in max__.o _max_tilde_tilde_new in max~~.o ... "_atom_getsymbolarg", referenced from: _delread_tilde_tilde_new in delay~~.o "_bug", referenced from: _tabwrite_tilde_tilde_stop in tabwrite~~.o _tabwrite_tilde_tilde_perform in tabwrite~~.o "_class_addanything", referenced from: _symtodp_setup in symtodp.o "_class_addbang", referenced from: _add___setup in add__.o _div___setup in div__.o _dptohex_setup in dptohex.o _dptosym_setup in dptosym.o _max_dp_setup in max__.o _min_dp_setup in min__.o _mul___setup in mul__.o```
...etc, omitting a long list of 50 or so undefined symbols, ending with:
ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [all] Error 1
Not sure what sense to make of that... missing required architecture x86_64 seems significant?
Thanks for your insights, Alexandros!
I did indeed run into that problem with the naming of Pd-0.47-1.app; when I first tried the pd_darwin makefile, I got an error that the compiler couldn't find m_pd.h, so I figured the path might need to be updated.
I tried makefile_d_fat as well (with the correct Pd /src path), and got even more errors in addition to the same unused parameter errors as the darwin version.
/usr/include/sys/cdefs.h:761:2: error: Unsupported architecture
I'm not sure whether I have any other compilers I can try (I do see "gnumake" in my newly-downloaded Command Line Tools, don't know if that's any different than the other "make"? this is literally my very first attempt at compiling).
But if there is indeed a problem with the source code, I suppose it could be a moot point. I did try deleting symtodp & running the darwin makefile again—this time it got as far as creating a dptosym.o file, but it ran into the unused parameter error once again on dptohex.c and gave up.
I've been trying for a solid few days to get iem_dp working on my Mac (for double precision lookup of long arrays), but I seem to have reached the limits of my abilities.
I downloaded the library from https://git.iem.at/pd/iem_dp/tree/master which contains the helpfiles, .c files for each object, and four makefiles for different architectures (including makefile_darwin, which I assume is the one I want for MacOS 10.12. I have no experience with compiling files, so I tried downloading Command Line Tools, and ran "make -f makefile_darwin" in Terminal, but I only get errors (see below).
Does anyone know what the problem might be? Or, does anyone happen to have iem_dp compiled for pd_darwin?
touch symtodp.c cc -DPD -DUNIX -g -Wall -W -Werror -Wno-unused -Wno-parentheses -Wno-switch -O2 -fno-strict-aliasing -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -DPD -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -c -o symtodp.o symtodp.c symtodp.c:86:50: error: unused parameter 's' [-Werror,-Wunused-parameter] static void symtodp_list(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:96:61: error: unused parameter 'ac' [-Werror,-Wunused-parameter] static void symtodp_anything(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:96:73: error: unused parameter 'av' [-Werror,-Wunused-parameter] static void symtodp_anything(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:120:37: error: unused parameter 'x' [-Werror,-Wunused-parameter] static void symtodp_free(t_symtodp *x) ^ 4 errors generated. make: *** [symtodp.o] Error 1```
My first contribution to the Patch Repo (and greater Pure Data community at large)!
In my own performance patch, I found myself re-creating this concept over & over again with slightly different parameters, and eventually realized I should just make an abstraction to save myself a lot of time & energy in the future.
The basic idea is simple—essentially just feeding [random] into [line] so that values will float around within a defined range at unpredictable intervals (without discontinuities between the ramps). You can set a center value and deviation percentage, so that the ramps will stick close to a value within the overall range. For example: playing sound files with [phasor~] and [tabread4~], I often like to add a touch of warping to the speed, so with this module I can send the phasor speed to argumentname-randcenter, set a range of values around the center (with small deviation %), and let the warping begin without having to redo all of the math.
Also, the module's output is sent to both the outlet and also to a [send] which is set by the creation argument, thus you can use the receive name of an existing slider in your patch as a creation argument, set the min/max and other preferred parameters, and it's ready to go.
Finally, I added the low clip % control to prevent the "jumpiness" that results when very low values of [random] are fed into the right inlet of [metro] (which can sound like discontinuities in certain applications). So, for instance, if your maximum rate in milliseconds (set by rate_range) is 3000, and you set low clip to 10%, none of the ramps will be faster than 300 ms. And, setting low clip % to 100% will result in a regular metro pulse at the specified maximum rate.
Hope you find it useful! Feedback/improvements welcome of course. (and apologies for the messy patching with the min/max/center calculations, still learning how to keep simple math from looking incomprehensible with cables running all over the place…)
Update: got it working!
The solution: as best as I can tell, TouchOSC refuses to send OSC over USB unless wifi is enabled on the iPad (despite the fact that it isn't actually using the wireless connection). I turned on wifi, and bingo! OSC can be sent in both directions.
Just wanted to post the solution for anyone who's interested. The wired connection is a huge improvement over the ad-hoc method—I can send a massive volume of OSC data back & forth with no noticeable latency, and the connection did not once fail during several hours of testing (compared with all kinds of disconnections & hang-ups I would get over wifi).
TouchOSC users rejoice! Quite a powerful controller for $5 (plus $7 for Midimux).