Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

REQUEST: Passed parameters into subpatch
by William Huston 16 Aug '20

16 Aug '20

What about this? [pd NAME IGNORED ... -p ARG1 ARG2...] This would be a nice feature, in that it would make subpatches work more like abstractions. Thanks, BH -- William Huston: WilliamAHuston(a)gmail.com Binghamton NY *Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog <http://WilliamAHuston.blogspot.com> -- Facebook <http://facebook.com/billhuston> -- Twitter <http://twitter.com/WilliamAHuston>-- Youtube <https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1> * -- Podcast Blog <https://billhustonpodcast.blogspot.com/>* *Document collections*: VirtualPipelines <http://TinyURL.com/VirtualPipelines> -- BHDCSDimockArchive <http://bit.ly/BHDCSDimockArchive> *Please support my work! -- *TinyURL.com/DonateToBillHuston

1 0

g_all_guis.h include guards?
by Dan Wilcox 15 Aug '20

15 Aug '20

Howdy all, I noticed today that g_all_guis.h does not have #if/#def include guards. Is this an oversight or is there some reason? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 5

Tk 8.6 on macOS?
by Dan Wilcox 13 Aug '20

13 Aug '20

Howdy Miller, Is the Pd 0.51-1 test1 build using a newer TK 8.6 framework? If so and it's working well, can you update the wish-shell.tgz with the new source Wish.app you are using? I can also make a PR for this if you send it to me. Once it's working, I like to update the included wish so that custom builds are still using the same canonical Wish & resulting Tcl/Tk versions. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

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

tcl error message
by Eric Lennartson 01 Jul '20

01 Jul '20

Got this error while making an abstraction. Only happens when I load the patch as an abstraction, not when I open the file itself. Pd seems to continue functioning normally, but I figured that y'all might want to know about it. Not sure what else might be helpful to know. (Tcl) INVALID COMMAND NAME: invalid command name ".x10046c6f0.c" while executing ".x10046c6f0.c delete 105031800IN0" ("uplevel" body line 267) invoked from within "uplevel #0 $docmds"

4 5

libpd talking to host in blocksize 1
by Max 30 Jun '20

30 Jun '20

Hi list, when using libpd as a plugin to a host, say VCV Rack or a DAW, it is desirable to not only be able to process small blocksizes internally, but also talk to the host in a smaller blocksize than the default 64. Especially in the case of VCV Rack this is almost a necessity to do meaningful analog modelling, recursive feedbacks, etc. Would this feature be possible to implement at all given the limitation of Pd itself? M.

2 1

Jump to page:

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