problem creating objects from external iemlib
hi everyone!
I'm trying to run the patch "Ambisonic_2d_example.pd" from the iem_ambi external. While trying to get it to run, I made some changes to the declare statement. You can find the code below..
I installed the externals needed for this patch through deken and I also set the "-lib iemlib" startup flag in PD.
Unfortunately I get the following errors. As you can see PD fails to create some objects (e.g. fadtodb, rbpq, mull~, dsp). These objects seem to all come from the iemlib which is loaded successfully. I have also checked the /externals/iemlib directory.. the four mentioned object-patches are there.
I am running PD on a VM running Debian 11.7 on a M1 MacBook Pro.
I have been trying to solve this for a couple of hours now.. Does anyone know why it's not working?
iemlib (1.22-1) library loaded! (c) Thomas Musil Jul 7 2023 : 18:09:42
musil@iem.at iem KUG Graz Austria
iem_ambi (1.21.1) library loaded! (c) Thomas Musil Jul 18 2023 : 11:42:00
musil@iem.at iem KUG Graz Austria
iemmatrix 0.3.3
objects for manipulating 2d-matrices
(c) 2001-2015 iem
IOhannes m zmölnig
Thomas Musil
Franz Zotter
compiled Jul 18 2023 : 22:25:45
iemlib (1.22-1) library loaded! (c) Thomas Musil Jul 7 2023 : 18:09:42
musil@iem.at iem KUG Graz Austria
♡♡♡
♡ the zexy external 2.4.2
♡ (c) 1999-2023 IOhannes m zmölnig
♡ forum::für::umläute
♡ iem @ kug
♡ compiled Jul 7 2023
♡ send me a 'help' message
♡♡♡
matchbox: OSC-pattern matching code (c) Matt Wright, CNMAT
iemgui (1.21-1) library loaded! (c) Thomas Musil Sep 13 2022 : 19:34:09
musil@iem.at iem KUG Graz Austria
dsp
... couldn't create
rbpq2~ 1000 2 100
... couldn't create
mull~ 1 100
... couldn't create
fadtodb
... couldn't create
matrix_inverse nonsingular
modified_Ambisonic_2d_example.pd:
#N canvas 1512 175 1512 1715 10;
#X declare -stdlib /home/amir/Documents/Pd/externals/iem_ambi -stdlib
/home/amir/Documents/Pd/externals/iemmatrix -stdlib /home/amir/Documents/Pd/externals/iemlib
-stdlib /home/amir/Documents/Pd/externals/zexy -stdlib /home/amir/Documents/Pd/externals/iemgui
;
#X obj 20 44 dsp;
#X obj 20 24 tgl 15 0 empty empty empty 0 -6 0 8 -260818 -1 -1 0 1
;
#X floatatom 20 83 5 0 0 0 - - -;
#X floatatom 33 65 5 0 0 0 - - -;
#X obj 230 88 ambi_encode 2;
#X obj 469 102 mtx_*~ 5 1 100;
#X obj 509 11 noise~;
#X obj 509 32 rbpq2~ 1000 2 100;
#X obj 225 591 mtx_print;
#X obj 230 140 mtx 5 1;
#X msg 230 51 col 1 \$1;
#X obj 230 109 t b a;
#X obj 699 118 prvu~;
#X obj 700 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 719 118 prvu~;
#X obj 720 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 739 118 prvu~;
#X obj 740 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 759 118 prvu~;
#X obj 760 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 779 118 prvu~;
#X obj 780 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 1 0;
#X obj 115 222 loadbang;
#X obj 442 257 mtx_*~ 2 2 100;
#X obj 537 257 mtx_*~ 2 2 100;
#X obj 233 240 ambi_rot 2;
#X obj 699 273 prvu~;
#X obj 700 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 719 273 prvu~;
#X obj 720 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 739 273 prvu~;
#X obj 740 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 759 273 prvu~;
#X obj 760 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 779 273 prvu~;
#X obj 780 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 1 0;
#X obj 411 257 *~ 1;
#X obj 131 436 round_zero 1e-06;
#X msg 147 343 real_ls \$1 \$2;
#X msg 131 364 begin_pseudo_inverse;
#X msg 115 385 end_pseudo_inverse;
#X obj 115 245 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 131 414 ambi_decode3 2 2 8 0;
#X msg 147 322 1 0 \, 2 45 \, 3 90 \, 4 135 \, 5 180 \, 6 225 \, 7
270 \, 8 315;
#X obj 425 381 mtx_*~ 8 5 0 ________________;
#X obj 115 264 t b b b b;
#X obj 508 75 mull~ 1 100;
#X obj 678 27 fadtodb;
#X obj 551 55 dbtorms;
#X obj 618 58 - 100;
#X obj 618 82 vsl 15 121 0 120 0 1 empty empty empty 0 -8 0 8 -260818
-1 -1 24000 1;
#X floatatom 637 80 5 0 0 0 - - -;
#N canvas 0 0 462 312 __________________________ 0;
#X obj 25 66 rvu~;
#X obj 25 86 + 100;
#X obj 25 106 dbtorms;
#X obj 25 127 outlet;
#X obj 75 66 rvu~;
#X obj 75 86 + 100;
#X obj 75 106 dbtorms;
#X obj 75 127 outlet;
#X obj 125 66 rvu~;
#X obj 125 86 + 100;
#X obj 125 106 dbtorms;
#X obj 125 127 outlet;
#X obj 175 66 rvu~;
#X obj 175 86 + 100;
#X obj 175 106 dbtorms;
#X obj 175 127 outlet;
#X obj 225 66 rvu~;
#X obj 225 86 + 100;
#X obj 225 106 dbtorms;
#X obj 225 127 outlet;
#X obj 275 66 rvu~;
#X obj 275 86 + 100;
#X obj 275 106 dbtorms;
#X obj 275 127 outlet;
#X obj 325 66 rvu~;
#X obj 325 86 + 100;
#X obj 325 106 dbtorms;
#X obj 325 127 outlet;
#X obj 375 66 rvu~;
#X obj 375 86 + 100;
#X obj 375 106 dbtorms;
#X obj 375 127 outlet;
#X obj 25 45 inlet~;
#X obj 75 45 inlet~;
#X obj 125 45 inlet~;
#X obj 175 45 inlet~;
#X obj 225 45 inlet~;
#X obj 275 45 inlet~;
#X obj 325 45 inlet~;
#X obj 375 46 inlet~;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 14 0 15 0;
#X connect 16 0 17 0;
#X connect 17 0 18 0;
#X connect 18 0 19 0;
#X connect 20 0 21 0;
#X connect 21 0 22 0;
#X connect 22 0 23 0;
#X connect 24 0 25 0;
#X connect 25 0 26 0;
#X connect 26 0 27 0;
#X connect 28 0 29 0;
#X connect 29 0 30 0;
#X connect 30 0 31 0;
#X connect 32 0 0 0;
#X connect 33 0 4 0;
#X connect 34 0 8 0;
#X connect 35 0 12 0;
#X connect 36 0 16 0;
#X connect 37 0 20 0;
#X connect 38 0 24 0;
#X connect 39 0 28 0;
#X restore 425 406 pd __________________________;
#X obj 459 490 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 486 460 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 486 528 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 516 450 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 516 538 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 546 460 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 546 528 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 573 490 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X msg 310 58 ambi_weight 1 1 1;
#X msg 164 299 ambi_weight 1 1 0.3904;
#X msg 89 466 ambi_weight 1 1 1;
#X text 388 509 +90 degree;
#X text 601 506 -90 degree;
#X text 486 602 +-180 degree;
#X obj 234 220 cnv 12 30 12 empty empty empty 20 12 0 14 -260818 -66577
0;
#X obj 231 32 cnv 12 30 12 empty empty empty 20 12 0 14 -260818 -66577
0;
#X floatatom 230 31 5 -180 180 0 - - -;
#X text 232 14 phi;
#X floatatom 233 219 5 -180 180 0 - - -;
#X text 231 201 rho_z;
#X obj 264 213 cnv 8 8 8 empty empty empty 20 12 0 14 -262144 -66577
0;
#X obj 260 24 cnv 8 8 8 empty empty empty 20 12 0 14 -262144 -66577
0;
#X text 341 114 ENCODING;
#X text 309 378 DECODING;
#X text 323 257 ROTATING;
#X text 587 90 gain;
#X text 24 119 iemmatrix \, iem_ambi \, iemgui;
#X text 17 108 we need iemlib1 \, iemlib2 \,;
#X text 78 596 IEM KUG;
#X text 62 584 musil;
#X text 92 584 @;
#X text 98 584 iem.at;
#X text 61 606 Graz \, Austria;
#X text 13 573 (c) Thomas Musil 2000 - 2006;
#X obj 182 647 declare -stdlib /home/amir/Documents/Pd/externals/iem_ambi
-stdlib /home/amir/Documents/Pd/externals/iemmatrix -stdlib /home/amir/Documents/Pd/externals/iemlib
-stdlib /home/amir/Documents/Pd/externals/zexy -stdlib /home/amir/Documents/Pd/externals/iemgui
;
#X connect 0 0 2 0;
#X connect 0 1 3 0;
#X connect 1 0 0 0;
#X connect 4 0 11 0;
#X connect 5 0 12 0;
#X connect 5 0 36 0;
#X connect 5 1 14 0;
#X connect 5 1 23 1;
#X connect 5 2 16 0;
#X connect 5 2 23 2;
#X connect 5 3 18 0;
#X connect 5 3 24 1;
#X connect 5 4 20 0;
#X connect 5 4 24 2;
#X connect 6 0 7 0;
#X connect 7 0 46 0;
#X connect 9 0 5 0;
#X connect 10 0 4 0;
#X connect 11 0 9 0;
#X connect 11 1 9 0;
#X connect 12 0 13 0;
#X connect 14 0 15 0;
#X connect 16 0 17 0;
#X connect 18 0 19 0;
#X connect 20 0 21 0;
#X connect 22 0 41 0;
#X connect 23 0 28 0;
#X connect 23 0 44 2;
#X connect 23 1 30 0;
#X connect 23 1 44 3;
#X connect 24 0 32 0;
#X connect 24 0 44 4;
#X connect 24 1 34 0;
#X connect 24 1 44 5;
#X connect 25 0 23 0;
#X connect 25 1 24 0;
#X connect 26 0 27 0;
#X connect 28 0 29 0;
#X connect 30 0 31 0;
#X connect 32 0 33 0;
#X connect 34 0 35 0;
#X connect 36 0 26 0;
#X connect 36 0 44 1;
#X connect 37 0 44 0;
#X connect 38 0 42 0;
#X connect 39 0 42 0;
#X connect 40 0 42 0;
#X connect 41 0 45 0;
#X connect 42 0 37 0;
#X connect 43 0 38 0;
#X connect 44 0 52 0;
#X connect 44 1 52 1;
#X connect 44 2 52 2;
#X connect 44 3 52 3;
#X connect 44 4 52 4;
#X connect 44 5 52 5;
#X connect 44 6 52 6;
#X connect 44 7 52 7;
#X connect 45 0 40 0;
#X connect 45 1 39 0;
#X connect 45 2 43 0;
#X connect 45 3 62 0;
#X connect 46 0 5 1;
#X connect 47 0 48 0;
#X connect 47 0 49 0;
#X connect 48 0 46 1;
#X connect 49 0 51 0;
#X connect 50 0 47 0;
#X connect 52 0 56 0;
#X connect 52 1 54 0;
#X connect 52 2 53 0;
#X connect 52 3 55 0;
#X connect 52 4 57 0;
#X connect 52 5 59 0;
#X connect 52 6 60 0;
#X connect 52 7 58 0;
#X connect 61 0 4 0;
#X connect 62 0 42 0;
#X connect 63 0 42 0;
#X connect 69 0 10 0;
#X connect 71 0 25 0;
playing multiple videos with pd
@KMETE said:
I'm not sure what you mean by load. I did update my pd search path and indeed it founds the object [gemwin] but I think there is more objects inside it that it could not find
Something that is poorly explained in Pd documentation is that there are different types of externals.
-
Some "external" objects are really abstractions (Pd patches that are loaded like objects into your patch). For these, it's enough to make them available in the search path.
-
Some externals need C / C++ binaries. Some of those ship a separate binary library for every object -- e.g. the ELSE library has multiple "bl.saw~.xxx" files, and multiple "bl.square~.xxx" files etc. For this type of external, the search path is enough.
-
Some externals package multiple objects' C / C++ code into one big binary DLL. On my machine, if I go to the Gem folder, I can find "Gem.pd_linux." On other OSes, this would be .pd_somethingElse depending on the OS.
For this last type of external library, it is not enough to put it in the search path. You must explicitly load the library. If you don't load the library, then any objects defined in the big binary package will not work. (Some Gem objects are abstractions -- these are found in your search path. But inside those abstractions are binary objects, and those are not loading successfully because you haven't loaded the library file yet.)
You can do this in Preferences > Startup.
But I personally don't put any specific libraries into either the search path or Startup, because of issues moving patches to other machines. I prefer to put only Documents/Pd/externals into my search path, and then use [declare].
[declare -lib Gem -path else -path list-abs]
Should this be easier and more transparent? Yes... but it's not.
hjh
ofelia on raspberry pi?
Hi,
I am trying to get ofelia to run on a couple of rpi. Right now I am trying a rpi 3B+ running https://blokas.io/patchbox-os/
I run ofeila with the ofelia-fast-prototyping abs on my mac successfully.
Following install instructions here https://github.com/cuinjune/Ofelia
after running
sudo ./install_dependencies.sh
it ends like this:
detected Raspberry Pi
installing gstreamer omx
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
gstreamer1.0-omx is already the newest version (1.0.0.1-0+rpi12+jessiepmg).
The following package was automatically installed and is no longer required:
raspinfo
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Updating ofxOpenCV to use openCV4
sed: can't read /home/patch/Documents/Pd/externals/addons/ofxOpenCv/addon_config.mk: No such file or directory
sed: can't read /home/patch/Documents/Pd/externals/addons/ofxOpenCv/addon_config.mk: No such file or directory
When running the example patches in Pd I get this in PD console:
opened alsa MIDI client 130 in:1 out:1
JACK: cannot connect input ports system:midi_capture_1 -> pure_data:input_2
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia f ;
ofBackground(20) ;
ofSetSmoothLighting(true) ;
ofSetSphereResolution(24) ;
local width , height = ofGetWidth() * 0.12 , ofGetHeight() * 0.12 ;
sphere = ofSpherePrimitive() ;
sphere:setRadius(width) ;
icoSphere = ofIcoSpherePrimitive() ;
icoSphere:setRadius(width) ;
plane = ofPlanePrimitive() ;
plane:set(width * 1.5 , height * 1.5) ;
cylinder = ofCylinderPrimitive() ;
cylinder:set(width * 0.7 , height * 2.2) ;
cone = ofConePrimitive() ;
cone:set(width * 0.75 , height * 2.2) ;
box = ofBoxPrimitive() ;
box:set(width * 1.25) ;
local screenWidth , screenHeight = ofGetWidth() , ofGetHeight() ;
plane:setPosition(screenWidth * 0.2 , screenHeight * 0.25 , 0) ;
box:setPosition(screenWidth * 0.5 , screenHeight * 0.25 , 0) ;
sphere:setPosition(screenWidth * 0.8 , screenHeight * 0.25 , 0) ;
icoSphere:setPosition(screenWidth * 0.2 , screenHeight * 0.75 , 0) ;
cylinder:setPosition(screenWidth * 0.5 , screenHeight * 0.75 , 0) ;
cone:setPosition(screenWidth * 0.8 , screenHeight * 0.75 , 0) ;
pointLight = ofLight() ;
pointLight:setPointLight() ;
pointLight:setDiffuseColor(ofFloatColor(0.85 , 0.85 , 0.55)) ;
pointLight:setSpecularColor(ofFloatColor(1 , 1 , 1)) ;
pointLight2 = ofLight() ;
pointLight2:setPointLight() ;
pointLight2:setDiffuseColor(ofFloatColor(238 / 255 , 57 / 255 , 135 / 255)) ;
pointLight2:setSpecularColor(ofFloatColor(0.8 , 0.8 , 0.9)) ;
pointLight3 = ofLight() ;
pointLight3:setPointLight() ;
pointLight3:setDiffuseColor(ofFloatColor(19 / 255 , 94 / 255 , 77 / 255)) ;
pointLight3:setSpecularColor(ofFloatColor(18 / 255 , 150 / 255 , 135 / 255)) ;
material = ofMaterial() ;
material:setShininess(120) ;
material:setSpecularColor(ofFloatColor(1 , 1 , 1)) ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia f ;
pointLight = nil ;
pointLight2 = nil ;
pointLight3 = nil ;
collectgarbage() ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia f ;
local width , height , time = ofGetWidth() , ofGetHeight() , ofGetElapsedTimef() ;
pointLight:setPosition((width * 0.5) + math.cos(time * 0.5) * (width * 0.3) , height / 2 , 500) ;
pointLight2:setPosition((width * 0.5) + math.cos(time * 0.15) * (width * 0.3) , height * 0.5 + math.sin(time * 0.7) * height , -300) ;
pointLight3:setPosition(math.cos(time * 1.5) * width * 0.5 , math.sin(time * 1.5) * width * 0.5 , math.cos(time * 0.2) * width) ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
ofelia f ;
local spinX = math.sin(ofGetElapsedTimef() * 0.35) ;
local spinY = math.cos(ofGetElapsedTimef() * 0.075) ;
ofEnableDepthTest() ;
ofEnableLighting() ;
pointLight:enable() ;
pointLight2:enable() ;
pointLight3:enable() ;
material:beginMaterial() ;
plane:rotateDeg(spinX , 1 , 0 , 0) ;
plane:rotateDeg(spinY , 0 , 1 , 0) ;
plane:draw() ;
box:rotateDeg(spinX , 1 , 0 , 0) ;
box:rotateDeg(spinY , 0 , 1 , 0) ;
box:draw() ;
sphere:rotateDeg(spinX , 1 , 0 , 0) ;
sphere:rotateDeg(spinY , 0 , 1 , 0) ;
sphere:draw() ;
icoSphere:rotateDeg(spinX , 1 , 0 , 0) ;
icoSphere:rotateDeg(spinY , 0 , 1 , 0) ;
icoSphere:draw() ;
cylinder:rotateDeg(spinX , 1 , 0 , 0) ;
cylinder:rotateDeg(spinY , 0 , 1 , 0) ;
cylinder:draw() ;
cone:rotateDeg(spinX , 1 , 0 , 0) ;
cone:rotateDeg(spinY , 0 , 1 , 0) ;
cone:draw() ;
material:endMaterial() ;
ofDisableLighting() ;
ofDisableDepthTest() ;
... couldn't create
Thankful for help!
Finding a .dylib required by externals
I'm running Pd-0.52-2 on MacOS Monterey (12.6) and having trouble with externals that I created. When developing/debugging, everything is fine. I have 4 externals with extensions .pd_darwin, each dependent upon a DLL named libo2pd.dylib. With everything in ~/Documents/Pd/externals/, I can start my locally compiled pd-0.52-2.app, and everything works. But if I run a downloaded /Applications/Pd-052-2.app and try to create one of these external objects, I get the message:
/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin: dlopen(/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin, 0x000A): Library not loaded: 'libo2pd.dylib'
Referenced from: '/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin'
Reason: tried: 'libo2pd.dylib' (relative path not allowed in hardened program), '/usr/lib/libo2pd.dylib' (no such file)
o2ensemble o2global
... couldn't create
I get the same results running from the command line, and running from the directory with the .dylib and externals does not make any difference. Note that /usr/lib is protected even using sudo, so even if I could install libo2pd.dylib there, I don't think it's an acceptable solution.
I suspect this problem stems from Apple security policies, but I don't know how Pd searches for .dylibs and there's a lot of ambiguity in documentation and discussions since "libraries" and "paths" are used in multiple ways. I also tried setting LD_LIBRARY_PATH and running from the command line, but that didn't work.
Does anyone know to set up Pd for an external that depends on a DLL?
Some patches won't open. (was: Why Vanilla fails at reading some Purr Data patches?)
@lacuna said:
So these patches starting with
#N canvas 2802 562 675 300 12;
or
#N canvas 785 1198 794 777 12;
appear blank.
If (I'm guessing) the canvas parameters are "left-X top-Y width height" (and I guess 12 is a zoom factor but I'm not sure), then X = 2802 is very, very far to the right, and 1198 is very, very far down. On my laptop, I've got 1366x768; a window positioned 2802 pixels away from screen left would far, far out of bounds.
The window manager that I use in Linux will "fix" offscreen window coordinates, so when I open the js-help patch, it appears flush against the right and bottom screen borders. The stated coordinates are out of bounds on my system; the window manager shifts them to be on screen. The problem is technically there, but masked by the window manager.
I have seen Windows not adjust out of bounds window coordinates -- i.e., open a subpatch within a student's patch, and couldn't see the window at all.
I'm not 100% certain that's the problem here -- but I'll observe that the action you took, which resolved the problem, was to change the upper-left window coordinates to be much closer to the top left of the screen.
hjh
fx3000~: 30 effect abstraction for use with guitar stompboxes effects racks, etc.
It still does not work.
I added my-guitar-rig/my-guitar-rig~
to a window and it generated a lot of errors
I am running version 0.52.1 of pd
Hopefully this is helpful. The errors I got are:
z~ 64
... couldn't create
limiter~ 98 1
... couldn't create
io pair already connected
delay(wavey)(v).pd 39 0 40 0 (snapshot~->gatom) connection failed
tof/pmenu 1 1 black white red
... couldn't create
tof/pmenu 1 1 black white red
... couldn't create
z~ 64
... couldn't create
limiter~ 98 1
... couldn't create
io pair already connected
delay(wavey)(v).pd 39 0 40 0 (snapshot~->gatom) connection failed
tof/pmenu 1 1 black white red
... couldn't create
tof/pmenu 1 1 black white red
... couldn't create
z~ 64
... couldn't create
limiter~ 98 1
... couldn't create
io pair already connected
delay(wavey)(v).pd 39 0 40 0 (snapshot~->gatom) connection failed
tof/pmenu 1 1 black white red
... couldn't create
tof/pmenu 1 1 black white red
... couldn't create
z~ 64
... couldn't create
limiter~ 98 1
... couldn't create
date
... couldn't create
time
... couldn't create
z~ 64
... couldn't create
limiter~ 98 1
... couldn't create
mknob 42 0 0 1 0 0 empty empty ratio:1.5:1 -2 -6 0 10 -262144 -1 -1 20175 1
... couldn't create
tof/pmenu 1 1 black white red
... couldn't create
pd-float: rounding to 2048 points
warning: fx3000-in-2: multiply defined
warning: fx3000-in-2: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-0: multiply defined
warning: fx3000-in-0: multiply defined
pd-float: rounding to 2048 points
pd-float: rounding to 2048 points
warning: fx3000-in-2: multiply defined
warning: fx3000-in-2: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-0: multiply defined
warning: fx3000-in-0: multiply defined
pd-float: rounding to 2048 points
pd-float: rounding to 2048 points
warning: fx3000-in-2: multiply defined
warning: fx3000-in-2: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-1: multiply defined
warning: fx3000-in-0: multiply defined
warning: fx3000-in-0: multiply defined
pd-float: rounding to 2048 points
Why does Pd look so much worse on linux/windows than in macOS?
@ddw_music said:
I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon.
I think most people agree with you, myself included. Tk is clunky but it's in the current code base and has been kept so far since it works, although admittedly barely in many cases.
The last couple of posts here are encouraging.
I know development is slow, but it's really working against inertia. Momentum has been growing the last years and that's mostly due to more effective collaboration to tackle some of these issues. I think finding a sustainable approach to the GUI is one of the largest ones, so is taking a while to grow.
IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.
Nope. See above.
Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)
Yup, you are totally right. I didn't mean to imply the Linux screenshot looked good since "that's the way it is" just more that it looks so much better on macOS since the screenshot is likely double the resolution as well.
I started using Pd on Windows circa 2006 then jumped to Linux for many years, then to macOS. My feeling was that Pd worked best on Linux but a lot of that has caught up as the underlying systems have developed but in some ways the Linux desktop has not (for many reasons, good and bad).
- Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.
I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).
That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.
I'm happy to download the deken GEM package because I know the IEM people have done all the craziness to build it (it's a small nightmare of autotools/makefiles due to the amount of plugins and configuration options). I am also very happy to not have to build it and provide it to other users but in exchange we ask people to do that extra step and use deken. I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners. There are some thoughts of improving it and feedback for people in the teaching environment has also pushed certain solutions (ie. Pd Documents folder, etc).
Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.
By "tracking" I am referring to a fork following the new developments in Pd-vanilla and integrating the changes. This becomes harder if/when the forks deviate with internal changes to the source code, so merging some changes then has to be done "by hand" which slows things down and is one reason why a fork may release a new version but be perhaps 1 or two versions behind Pd vanilla's internal objects, ie. new [soundfiler] right outlet, [clone] object, new [file] object, etc.
- As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.
I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...
Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.
Hah yeah, I totally understand. My first contribution to Pd(-extended) was to find out how to disable showing hidden files in the open/save panels on Linux. You would open a dialog, it defaulted to $HOME
, then you had to wade through 100 dot folders. Terrible! Who did this and why? Well it wasn't on purpose, it was just the default setting for panels on Tk, and I added a little but of Tcl to turn it off and show a "Show hidden files/folders" button below.
OTOH I have a colleague at work who's internal toolkit still uses Motif. Why? Well it still works and he's the only user so he's ok with it. I'd say that Tk also still uses Motif... but there are many users and they have much different expectations. ;P
Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled).
Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.
"Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.
Another approach would be to try to bring improvements to Tcl/Tk itself but the dev community is a little opaque, more so than Pd. However I admit to not having put a ton of time into it, other than flagging our custom patches to the TK macOS guy on Github.
WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.
As would I... we are preparing for a major exhibition opening in December, but I will have some time off after and I may take a stab at a technical demo for this (among other things) then pull in some other perspectives / testers. It has been an itch I have wanted to scratch since, at least Pd Con 2016 in NYC.
Why does Pd look so much worse on linux/windows than in macOS?
Howdy all,
I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.
I'm just writing for myself and don't speak for Miller or anyone else.
Mac looks good
The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.
There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."
In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.
This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.
IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.
Nope. See above.
It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.
Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.
tkpath exists, why not use it?
Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.
And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.
It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.
Why aren't the fonts all the same yet?!
I also despise how linux/windows has 'bold' for default
I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.
Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?
And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.
Why don't we add abz, 123 to Pd? xyzzy already has it?!
What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.
Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.
For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.
Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.
I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.
I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.
This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.
I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).
A couple of points:
-
Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.
-
As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.
I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.
A way forward: libpd?
I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."
For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."
So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).
Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.
Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.
Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...
Discouraging Initiative?!
But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.
IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.
We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.
At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.
This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.
That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.
Out
Ok, that was long and rambly and it's way past my bed time.
Good night all.
GEM / Catalina
Hello. I can't get GEM to work on MacOS Catalina (10.15.4). I installed using Help > Find Externals. Here're the errors I get. . . .
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
GEM: Graphics Environment for Multimedia
GEM: ver: 0.94.git v0.94_pre1
GEM: compiled on Dec 21 2018
GEM: maintained by IOhannes m zmoelnig
GEM: Authors : Mark Danks (original version)
GEM: Chris Clepper
GEM: Cyrille Henry
GEM: IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM: homepage https://gem.iem.at/
GEM: bug-tracker https://bugs.gem.iem.at/
GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/
GEM: binary/abstractions version mismatch!
GEM: continue at your own risk...
GEM: compiled for MMX/SSE2 architecture
GEM: using SSE2 optimization
GEM: detected 8 CPUs
GEM: image loading support: magick SGI imageIO jpeg tiff
GEM: image saving support: SGI imageIO jpeg magick tiff
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
gemcocoawindow
... couldn't create
Pd FLOSS Manual, what to do with it?
@60hz said:
So what I see is that pd-vanilla and his minimal gui with computer scientists oriented documentation is not suited for newcomers and artist but purr-data is. So that should make sense that flossmanuals should have a documentation about it.
It makes sense and we're saying Purr Data can have its own Floss manuals, but what are you talking about, a new entry or turning the current Floss Manuals into a Purr Data Manual?
By the way, the point of updating this Floss manuals to Vanilla is to make its documentation and itself more suited for newcomers, the solution to the exact problem you're raising it won't change if we don't do anything about it and if efforts to change it are rejected.
Folks, when I started this thread, I made no mention to Purr Data. Purr Data is something else. I get the confusion, I get the relation, it's not out of purpose to bring this up here, but I want to make things clear.
See, we're talking about a Manual, a so called "Pure Data" manual, which actually mixed the notion of Pd itself and Pd Extended (now dead) and sits around still as a "Pure Data" manual. While Pd itself has also its 'official' manual. That's all very confusing already, right? The point is then to fix this, work on the Pure Data documentation itself (it's all in the original post). Purr Data relates to Pd and Extended but it's a whole different animal. It has different configurations, interface, features and whatnot. More over, it has quite strong incompatibilities that people don't seem to bring up. When you have a so called Pure Data manual talking now about 'Purr Data' actually, things get even more confusing, we're adding more noise.
What's also confusing is the mixed notion of a 'Software Manual' and a 'Tutorial'. These are supposed to be distinct things. And tutorials are free to focus on different things. Floss seems to be a tutorial on how to do some stuff in Pd, not a 'real software manual' at all. Floss also seems to be good to talk about some externals for Pd. Cool... we could update it then and keep it mostly the same. The changes would be minimal. We'd have a good section on how to manage externals in Pd Vanilla theses days. That'd be great, right? How to configure, etc...
If you're saying, "but hey, I think most of the tutorial examples would work on Purr Data, as they already ship the externals we're talking about, cause they were originally based in Extended", fine! Cool! Great, we can see if what we have in the end perfectly suits being just implemented, opened, and used in Purr Data as well. I'm not talking about the configuration part and things like that, just running the patches...
If it's all fine we can just say "hey, the things you see here are also suited if you want to run Purr Data"
How about it?
Note: On the other side, I prefer using pd-ceammc libraries which are organized AND replace all pd-extended and more, so the best would be having Purr Data + ceammc lib and the peace would come back on earth...
They do not, by far, replace "all pd-extended", nope, sorry, not a fact. Where's ceammc's GEM replacement for instance?
And what are you suggesting with "Purr Data + ceammc lib"? A Floss manuals for both?
And are you talking about the ceammc library that you can install directly from vanilla and use it as part of vanilla or the 'Pd-ceammc' fork of Pd, that comes with the ceammc library and some more stuff?
Well... everything I said about "hey what about Purr Data?" applies here. And the fact is that Pd-ceammc, unlike Purr Data, is not a "whole different animal", it's pretty much just another 'race' of Pd. It is 100% compatible to Pd-Vanilla (unlike Purr Data). the changes are minimal. You can, for example, run Deken and install externals in Pd-ceammc.
If you don't want to bother using something else than Vanilla, you can install the ceammc library in Vanilla and just use most of what ceammc offers anyway. It's all compatible.
So any Pure Data Manual, Floss manual, tutorial, will work great for Pd-ceammc. And if we consider the fact that a Manual for Purr is needed (not a tutorial, a 'manual', a 'software manual') since it's just too different. That doesn't hold for Pd-ceammc.
And yeah, when I say Purr Data is highly incompatible, you can't run any of the GUI objects from Pd-ceammc in Purr Data. You can't run other GUIs from other libraries.
In fact, Purr Data doesn't even have all of the GUI externals from extended ported and running. Also, Purr Data misses updates from cyclone. Purr is also not doing a great job keeping up to the latest vanilla changes and has some changes of their own to vanilla things. So, unlike Extended and Vanilla, it's really hard tying them with a knot. Unfortunately, at least to me, the community is divided. There are independent developments. And it's hard to manage this, hence the talk about creating a whole new FLOSS for them if needed.
If Purr Data were in fact a reincarnation of Extended, fine. But that's not quite it. And here's something people don't really seem to be aware is that the best shot to have an updated external library that runs all extended patches is going to be "Vanilla + install externals yourself"
And there's also the fact that there are more libraries than just the extended libraries out there, and you can also get them into Vanilla. Like ceammc, like timbreid, like soundhack, like ELSE, like many many others that are just missing, not compatible or hard to get into Purr.
So, there's a way to have both Pd-ceamm + Purr Data when it comes to the externals - get them all for vanilla!
Sure, you'll miss the interface differences from Purr and maybe I don't know what. But that's it, and it needs to be clear what the choice is, there's also a sacrifice in giving up Vanilla.