Pd-dev April 2020

pd-dev@lists.iem.at

9 participants
9 discussions

Doppler effect implementation
by Frodo Jedi 01 May '22

01 May '22

Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested? Cheers FJ

9 15

My [hid] 0.7.1 fork builds without XCode
by Albert Rafetseder 24 Nov '20

24 Nov '20

Hello, TL;DR: Here's my fork of [hid] version 0.7.1 that needs no XCode to build on Mac OS X (10.11.6 on my end, hopefully on later macOSses too): https://gitlab.com/aaaaalbert/pd-hid It's based on https://git.puredata.info/cgit/svn2git/libraries/hid.git/ Long version: I'm just re-learning Pd and decided it would be a good idea to build it on my ageing Mac (which went marvelously!), and also build [hid] which didn't go that smoothly for me. In the versions of [hid] that I inspected [1], it requires XCode to build on Darwin, as the Makefile [2] passes to xcodebuild an XCode project file [3], lets XCode do its thing, then continues. I couldn't get my version of XCode to use the project file, running into this error: ``` xcodebuild: error: Unable to read project 'HID Utilities Slib.pbproj'. Reason: Project file 'HID Utilities Slib' was written by an unsupported Xcode version (38) ``` I soon gave up on hacking the project file and instead wrote a sub-Makefile for the Mac parts [4], adapted the main Makefile [5], and voilà! I can use a spare JoyCon game controller to feed button presses to my patches. I've built and manually tested my version of [hid], tentatively labeled 0.7.3, both on Mac (OS X 10.11.6) and Linux (Xubuntu 19.10) with PureData 0.50-2 as tagged on GitHub [6]. Outlook: I'm thinking of adding accelerometer support for the game controller, and perhaps sort out the values that hatswitches produce on different OSses. Thanks, Albert. [1] Here are the different versions / forks of [hid] that I found: * 0.7.1 --> https://git.puredata.info/cgit/svn2git/libraries/hid.git (That's the one I based my work on.) * 0.7 --> https://sourceforge.net/projects/pure-data/files/libraries/hid/hid-0.7.tar.… (as linked from the Pd wiki) * 0.7 --> https://salsa.debian.org/multimedia-team/pd/pd-hid/ * 0.7.1 --> https://github.com/agraef/purr-data/blob/master/externals/hid/ Binary releases from deken: * 0.7.1 --> http://puredata.info/Members/zmoelnig/software/hid/ * 0.7.1 --> http://puredata.info/Members/chr15m/software/v0-0extended/hid/ [2] original Makefile: https://git.puredata.info/cgit/svn2git/libraries/hid.git/tree/Makefile#n200 [3] XCode project file: https://git.puredata.info/cgit/svn2git/libraries/hid.git/tree/HID%20Utiliti… [4] sub-Makefile for Mac build, not using XCode: https://gitlab.com/aaaaalbert/pd-hid/-/blob/osx-build-without-xcode/HID%20U… [5] adapted main Makefile: https://gitlab.com/aaaaalbert/pd-hid/-/blob/osx-build-without-xcode/Makefile [6] https://github.com/pure-data/pure-data/releases/tag/0.50-2

2 2

A gift from a PD user :)
by Jakob Skouborg 28 Apr '20

28 Apr '20

Hello guys! I am sorry if this violates the rules of the dev list, but I just want to send a little bit of gratitude back to you guys for your endless effort in making Pure Data better. So here is something that I have created with Pure Data, a 64 voice granular sample player: Here is a short clip of it in action: https://www.youtube.com/watch?v=0VuRK1wMdVM <https://www.youtube.com/watch?v=0VuRK1wMdVM> Here is the patch, slightly modified compared to the Youtube clip, without stereo, as the stereo wasn’t too good, it needs to be updated. It can be pretty cpu intensive, at some setting it uses 100% cpu of my 2012 Macbook, but most settings are good: https://github.com/jaffasplaffa/Pure-data-patches/tree/master/Granular21 <https://github.com/jaffasplaffa/Pure-data-patches/tree/master/Granular21> Have fun :) Jakob Skouborg

3 4

Re: [PD-dev] PD-specific tips for compiling faster on Windows
by Dan Wilcox 23 Apr '20

23 Apr '20

Actually, 1-2 minutes is pretty good! Before Christof helped with improving the build on Windows, it was more into the 10 minute range due to the layout and compilation order of the files. Christof is right in that if you are just testing smaller changes, you can just rebuild the core and put the compiled file into the bin folder to run it without having to rebuild the whole thing. I also do this on macOS where I build the Pd core and simply copy the updated pd executable into the .app bundle without rebuilding the entire bundle each time. Maybe we should include some dev / debug tips and tricks about this to the INSTALL.txt? There has been interest for using CMake for libpd, so I could see that as a companion method to build Pd but not a replacement for autotools IMO. Then we would have 3 methods to build it, yeah! :P In any case, as long as something like this is maintained, it's all good as Pd should be easy to compile on it's platforms. > On Apr 21, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Tue, 21 Apr 2020 10:24:54 +0200 > From: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] PD-specific tips for compiling faster on Windows > Message-ID: <4426262d-2274-567a-8e3c-fd2935e750fe(a)christofressi.com <mailto:4426262d-2274-567a-8e3c-fd2935e750fe@christofressi.com>> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Autotools (especially libtool) is very slow on MinGW. On my system, > compiling the /extra externals takes significantly longer than compiling > the actual Pd application, only because of libtool. > > > If you want to get faster build times, rewrite the build system in CMake > and compile with MSVC :-) > > > How often do you need to recompile whole Pd? Usually, you just change > 1-2 files and this should compile and link rather quickly. "make app" is > also slow (again, because of libtool). Usually, I only run "make app" > once and then just copy pd.dll into the Pd folder on the command line > (assuming you only make changes to the core): > > > cp ./src/pd.dll ./pd-0.50.2/bin > > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD-dev] PD-specific tips for compiling faster on Windows
by Dan Wilcox 22 Apr '20

22 Apr '20

The libpd CMakeLists.txt might be a good starting point. I have used CMake for some specific things, but in general I find autotools to be the easiest to use for (non-Windows) end users, especially those on Linux that are more used to the paradigm. It's always a beast to set up, but stays stable for a long time. One danger I'd like to avoid is all of the Windows people *not* using the autotools build as then we lose testing and further updates on that platform. Keep in mind that the autotools build is now used for Miller's "canonical" releases. > On Apr 22, 2020, at 2:31 PM, pd-dev-request(a)lists.iem.at wrote: > >> There has been interest for using CMake for libpd, so I could see > that as a companion method to build Pd but not a replacement for > autotools IMO. > > Actually, I would volunteer to setup a CMake build system for Pd. CMake > is really nice because it supports so many tool chains out of the box, > including Visual Studio solutions and Unix Makefiles for MinGW. > > Of course, this is not high priority, so I might give it a shot in > summer or so. > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

PD-specific tips for compiling faster on Windows
by Henri Augusto Bisognini 21 Apr '20

21 Apr '20

Hi list! I'm using the usual build tools (as in INSTALL.txt) for compiling PD. Builds here can take several minutes for completion. I know that compiling times on windows are generally slower than Linux and sometimes OSX. But i wonder if there is any pd-specific tips on optimizing compile time on Windows. Cheers, Henri

2 1

Re: [PD-dev] Failed to configure on MacOS 10.14.6
by Dan Wilcox 20 Apr '20

20 Apr '20

> On Apr 20, 2020, at 11:09 AM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Mon, 20 Apr 2020 11:03:05 +0200 > From: Pierre Guillot <guillotpierre6(a)gmail.com <mailto:guillotpierre6@gmail.com>> > To: pd-dev <pd-dev(a)iem.at <mailto:pd-dev@iem.at>> > Subject: [PD-dev] Failed to configure on MacOS 10.14.6 > Message-ID: > <CALPKkhoKVpKjwFE3ZGTRxajpG9vUG4uprT7Z2qMZd=o_oTnFVw(a)mail.gmail.com <mailto:CALPKkhoKVpKjwFE3ZGTRxajpG9vUG4uprT7Z2qMZd=o_oTnFVw@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I try to compile Pd on a new computer but the configure fails. > I installed all the dependencies using Homebrew: > > brew install automake autoconf libtool pkg-config gettext You don't need to do this every time, only once when you set up the build dependencies. This is why you get so many "already installed and up-to-date" messages. At most, you can update Homebrew and the installed packages now and then. > I run brew link --force gettext > > Warning:Refusing to link macOS provided/shadowed software: gettext > > ... > > I guess here is the problem.... No. It's only a warning. If gettext is not found, you can still build libpd as gettext is only needed for building the translations in the /po folder. macOS (and/or the developers tools) comes with an older version of gettext, so to use the newer one provided by Homebrew, you need to add the bin path to the newer one before the other default bin paths which is what the suggestion in the output is telling you. It's not that important as I don't think I've done it either and must be using the default system gettext which works fine. > > Then I run ./autogen.sh > > autoreconf: Entering directory `.' > > ... > > autoreconf: Leaving directory `.' That is the normal output which I see as well. > Then I run ./configure --disable-jack-framework > > but I get: .in'ig.status: error: cannot find input file: `Makefile > (I attached the full output of configure) > > Do you have any idea of what I can do to solve the problem? > Thanks! Was a Makefile.in created after you ran autopen.sh? The error message is a bit jumbled as it was partially overeaten by another status message, but it seems to say it cannot find a Makefile.in file. Automake should process each Makefile.am into a Makefile.in file which configure then uses. Also, look at the end of the config.log file which will have more detailed info. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Failed to configure on MacOS 10.14.6
by Pierre Guillot 20 Apr '20

20 Apr '20

Hi, I try to compile Pd on a new computer but the configure fails. I installed all the dependencies using Homebrew: brew install automake autoconf libtool pkg-config gettext Updating Homebrew... Warning: automake 1.16.2 is already installed and up-to-date To reinstall 1.16.2, run `brew reinstall automake` Warning: autoconf 2.69 is already installed and up-to-date To reinstall 2.69, run `brew reinstall autoconf` Warning: libtool 2.4.6_1 is already installed and up-to-date To reinstall 2.4.6_1, run `brew reinstall libtool` Warning: pkg-config 0.29.2_3 is already installed and up-to-date To reinstall 0.29.2_3, run `brew reinstall pkg-config` Warning: gettext 0.20.2 is already installed and up-to-date To reinstall 0.20.2, run `brew reinstall gettext` I run brew link --force gettext Warning:Refusing to link macOS provided/shadowed software: gettext If you need to have gettext first in your PATH run: echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile For compilers to find gettext you may need to set: export LDFLAGS="-L/usr/local/opt/gettext/lib" export CPPFLAGS="-I/usr/local/opt/gettext/include" I guess here is the problem.... Then I run ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/generated -I m4 autoreconf: configure.ac: tracing autoreconf: running: glibtoolize --copy --force glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'm4/config'. glibtoolize: copying file 'm4/config/ltmain.sh' glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/generated'. glibtoolize: copying file 'm4/generated/libtool.m4' glibtoolize: copying file 'm4/generated/ltoptions.m4' glibtoolize: copying file 'm4/generated/ltsugar.m4' glibtoolize: copying file 'm4/generated/ltversion.m4' glibtoolize: copying file 'm4/generated/lt~obsolete.m4' autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --force-missing configure.ac:175: installing 'm4/config/compile' configure.ac:9: installing 'm4/config/missing' asio/Makefile.am: installing 'm4/config/depcomp' autoreconf: Leaving directory `.' Then I run ./configure --disable-jack-framework but I get: .in'ig.status: error: cannot find input file: `Makefile (I attached the full output of configure) Do you have any idea of what I can do to solve the problem? Thanks! Pierre

1 0

knowing when the patch is in edit mode for an external?
by Alexandre Torres Porres 03 Apr '20

03 Apr '20

Hi folks. Recently I've implemented improvements to cyclone/comment so it behaves like in Max. This is still a work in progress, but what I have is that I'm showing the inlet when I get into edit mode. Inlet disappears when I get out of edit mode. I'm still doing other things that depend on getting in and out of edit mode, like showing an outline. I might do that for cyclone/scope~ as well The thing is that I'm doing a quite dirty hack for that, which is listening to messages the patch gets, kinda like iemguts/receivecanvas and I don't like this hack, I'd rather it'd be possible to do it in an easier way. And I know that the comments in Pd will also react to getting in and out of edit mode, to show the vertical line to the right. I don't really know how it does it and if it is possible to do it in the same way for an external. If it's not possible - as I'm assuming it is not - what would need to change to allow this to be easily queried by an external object? So yeah, this is basically a feature request :) thanks Alex

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev April 2020