Pd-list June 2024

pd-list@lists.iem.at

18 participants
24 discussions

text label for toggle: default x offset?
by Peter P. 18 Jun '24

18 Jun '24

Hi list, I would like to propose a default x offset for the label of toggle to become 8 instead of the current 0. The current 0 makes the first character sit within the patch cord vertically leading to toggle's inlet. Right now I have to re-adjust the offset for every toggle created to enhance label readability. One workaround is to start the label with a whitespace (space) character, but this is too easily forgotten. looking for comments and opinions cheersz, Peter

1 0

CFP: Envisioning the future (deadline 20 June 2024)
by Eldad Tsabary 18 Jun '24

18 Jun '24

CFP: Envisioning the future (deadline 20 June 2024) The International Conference on Arts and Humanities 2024 5-6 September 2024, Colombo Sri Lanka (and remotely) https://fineartsconference.com/call-for-papers/ The call for abstracts has been extended to June 20th. Please send your proposals of research/art related to "Envisioning Futures: Diverse Perspectives, Global Narratives" The conference theme is pretty broad and the invited fields are even broader...we envision a very diverse, inclusive, speculative research and art "get-together" in Colombo (and virtually) about the future, this coming September. I envision it as a welcoming opportunity for humans from South and Southeast Asia and from around the globe to think about where we are, where we could be (or hope to be) going, and where we are afraid to be--thinking about both macro or micro aspects of our life together on this planet (and beyond?). All of that through shared thought, conversation, story telling, art making, work-in-progress demonstrations, and good ol' research papers. Thx Eldad Tsabary

1 0

Programmatic way to detect audio I/O errors
by Roman Haefeli 17 Jun '24

17 Jun '24

Hey all The Pd main window has an indicator for audio I/O errors that flashes red whenever it detected a buffer underrun. Is that information exposed in a way it can be accessed in a patch? If not, would that be a worthwhile feature? I think: yes. A patch using audio input for recording could immediately tell if the recording is garbage, for instance. My current use case is for clocks: When a drop-out is detected, it is a good moment for re-syncing the clock as the steadiness is lost anyway at that moment and the drop-out is basically the only reason for clock drifts. The poor man's drop-out detection (and what I do now) is to compare [time] and [realtime]. However, the delta between them varies depending on the configured buffersize. Only if the delta is larger than the buffersize, one can be sure that a drop-out happened. Having that info reliably from Pd directly would be definitely better. Roman

3 3

hid for pd64
by Peter P. 12 Jun '24

12 Jun '24

Hi dear list, it seems that [hid] is not available for pd64 on Debian neither via Deken, nor via apt. In case anyone is thinking of packaging such binary version, it would be very welcome! thanks a lot! Peter

1 0

vanilla drip was Gemwin vs [pix_snap]
by Dan Wilcox 12 Jun '24

12 Jun '24

Howdy, I made a vanilla [drip] using [list store], as suggested by IOhannes. I started updating older list-abs patches I was using to use the newer [list] stufff but I haven't pushed this to GitHub or deken yet. > you can also replace [drip] with some patch involving [list store], but > that's a bit more complicated. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Re: [PD] Gemwin vs [pix_snap]
by Johnny Mauser 12 Jun '24

12 Jun '24

Hi cyrille, I am having some trouble sending the patch through gmail. I took away the .zip extension and replaced it with .jpg to open it you would need to remove .jpg and put .zip back. Thanks for the answer. Yeah, I was thinking about something like that too, don’t know how to track this down. Also I am confused with the gem backends these days. Here is the patch. I hope you have not too much missing dependencies on your side, or other trouble opening it. Thanks, jonas > >> Am 11.06.2024 um 22:52 schrieb cyrille henry <ch(a)chnry.net>: >> >> hello, >> The image of the gem windows appear to be 1280x960. >> pix_snap capture a 640x480 image. >> Are you sure that the gemwin is create with a dimen of 640x480? >> Maybe there is a compensation somewhere because of high resolution apple screen. >> >> can you send your patch? >> cheers >> >> c >> >> >> Le 11/06/2024 à 21:17, Johnny Mauser via Pd-list a écrit : >>> Dear Lists, >>> I have an old patch I want to revive and the following problem: >>> I have a gemwin with certain dimensions, say 640x480pix, and I want to record it using [pix_snap]+[pix_writer]. I use the same dimensions for pix_snap but it is only capturing the left bottom corner of my gemwin. The resulting pix has the correct dimensions, also 640x480pix. >>> I use macOS 14.4, pd 54.1, >>> GEM: ver: 0.94.git v0.94-973-g1659d628b >>> GEM: compiled on May 23 2024 >>> Here are two pix showing the problem: >>> Screenshot of Gemwin: >>> Pix_writer record: >>> _______________________________________________ >>> Pd-list(a)lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list> > > <TestPatternCreator.zip>

4 5

PD hanging on closing patcher window (when Pd window is closed)
by Edwin van der Heide 12 Jun '24

12 Jun '24

On macOS 12.7.5 with Pd-0.55-0 When I open Pure Data, close the Pd window, open a new empty patcher window, and close that patcher window, Pd hangs for me and I only see the icon of the apple menu without the other menu items. I don’t think this is a new issue. I am curious if it is reproducible for others. Best! Edwin

2 1

Gemwin vs [pix_snap]
by Johnny Mauser 11 Jun '24

11 Jun '24

Dear Lists, I have an old patch I want to revive and the following problem: I have a gemwin with certain dimensions, say 640x480pix, and I want to record it using [pix_snap]+[pix_writer]. I use the same dimensions for pix_snap but it is only capturing the left bottom corner of my gemwin. The resulting pix has the correct dimensions, also 640x480pix. I use macOS 14.4, pd 54.1, GEM: ver: 0.94.git v0.94-973-g1659d628b GEM: compiled on May 23 2024 Here are two pix showing the problem: Screenshot of Gemwin: Pix_writer record:

2 1

regression: loadbanged "pd quit" is not executed immediately
by IOhannes m zmoelnig 11 Jun '24

11 Jun '24

thanks for Pd-0.55! i noticed a weird regression though: the following patch now executes the left-hand branch of [trigger], which it did not do with Pd<0.55 ``` [loadbang] | [t b b] | | | [; pd quit( | [print ouch] ``` that is: running this with "pd -nogui test.pd" will print "ouch: bang" and then quit, whereas previously it (correctly) quitted Pd without printing anything. this breaks my test-suites! gmasdr IOhannes

3 5

Re: [PD] slow startup on macOS
by Dan Wilcox 03 Jun '24

03 Jun '24

Thanks for looking into this, y'all. I also agree that this check is not really necessary. We already know the BundleID we are using, but it might have been put in place as Pd-extended had a different domain (and hence BundleID), so checking first would ensure the same plugin would work on multiple forks. We might want at least document this change and/or provide a better mechanism to check, although it seems macOS was the only platform to do this. Following, I don't see a real reason why using the `defaults` command should be slow in and of itself (except for [1]). This is perhaps a security mechanism where accessing the bundle's Info.plist directly is discouraged as it might be used by malware (my guess). Normally, you would query the defaults via the bundle ID or via the C/Obj-C/Swift APIs and *not* read Info.plist to get the bundle ID first. I don't see it as a Gatekeeper issue though, since the attributes were the same for the current stable release and this test3 release on my system: % xattr /Applications/Pd-0.54-1.app com.apple.macl com.apple.provenance com.apple.quarantine % xattr ~/Desktop/Pd-0.55-0test3a.app com.apple.macl com.apple.provenance com.apple.quarantine [1] Saving Pd settings on macOS *used* to be slow (multiple seconds) as each setting was written individually using `defaults` from C. This was more an issue of making multiple system calls rather than an issue with `defaults`. I replaced that with using the Apple Foundation C API instead and it's very fast now. ;) > On Jun 2, 2024, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Sun, 2 Jun 2024 10:40:16 +0200 > From: IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] slow startup on macOS > Message-ID: <76936eab-e81f-4b7c-a39d-37ff73c7d8dd(a)iem.at <mailto:76936eab-e81f-4b7c-a39d-37ff73c7d8dd@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/2/24 09:34, Benjamin Wesch wrote: >> On Sun, Jun 2, 2024 at 8:45?AM IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> wrote: >>> [...] replace the dynamic reading of ::pd_guiprefs::domain >> >> without really understanding the whole mechanism: isn't this already >> defined here then? >> https://github.com/pure-data/pure-data/blob/master/tcl/pd_guiprefs.tcl#L21 > > yes. (as i said: there should be some fallback mechanisms in place). > > >> >>> or probably just remove the lines 72-76 >> >> both options work for me. >> > > thanks for confirming. > i've created a PR [2331] for the fix. > CI-builds should be available soon. > > > [2331] <https://github.com/pure-data/pure-data/pull/2331> -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list June 2024