Pd-dev July 2020

pd-dev@lists.iem.at

4 participants
7 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

Re: [PD-dev] Opening patches from libpd without accessing filesystem?
by Dan Wilcox 27 Jul '20

27 Jul '20

If you have suggestions for a libpd API which wraps this, I encourage you to open an issue on the libpd Github repo. If you have something working, even better. We can look into integrating or at least documenting it for others. > On May 6, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > As for my case, I think the garray_init idea suggested by you and > Christof Ressi is enough for me right now! I will test with it. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

support for other alphabets for cyclone/comment?
by Alexandre Torres Porres 18 Jul '20

18 Jul '20

I can see Pd accepts characters in different alphabets,. If I change my macos settings to have an input in arabic or something, it's fine in Pd comments and stuff. I can switch back and forth between different alphabets and Pd just works fine with it. Of course this is useful for labels and comments and stuff Anyway, the same doesn't work for cyclone/comment and I wonder where in Pd's code it takes care of that, so I could do the same automatica detection for cyclone/comment any hints where I should look? thanks!

1 1

Macs to transition to ARM processors
by Dan Wilcox 13 Jul '20

13 Jul '20

Howdy all, Apple announced today that it will transition from Intel to its own Arm processors. What this will bring is: * Universal 2: x86_64 & arm fat binaries * Rosetta 2: emulation layer from x86_64 to arm For Pd, this means that current binaries will most likely *run* but who knows how the performance will be good for realtime DSP. OTOH, they did demo a game and some virtualization support so it seems they have focused on making things run as well as they can. Building Pd itself for macOS arm should be relatively easy, just a different arch target. For externals, this would may require an additional fat lib type, perhaps dfat_2? Note, I believe the distinction will be important for us since we still have "Universal 1" builds. As with the Pd core, updating pd-lib-builder should also be relatively easy by adding the new arch targets, depending on what they are. For deken, this means recompiling and uploading the new fat type. I don't imagine it will be possible to have a "fatter lib" which supports ppc, x86, x86_64, & arm. I believe the writing is on the wall for the eventual need for a build system newer then OS X 10.6. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

6 7

Re: [PD-dev] [PD] Pd 0.50-2 on macos 11.0 BigSur beta
by IOhannes m zmoelnig 07 Jul '20

07 Jul '20

On 06.07.20 19:39, Martin Peach wrote: > The build farm used by Pd-extended worked very well for me. It would > be nice to have such a setup integrated with the deken system, so > anyone could upload their externals and they would be built and > packaged online instead of each developer needing to acquire one of > each machine on a 3-year rolling plan. we have something like this [0] setup at the iem, based on gitlab-ci[1]. the system is targetting pd-lib-builder projects (though it will probably will work with most build-systems that follow a "make && make install" paradigm) whenever someone pushes a new commit to a CI-enabled Pd-project, it will build the external for the following architectures: - Darwin/amd64 (aka "64bit macOS") - Windows/amd64 (aka "64bit windows") - Windows/i386 (aka "32bit Windows") - Linux/amd64 - Linux/i386 - Linux/armhf (aka "Raspberry") - Linux/arm64 (the future) the build artifacts are collected into a single deken package, which can be downloaded manually. if the commit was "tagged" (which we take as a "release" indicator), the deken package will be automatically uploaded to deken.puredata.info. there's a system to declare build dependencies (via "apt" on linux, MSYS' "pacman" on Windows, and "brew" on macOS). for systems that don't come with a proper package manager installed by default (macOS, Windows), the runtime dependencies are collected and embedded in the deken package. some libraries cannot be built into a single multi-arch library because of file conflicts (this becomes fun quickly when dealing with dependency libraries and dependencies thereof). there's an option to create multiple single-architecture deken packages for this case. in general, the configuration is about 3-lines (e.g. [2]) a bit more, if you want to enable automatic uploads to puredata.info. so everythings cool. what are the caveats? ## Darwin/i386 we currently don't build for Darwin/i386 (nor Darwin/amd64). while we have older macOS builders (there's builders for both macOS/Sierra and macOS/Mojave, the default being macOS/Mojave) with *not* the newest XCode, and should therefore still be able to build i386 binaries without problems, these are currently disabled because of the automatic dependency management (on macOS we use "brew" to install dependencies; brew has decided to stop supporting i386 binaries a while ago :-() ## accountability deken is a quite insecure system, as there isn't really a way to "verify" a package before installing it. the best you can get is that you know the <username> who uploaded a given package (in theory there's also the gpg-signature; but who ever checked that?) now, with automated uploads this becomes a bit muddled, as there is no longer any direct involvement of a human (whom you can trust, or not) in creating the binaries. in theory we know the user who pushed the last commit that triggered the build process. but currently there's no easy way to make this user show up in the deken results. ## passwords to upload any package to deken.puredata.info, you currently need a username/password. if you want to upload automatically, the build-process needs to know your username/password. i really don't want to encourage people to store their credential for one web-service in any other web-service (even if both services are operated by the same entity (me!)). (the credentials would be stored in some database and *NOT* in a file in the repository, so they are not directly exposed to ordinary humans; but nevertheless the credentials need to be plain-text (as in: unhashed) which is a security breach...). for my personal use i have created a "zmoelnigbot" account on puredata.info to manage those uploads (and keep it separate from my other account). but that doesn't scale well. ## resources it's not like we have a big compile farm or so, but we take interest (and pride) in running all the builds on-premises. currently there's 3 machines: - an oldish (but dedicated) MacMini (that needs to run all the Darwin-builds for license reasons; and which also does Windows builds) - a dedicated linux box (Windows and Linux builds) - a virtual machine (Linux builds) having dedicated machines means, that the builds will (mostly) start right away (as opposed to e.g. travis-ci where it can take considerable time (as in: half an hour) until the builds start). having very few machines available means that building for all the different architectures will take longer than just running "make" locally. it also means that if multiple projects want to build at the same time, it will take longer (and we have some in-house projects where each build takes about 1hour; if they happen to be started before your project, it will take a while). it's probably super-easy for volunteers to add their own machines to the build farm - at least for the Linux builds (that use docker internally). it's much more complicated for Windows and Darwin builds (which currently use manually pre-configured VirtualBox images that have to be regularly updated (manually), which is always a pain in the ass). of course, the Windows and Darwin builds are those where the automatic build becomes really interesting. ## resources (legally) the service is currently run by the iem, at the iem and for the iem. i would have to talk with my boss about making it available to a wider audience. it would probably be fine (but of course, i really don't know). mgfdasr IOhannes [0] https://git.iem.at/pd/iem-ci/ [1] https://docs.gitlab.com/ee/ci/ [2] https://git.iem.at/pd/iemnet/-/blob/master/.git-ci/gitlab-iem.yml

1 0

Re: [PD-dev] tcl error message
by Alexandre Torres Porres 01 Jul '20

01 Jul '20

Eric only replied to me, I'm sending my answer to him and the list Em ter., 30 de jun. de 2020 às 20:35, Eric Lennartson < lennartsoneric(a)gmail.com> escreveu: > This abstraction is inside a subpatch that's in abstraction. > can you send me a folder with all the patches where the error presents itself? I couldn't trigger it by only loading your patch or if I put it in a subpatch and stuff. Em ter., 30 de jun. de 2020 às 20:39, Eric Lennartson < lennartsoneric(a)gmail.com> escreveu: > Yeah okay, so you're completely right. The loadbang needs to change so > that it bangs after the parent patch is created. > yeah, I thought so :) but please don't change it, what you're doing is correct. The error needs to be fixed, and now I'm pretty positive my fix from https://github.com/pure-data/pure-data/pull/1079/commits/8ba3bd3b115d62dc8d… can also take care of this annoyance. But send me the whole thing so I can test it please ;) cheers >

1 0

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 July 2020