[declare] vs help browser
@ddw_music well I for one have never been on board with the whole ~/Documents/Pd/externals thing.. especially if it is not in staticpaths (also why would you install externals into Documents of all places??). I do think that ~/pd-externals is supposed to be different from ~/Documents/Pd/externals though (that was your main hangup I think). To me it makes sense that windows has appreciably different standard paths than linux.
This isn't so much an inconsistency between the gui prompt and the helpbrowser as it is an inconsistency between the gui prompt and the static paths themselves (which the helpbrowser then references when it populates its listboxes)
if it were up to me externals would still be installed in an "old" standard location by default - e.g. ~/Library/Pd on osx - and the gui wouldn't recommend anything different, maybe just tell the user what directory externals will be installed to and ask if they want to change it.
I assume you can navigate to the externals directory in the help browser in windows and Gem and Zexy show up there though..
just fyi you can safely delete your /home/dlm/pd-externals entry from the search paths as it is already in the static path. (then it won't show up in the helpbrowser anymore, which is redundant since the helpbrowser is populated with its contents anyhow)
on the other hand, I suppose one could use ~/Documents/Pd/externals as a way to disclude items from the root helpbrowser listbox.
[declare] vs help browser
As a further test -- I hacked ./tcl/helpbrowser.tcl to print to stdout some progress messages while building the help browser directory list. (Doing this in Linux -- I haven't set up the Windows machine to build Pd from source.)
To my surprise, I found that the Externals Install Directory is part of $::sys_staticpath (in Linux).
Each entry in $::sys_staticpath is globbed for any subdirectories -- so this is how it's finding Gem, cyclone, zexy etc.
staticpath add search /home/dlm/pd-externals/Gem
staticpath add search /home/dlm/pd-externals/freeverb~
staticpath add search /home/dlm/pd-externals/zexy
... etc.
A little bit later, it checks $::sys_searchpath -- this comes from preferences. These entries are not globbed for subdirectories.
searchpath add search /home/dlm/pd-externals
(Above is the only entry coming from Preferences > Path.)
So one possible difference is that the "static path" includes my external location in Linux (that isn't speculation -- the stdout listing proves it), while it probably doesn't in Windows.
OK, then, let's grep staticpath... this leads to s_path.c, which says (in an ifdef for Linux):
sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0);
So user-home/pd-externals is a special, hardcoded location for Linux, which I happen to be using for my externals.
Looking a bit further down, hardcoded locations in Windows are AppData/Pd and something about common-program-files/Pd -- but the Pd GUI recommends Documents/Pd/externals as the installation directory. (And Mac will have a similar problem, because the hardcoded locations include ~/Library/Pd but again not Documents/Pd/externals.)
I'm satisfied that this explains the difference in behavior between the two environments. But it leaves a bit of an impression that this hasn't been completely thought through. If there are magic locations for help browser search, ideally this would be coordinated with recommended installation directories, but they aren't.
hjh
[declare] vs help browser
Are you looking at the same directory?
Do you mean the Linux machine or the Windows machine?
If the Linux machine -- I'm aware of the ~/.pdsettings file -- its contents match the display (nloadlib = 0 meaning no startup libs, npath = 1 and only a path1). There is no registry in Linux, so that comment isn't relevant to the Linux machine.
On the Windows machine, there isn't any other Pd library folder, and I keep only one version of Pd. But I don't think this question quite makes sense -- if there are multiple versions of Pd sharing the same settings, how would the two versions behave differently? Wouldn't I see the same behavior in multiple versions?
FWIW, I checked the registry and, just like the Linux machine, nloadlib is 0 and npath is 1. So Pd on the Windows machine should not be loading any startup libraries (and indeed, I don't see any output from Gem or zexy), and there should be only one search path (which I can confirm by creating an object in a subfolder, and it isn't found).
"This Pc" is pretty clearly just a display convention in the Windows Explorer, and has nothing to do with the actual file system structure.
hjh
[sigmund~] creation arguments/parameters setup
@cfry Those sorts of sounds can be gotten as well and a more sensitive mic will pick them up. The problem you are having is the mic is just getting noise, everything of the same volume, so nothing distinct for [sigmund~] to pick out, remember all those discrete sources add together. By wind noise I meant the sound of wind hitting a microphone directly, this creates a constant sound which will over power all those other sounds, not the sound of wind rustling the leaves in a tree. A good wind screen will be very helpful for you here, but you need to remember, a windscreen does reduce mic sensitivity, so there is a trade off, increase mic sensitivity and the more wind noise it picks up, put on a denser wind screen and you loose some of that sensitivity. A pop screen could work better since it can be placed between the wind and the mic, the other sides of the mic are left open, but if the wind shifts you could end up with wind noise overpowering everything and have to reposition the screen. If you limit yourself to days with nothing more than light winds, you should be able to get by with just a light windscreen and not suffer much loss in sensitivity.
My knowledge of windscreens and pop screens and the like is fairly limited and largely theoretical, I have little hands on use of these things as I mostly record in more controlled environments or in situations where I have more leeway than your needs allow. Seeking out people or sites dedicated to making field recordings would likely be your best path on finding a good mic/pre setup for your needs.
How to compile/install externals in vanilla Pd?
@4zz4 here is a video that explain how to use the externals folder:
there you also have to put your compiled externals.
You can download most of the externals from Deken.
But if you want to compile them by yourself: In my own experience it is easier with Linux than with Windows. Mostly you have a makefile for Linux and a .sln file for Windows/Visual Studio.
It is different from external to external, most of the time there is helpful information in the readme/install file of the external.
If you have problems with compiling a certain library it would be good to know which library and where (which error), then it is easier to help.
How to compile/install externals in vanilla Pd?
I know Pd wants me to use viual studio (i'm on windows, i will switch to linux when i havue time for it) to compile externals. It also wants me to use a shell, but idk how to do that. i opened a powershell window in the external that i wanted to compile, but when i entered in "nmake" and "pd_nt" there nothing happended. The external was downloaded on SourceForge and i unzipped it twice to get out the contents.
Can somebody explain how to compile an external as much as practically possible?
Also, where should i put my externals? is it in "lib", "extra", something else or should i make a new folder for externals? I currently made a new folder to externals called "externals" because i saw a youtuber having a folder named that for his externals.
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:
[pix_share_read] and [pix_share_write] under windows
@whale-av, here is a log running pd with -lib Gem -verbose.
tried both 32bit and 64bit pd 0.48-1...
tried ./Gem.m_i386 and failed
tried ./Gem.dll and failed
tried ./Gem/Gem.m_i386 and failed
tried ./Gem/Gem.dll and failed
tried ./Gem.pd and failed
tried ./Gem.pat and failed
tried ./Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pat and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pat and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.pat and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.dll and succeeded
D:\\pd-0.48-1.windows.64bit\\extra\\Gem\\Gem.dll: couldn't load
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.pd and failed
Gem: can't load library```
warning: D: multiply defined
warning: D: multiply defined
warning: D: multiply defined
warning: C: multiply defined
warning: C: multiply defined
warning: B: multiply defined
warning: B: multiply defined
warning: A: multiply defined
warning: A: multiply defined
warning: D: multiply defined
warning: D: multiply defined
warning: C: multiply defined
warning: C: multiply defined
warning: B: multiply defined
warning: B: multiply defined
warning: A: multiply defined
warning: A: multiply defined
I was not troubled by this so far operating the patch of this, but still wondering what this is? Can this be resolved? Could this be causing a problem in the future?
possible deken bug + general question on dependencies
Hi,
not sure if this is a bug. Don't wanna noobishly spam to the devs' bug reports pile but this needs to be clarified. Is it a deken issue or on the repository or what?
Some searches for externals in the 64-bit version of PD vanilla for windows (I'm on windows 10) the deken search (in the menu: Help -> Find externals) don't return results while the same externals (in some cases) can found on the 32-bit version. Some externals are neither found in the 32- nor 64-bit version. Additionally - as a marker that something is wrong here - PD does not output the line
[deken]: No matching externals found. Try using the full name e.g. 'freeverb'.
which is the case for truly non-existing names (like searching "sdfsdfsdf").
Example of external found as expected on 32- and 64-version:
cyclone
Example of external found as expected on 32- but NOT on 64-bit version:
moonlib
Example of external found neither on 32- or 64-bit version:
apple
What I'm most eager to find out is whether, say, the moonlib external is just not compiled for 64-bit windows and therefore is not found or whether it should be found and just isn't (which hints more towards a bug).
Does anyone have an idea? I'm not completely new to PD but not up to date at all with its development. It seems the current version 0.49 vanilla is the first to have a 64-bit windows version.
kind regards