Pd-dev June 2020

pd-dev@lists.iem.at

11 participants
13 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

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

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

how to know if a GUI object is visible in a GOP?
by Alexandre Torres Porres 27 Jun '20

27 Jun '20

Hi folks, I opened an issue about this on github, but since there was no answer I'm hoping to get some attention and a possible answer here on the dev list. In Pd, if you have graphical objects in a GOP subpatch that are out of the visible range, it's possible they get drawn, and I opened the issue to mention that [vradio], for instance, does that (here it is: https://github.com/pure-data/pure-data/issues/1053 ). I also mentioned n there how graphs inside a GOP subpatch can also do that. But I also have this issue with some GUI externals I take care of. So, is there a way for an object to know if it is visible in the parent pacth so we do not tell it to get drawn? What I've now just stumbled upon is our code for cyclone/scope~ - unlike [vradio], if the object is out of bounds in a GOP and I tell it to change dimensions, it won't get drawn, but trigger a tcl/tk error instead. Note that no error happens if the subpatch is opened or if it is inside bounds (or both of course). Anyway, this line is what triggers the error => https://github.com/porres/pd-cyclone/blob/cyclone_0.5-1/cyclone_objects/bin… The error gives me hope there's a way to check if it is possible to do it, and then not tell it to do it if it's not possible... I used the "(glist_isvisible())" function to check if it's visible. It doesn't work as a check because the object is in a GOP, so it'll say it is visible, even though the object itself is actually out of bounds. Now, in the case of scope~, it tries to delete the GUI by referring to the subpatch canvas, and I assume it doesn't work because that window isn't active/opened. So if I change the lines below sys_vgui(".x%lx.c delete all%lx\n", x->x_cv, x); scope_draw(x, x->x_cv); To refer to the parent canvas (and not "x->x_cv"), I don't get an error, but I get the object getting redrawn in the parent patch outside the graph, just like the issue I reported with [vradio]. Again, when bumping into this, I thought, since the object knows it can't delete and redraw (that is, since it gives an error), there could be a way to check it. What do you say? Thanks

2 2

Re: [PD-dev] Macs to transition to ARM processors
by Dan Wilcox 25 Jun '20

25 Jun '20

> On Jun 25, 2020, at 12:00 PM, IOhannes m zmoelnig wrote: > >> I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it. > > sorry. if my post came across like this, it was really unintentional. > (on re-reading, i don't find my email especially snarky; except for the > first line alluding to iOS as their mainline system) Oh, you are probably right. I was more annoyed that, after writing an initial mail focused on the technical aspects of the upcoming transition, the entire contents of one of the responses was basically "I don't like Apple. Monopoly, blah blah..." Again, everyone can use their platform, it's all fine, but why bother writing that? Start your own thread then. Anyway, enough time wasted on that. As far as testing goes, I won't know much until I upgrade to macOS 11.0 when it comes out. I'm currently on 10.14 and will essentially skip 10.15 so far. I might see what Xcode 12 brings on a work machine. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] Macs to transition to ARM processors
by Dan Wilcox 24 Jun '20

24 Jun '20

> On Jun 24, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > so running on all > architectures ever supported by OSX (modulo system libraries...). To be pedantic, it has been officially "macOS" for some years now. The upcoming version will be 11.0, so "OS X" will no longer be relevant anyway. > why not just add arm64 to that list? I was only musing that the "Universal 2" format *might* be new. I haven't read any of the details about it yet. Hopefully it's the same thing with just the new architecture. > so initially, I was going to rebuke the idea oft a d_fat2 format. > > apple's labelling as "Universal 2" is a bit concerning though... > > anyhow, I don't really see why apple should make a 2nd universal format. > iirc, "fat" is a technology from NextStep, so its well aged, and has > proven itself. > this of course is no reason to not drop it. I mentioned that it *might* be different as there was some talk about Rosetta 2 and the other emulation/virtualization layers having some sort of way to optimize existing binaries for the different architecture, which led me to think that they might rework the "fat" approach with some additions or changes to facilitate this and/or lay the groundwork for the next 10-20 years. OTOH I also cannot imagine them changing something as fundamental as this unless it's *really* necessary. > more important: can you (well: they) make money with a new format? > i'm having a hard time here to imagine how (but then: i'm not very good > in imagining how to make money in general). (The following is not to IOhannes in particular.) As per the usual Apple grumbling I will say "nobody is forcing people to buy an Apple product." Supporting is another story, but now there are people like me to help and I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it. If support is a pain, then those institutions relying on Macs, of which there are many, could maybe kick back some development support in some way or even a build machine or two... > i don't think there are still enough ppc users left for apple to care > about them. > thinkgs might be different with i386 though. The last 32-bit only Intel Macs are from the late 00s, so there are some but their numbers are probably lower than you may think. There are probably fewer 32-bit Intel Macs in use now than ppc I bet, at least as far as Pd is concerned. > however, i guess the biggest issue is for the developers it's getting > really hard to create fat binaries that cover more architectures than > x86_64 and i-arm64. > that's because there's no reasonable toolchains available that allow you > to do so. Right. I imagine we are looking at a minimum of needing the Xcode12 developer tools (ie. compiler chain), without the Xcode UI. > so the only way to produce fat binaries (that include mor ethan x86_&4 > and amd64) is to have multiple build systems (parts of them unsupported > by now) and combine the artifacts into a single binary in a second step. I think it's better to have separate builds, which we already have. It's already hard enough, especially concerning Tcl/Tk frameworks, that I do not think making "one app bundle to rule them all" is even practical... feasible perhaps, but not sustainable. > that sounds like a big enough hurdle to be a rather plump nudge for most > applications to support only "recent" architecture. no need to invent a > new format. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD-dev] How to create an unsigned Pd.app?
by Dan Wilcox 10 Jun '20

10 Jun '20

Howdy Roman, > On Jun 10, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 10 Jun 2020 10:46:16 +0200 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] How to create an unsigned Pd.app? > Message-ID: <a29f644f7d58e842bf91e05bb7909bb136346698.camel(a)gmail.com <mailto:a29f644f7d58e842bf91e05bb7909bb136346698.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi all > > I only loosely followed the discussion about how apps for upcoming > macOS versions need to be signed and notarized to run without warnings. > > It seems the official builds for macOS distributed by Miller are > signed. Also, when I do 'make app' I seem to get a signed Pd.app. Is > there an easy way to build an unsigned Pd.app? <gripe>It was hard enough to test & fix this, of course someone *doesn't* want it to be done. :P</gripe> If you want to experiment, just comment the code sign section at the end of mac/osx-app.sh. This will disable adhoc signing and notarization. But...You *have* to sign it with *something* for 10.15 or it will be even worse: loading every older external will be blocked and have to be manually loaded. > I got complaints from people that installing netpd is hard and > convoluted. I am now trying to build a netpd.app based on Pd.app that > includes netpd and externals. I got it working so far, but when it is > downloaded through a browser, it triggers a pop up saying "This app is > damaged and cannot be opened" (translated from German). I can remove > the com.apple.quarantine attribute with: > > xattr -d com.apple.quarantine netpd-2.2.app > > and then it runs fine, but having to use the terminal to make it work > defeats the purpose of the whole exercise. As you noted, Miller's Pd.app is now signed. It's just a fake adhoc signing (certificate name "-") which doesn't require an account or actual signing certificate. You could essentially copy all of your netpd files into a copy of Pd.app, then re-sign everything yourself. That should at least get you to the same point as Miller's original download from a user perspective, ie. Right-click + Open, then good after that. You may need to sign some deeper stuff like frameworks manually before signing the whole bundle. This is what we needed to add to sign the Tcl & Tk frameworks to solve the latest issue. Again, look at the end of mac/osx-app.sh. > I am actually only assuming the "damaged" pop-up is caused by a > signature that I render invalid by manipulating it. Maybe I do > something wrong that is totally unrelated. The signature thing just > seemed the most likely reason. "Damaged" is use whenever there is an issue with an app bundle, be it a missing/unreadable Info.plist, incorrect dir layout, or security issue. Use codesign to print out the existing signing info (I forget the codesign args, it's searchable). -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

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