Fresh Pd 0.50.2 install comes with broken libs and deken installs broken libs
ok, so I found time to compile Pd, 0.51.2, and I think now I understand my problem was twofold.
Pd compiles fine and all libraries in /extra works fine now.
So the fact that those same libraries installed by the public package were broken could point to issues with the package itself, as @oid suggested.
The other issue with the libraries installed via deken. Well, on one hand is my bad: those broken libraries I had installed were not technically broken, but simply compiled for AMD64_32 which is a different architecture than my machine (which is 64-bit). I had installed the 32-bit version without even checking what it was, I assumed the most recent deken package would be compiled for all platforms, but apparently this is not the case.
Which leads to my other question: I find it strange that those very common pd libs are not compiled for 64-bit platforms?
Anyway, issue is not entirely solved, but at least I understand now what has happened.
Crackled Audio from PD on Raspberry Pi 4
@EEight said:
@tiemget How do you start pd (show us the command line)
Welcome to Purr Data
nw.js version 0.24.5
Pd has started the GUI
canvasinfo: v0.1
stable canvasinfo methods: args dir dirty editmode vis
classinfo: v.0.1
stable classinfo methods: size
objectinfo: v.0.1
stable objectinfo methods: class
pdinfo: v.0.1
stable pdinfo methods: dir dsp version
[import] $Revision: 1.2 $
[import] is still in development, the interface could change!
compiled against Pd-l2ork version 2.14.2 (20200922-rev.c4495143)
PD_FLOATSIZE = 32 bits
working directory is /home/pi
libdir loader 1.10
compiled on Sep 22 2020 at 18:05:09
compiled against Pd version 0.48.0.
libdir_loader: added 'Gem' to the global objectclass path
libdir_loader: added 'cyclone' to the global objectclass path
libdir_loader: added 'zexy' to the global objectclass path
libdir_loader: added 'creb' to the global objectclass path
libdir_loader: added 'cxc' to the global objectclass path
libdir_loader: added 'iemlib' to the global objectclass path
libdir_loader: added 'mapping' to the global objectclass path
libdir_loader: added 'markex' to the global objectclass path
libdir_loader: added 'maxlib' to the global objectclass path
libdir_loader: added 'memento' to the global objectclass path
libdir_loader: added 'mjlib' to the global objectclass path
libdir_loader: added 'motex' to the global objectclass path
libdir_loader: added 'oscx' to the global objectclass path
libdir_loader: added 'pddp' to the global objectclass path
libdir_loader: added 'pdogg' to the global objectclass path
libdir_loader: added 'pixeltango' to the global objectclass path
libdir_loader: added 'rradical' to the global objectclass path
libdir_loader: added 'sigpack' to the global objectclass path
libdir_loader: added 'smlib' to the global objectclass path
libdir_loader: added 'unauthorized' to the global objectclass path
vbap - v1.1 - 14 Aug. 2014 - (c) Ville Pulkki 1999-2006 (Pd port by HCS)
libdir_loader: added 'pan' to the global objectclass path
freeverb~ v1.2
libdir_loader: added 'hcs' to the global objectclass path
libdir_loader: added 'jmmmp' to the global objectclass path
libdir_loader: added 'ext13' to the global objectclass path
libdir_loader: added 'ggee' to the global objectclass path
libdir_loader: added 'ekext' to the global objectclass path
libdir_loader: added 'disis' to the global objectclass path
libdir_loader: added 'lyonpotpourri' to the global objectclass path
pdlua 0.10.1 (GPL) 2014-2020 Martin Peach et al., based on
lua 0.6~svn (GPL) 2008 Claude Heiland-Allen <claude@mathr.co.uk>
pdlua: compiled for pd-0.48 on Sep 22 2020 18:05:09
Using lua version 5.3
pdlua: using JavaScript interface (Pd-l2ork nw.js version)
error: audio I/O stuck... closing audio
There you go.
ext13 on Raspberry PI
We want to stream audio from a Windows PC to a Raspberry PI over the network. First we tried to install ext13 with the External Manager on the PI but it has not worked, because there is no compiled version of ext13 for the ARM-Architecture the Raspberry PI uses. So we compiled ext13 on the PI accordingly to the README in the ext13 folder. Now we can create the streamin13~ object but nothing happens. Neither sound nor a error message. Have we forget something during compiling? In the README you can read that you have to put the compiled files to the pd directory. But where to put them exactly?
I hope someone can help us.
Optimizing pd performances to fit an RPI 3
This is Pure Data that needs to be compiled with -fno-omit-frame-pointer
flag.
< http://www.brendangregg.com/blog/2014-06-22/perf-cpu-sample.html >
Incomplete stacks usually mean -fomit-frame-pointer was used – a compiler optimization that makes little positive difference in the real world, but breaks stack profilers. Always compile with -fno-omit-frame-pointer. More recent perf has a -g dwarf option, to use the alternate libunwind/dwarf method for retrieving stacks.
And AFAIK Pure Data is compiled without < https://github.com/pure-data/pure-data/blob/f22d621e5c595572179cdd2aa51eab032b964240/configure.ac#L36 >.
Camomile with editable labels / guis and xy-slider
Yeah, thanks -- it looks like my system isn't setup to compile VSTs correctly. Before I moved to Debian I was using Ubuntu Studio, and was never able to compile Camomile correctly there, but the 0.0.6 binary files (basically the contents of the Plugins folder) were available instead -- and that install does fine with LV2 plugins.
When I looked at the vst files from my own plugins, they also show "plugin not valid" on load (but they don't crash anything).
So I removed the .so file from your zip (and the bkgnd image ref), generated an LV2 and that works fine in Carla:
So yeah! Most of the features in vanilla work really well in Camomile, including those display hooks. Actually, one of the first plugins I wrote was to simply package the "extra" reverb patch, [rev3~] :
One more thing -- thanks to your git fork (and the more detailed instructions in Pierre Guillot's 0.0.7 src), I was able to compile Camomile and all the submodules correctly today. VSTs still won't compile, but I feel much farther along!
Replacement for [list]?
Hi, if I have a patch that contains [list], is there anything that I can substitute it with, that does exactly the same thing?
I've been having quite a bit of fun with the rj library (https://puredata.info/downloads/rjlib), but have found some patches like u_highpassq contain the use of [list] inside them. Normally this wouldn't be a problem, but I kind of need to be able to compile my patch using the heavy compiler (https://github.com/enzienaudio/hvcc), and the heavy compiler does not support [list] for some strange reason.
The reason I kind of need to use the heavy compiler is because that's what https://www.rebeltech.org/patch-library/ uses. I have one of their devices, and I want to load a patch onto it that contains the high pass filter mentioned previously.
Alternatively, if anyone knows of a good vanilla (not extended) resonant low pass / resonant high pass filter patch that I could use instead of the rj one then that'd be great. I'm surprised pd doesn't have something like this in vanilla by default. Thanks
Purr Data 2.10.0 released
Purr Data 2.10.0 is now available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.10.0
Changes:
- iem_spec2/spec2_tabreceive_enable~: fix array error handler and set sane default array name value
- fix partconv crashers in bsaylor lib and add perfroutine for array errors
- adaptive/nlms3~: fix typo that caused a double free
- fix lyonpotpourri crashers in dsp, perform and constructor routines
- at least keep the inoperable streamout13~ and streamin13~ from crashing when instantiating
- use some sane default values in ekext/lpreson~ to prevent segfault
- quick fixes to keep cxc/mean~ from crashing when dsp is turned on
- greatly reduce undefined behavior in all dsp objects
- fix hex2dec so that it actually does something useful
- fix #523: crash with manual width adjustment on subpatch
- add ability to change makefile flags for Gem from toplevel makefile
- fix stray bugs detected by obs
- unauthorized/cooled~: increase string buffer size to accommodate the terminating nul character
- unauthorized/cooled~: fix memory access bug trying to concatenate into a string constant
- iemmatrix/mtx_dispersive_dline: add missing void return type
- allow make options like -j8 to be passed to the Gem compilation, which takes awfully long on a single cpu.
- cxc/cxc_split: fix use of un-initialized pointer
- ggee/serial_bird: fix undefined behavior with the ++ operator
- ext13/scramble~: fix header for scramble~
- jasch_lib/detox/detox: reformat for sanity's sake, fix array overflow, undefined behavior
- linux desktop: remove the -rt -audiobuf options from the desktop files.
- linux desktop: change DEFAULTADVANCE to 20 ms for Linux.
- linux desktop: remove leftover TargetEnvironment=Unity lines in menu entries for Purr Data
- linux desktop: add some comments and a few more useful desktop action examples to the main desktop file, so that the user understands how to adjust these if needed.
- linux desktop: replace pd-gui -> nw in the ForceQuit actions, which is the proper name of the GUI program on Linux
- linux desktop: remove useless %U arguments from desktop actions.
- linux desktop: invoke desktop actions via /bin/sh.
- linux desktop: migrate the desktop actions from the ancient Unity syntax to the current freedesktop.org standard
- linux desktop: remove sticky options from the desktop files. For now, keep -rt -audiobuf 20.
- Gem: sync with https://github.com/umlaeute/Gem, QT4L and startup issues have been fixed
- linux: fix the Debian control files once again, since the dependency auto-detection needs a Depends line in there.
- debuild: Support for ARM (e.g., Raspbian)
- update nw-update to nw.js 0.24.4 to fix font issues under Linux
- backport 'add-to-path' from vanilla rev. c917dd19, to make Gem happy.
- usability improvements in the documentation browser.
- switch Gem to the latest from upstream.
- add missing dlls for fluid~ on Windows. Fixes #540.
- Debian packaging: Demote python and fluid-soundfont dependencies, as suggested in #540.
- polish the externals/Makefile clean targets, and delete redundant files in repo
- fix compile options for Xcode 10 - fftease and lyonpotpourri externals.
- update pd-lua to latest upstream.
- fix compile options for Xcode 10 - externals and abstractions.
- fix compile options for Xcode 10.
- ios header needs to be included before base64.h, to avoid compile errors on macOS 10.14.
- fix improper string access in pd_getdirname on Mac.
- fix list cat crasher, update help patch, add missing test abstractions
- get rid of obsolete and unneeded unicap and sndobj dependencies on Linux.
- mark some globals as extern to fix compilation if g_canvas.h is included more than once
Please report bugs here:
The miniwoog
@whale-av Tried to copy all the externals from ye 'olde source code from Pd-extended to my own installation dir of Pd. That got rid of some errors. But some errors about " | " stayed. That's strange because that's a Vanilla logical operator.
Then I tried to compile ye 'olde source code from Pd-extended from source code. Got some error about pthread_create@@GLIBC
Maybe because pthread does not work anymore in modern C compilers? The current source code compiled without problems on my PC.
Anyway, I was about to give up and then I tried to install an old Linux Mint package (i.e. pre-compiled software). This luckily installed just fine. And guess what? The Moog patch works excellent.
There is a downside to all this, however. It's a shame that de kind developers of Pd make a version that does not work w/ our beloved patches anymore. Not even when you use the 'Find Externals' utility. And not even when you copy all the old Pd-extended externals to your current externals directory. A shame that ll that work on great patches from a few years ago go to waste.
Does anybody know how to compile the old Pd-extended on a mdern Linux system?
Now for that Pd-extended on a Raspberry Pi....
First bootup problems
Hey guys,
A quick search on the forums did not reveal a straightforward answer for how to deal with my bootup problem. I'm a big noob, with no programming experience, and I'm trying to get Purr Data to bootup on my busted old Linux Mint laptop. I'm using pd 2.8.1, and Mint 18. I have JACK on my computer, but I'm pretty sure everything is running through ALSA. Anyway, first bootup of PD looked like this:
Welcome to Purr Data
warning: your system's font stack is not optimal
Pd has started the GUI
canvasinfo: v0.1
stable canvasinfo methods: args dir dirty editmode vis
pdinfo: v.0.1
stable pdinfo methods: dir dsp version
classinfo: v.0.1
stable classinfo methods: size
objectinfo: v.0.1
stable objectinfo methods: class
[import] $Revision: 1.2 $
[import] is still in development, the interface could change!
compiled against Pd-l2ork version 2.8.1 (20190207-rev.e216f5a)
PD_FLOATSIZE = 32 bits
sys_nmidiin 1, nmidiindev 0
working directory is /home/jjwitte
Opened Alsa Client 128 in:1 out:1
libdir loader 1.10
compiled on Feb 7 2019 at 19:29:50
compiled against Pd version 0.48.0.
GEM: Graphics Environment for Multimedia
verbose( -1):GEM: ver: 0.93.git 438dab3
verbose( -1):GEM: compiled: Feb 7 2019
verbose( -1):GEM: maintained by IOhannes m zmoelnig
verbose( -1):GEM: Authors : Mark Danks (original version)
verbose( -1):GEM: Chris Clepper
verbose( -1):GEM: Cyrille Henry
verbose( -1):GEM: IOhannes m zmoelnig
verbose( -1):GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al.
verbose( -1):GEM: found a bug? miss a feature? please report it:
verbose( -1):GEM: homepage http://gem.iem.at/
verbose( -1):GEM: bug-tracker http://sourceforge.net/projects/pd-gem/
verbose( -1):GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/
verbose( -1):GEM: compiled for MMX/SSE2 architecture
verbose( -1):GEM: using SSE2 optimization
verbose( -1):GEM: detected 4 CPUs
GEM: image loading support: magick SGI jpeg tiff
GEM: image saving support: jpeg magick tiff
libdir_loader: added 'cyclone' to the global objectclass path
libdir_loader: added 'zexy' to the global objectclass path
libdir_loader: added 'creb' to the global objectclass path
libdir_loader: added 'cxc' to the global objectclass path
libdir_loader: added 'iemlib' to the global objectclass path
libdir_loader: added 'mapping' to the global objectclass path
libdir_loader: added 'markex' to the global objectclass path
libdir_loader: added 'maxlib' to the global objectclass path
libdir_loader: added 'memento' to the global objectclass path
libdir_loader: added 'mjlib' to the global objectclass path
libdir_loader: added 'motex' to the global objectclass path
libdir_loader: added 'oscx' to the global objectclass path
libdir_loader: added 'pddp' to the global objectclass path
libdir_loader: added 'pdogg' to the global objectclass path
libdir_loader: added 'pixeltango' to the global objectclass path
libdir_loader: added 'rradical' to the global objectclass path
libdir_loader: added 'sigpack' to the global objectclass path
libdir_loader: added 'smlib' to the global objectclass path
libdir_loader: added 'unauthorized' to the global objectclass path
vbap - v1.1 - 14 Aug. 2014 - (c) Ville Pulkki 1999-2006 (Pd port by HCS)
libdir_loader: added 'pan' to the global objectclass path
freeverb~ v1.2
libdir_loader: added 'hcs' to the global objectclass path
libdir_loader: added 'jmmmp' to the global objectclass path
libdir_loader: added 'ext13' to the global objectclass path
libdir_loader: added 'ggee' to the global objectclass path
libdir_loader: added 'ekext' to the global objectclass path
libdir_loader: added 'disis' to the global objectclass path
libdir_loader: added 'lyonpotpourri' to the global objectclass path
pdlua 0.9 (GPL) 2014-2018 Martin Peach et al., based on
lua 0.6~svn (GPL) 2008 Claude Heiland-Allen claude@mathr.co.uk
pdlua: compiled for pd-0.48 on Feb 7 2019 19:31:25
Using lua version 5.3
pdlua: using JavaScript interface (Pd-l2ork nw.js version)
[14] error: audio I/O dropout
So, I get the impression that these audio I/O dropout issues happen quite a bit. But does anyone have any ideas for what I can try next? Also, I apologize if this is the wrong forum this question. If someone could just point me in the right direction, that would be awesome.
possible deken bug + general question on dependencies
@oystersauce You are looking for freeverb~ ...... which has been compiled for 64-bit windows and is available on Deken.
I am pretty certain that your recent posts are all about the same problem.
If nobody has recompiled an external for 64-bit for the OS that you are running (and added a link to Deken) then Deken will not find it.
Some externals might have been compiled but not added, some have not been compiled, and maybe some cannot be compiled.
You might find repositories for the C code on github that will allow you to compile for your system.
Please share them afterwards as it will help others with the same problem.
64-bit Vanilla is starting to have some useful tools, but if you don't need them or the higher precision of 64-bit then Extended or Deken for 32-bit Vanilla are still a better bet at the moment.
Of course on a 64-bit OSX that is not an option.
If you are willing to try a fork like Purr Data then the developers are often more active and willing to help rebuild old (or even new) externals for their version.
A lot of people have been looking for [knob] and @yoichi_tbbb recently made a great one here........ https://forum.pdpatchrepo.info/topic/10938/new-knob-gui-object which I am surprised no-one has compiled for 64-bit.
David.