Pd-list January 2022

pd-list@lists.iem.at

38 participants
55 discussions

Re: [PD] Install path assumptions for [soundfiler] vs [file glob]
by Dan Wilcox 11 Jan '22

11 Jan '22

You can also use [declare -path] to set paths for soundfile ala [declare -path .] etc. > On Jan 11, 2022, at 2:50 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Tue, 11 Jan 2022 14:11:59 +0100 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] Install path assumptions for [soundfiler] vs [file > glob] > Message-ID: <8fa2486ced7b36ea837d36be535d1202ad20bfe8.camel(a)gmail.com <mailto:8fa2486ced7b36ea837d36be535d1202ad20bfe8.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > On Tue, 2022-01-11 at 11:31 +0000, Pierre Alexandre Tremblay wrote: >> Dear all >> >> I am wondering if I my assumptions are wrong, or if there is a >> discrepancy that needs solving (or not.) >> >> Setup: if one installs objects like our flucoma.org <http://flucoma.org/> bundle, one might >> have stuff included in the help, like media files. To make a clean >> install, we have put all of them in a folder called media/ >> >> The behaviour I rely on for the held-files is that [soundfiler] will >> find, for instance, [read -resize media/mysound.wav] (see attached >> file) > > > If 'media' lies near the patch, yes. From what I understand, when given > a relative path to [soundfiler] (and many other objects), it'll try all > search paths, starting with the directory of the path. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Install path assumptions for [soundfiler] vs [file glob]
by Pierre Alexandre Tremblay 11 Jan '22

11 Jan '22

Dear all I am wondering if I my assumptions are wrong, or if there is a discrepancy that needs solving (or not.) Setup: if one installs objects like our flucoma.org bundle, one might have stuff included in the help, like media files. To make a clean install, we have put all of them in a folder called media/ The behaviour I rely on for the held-files is that [soundfiler] will find, for instance, [read -resize media/mysound.wav] (see attached file) First question: am I right to do so (not ethically, but in term of path resolution to installed libraries) — If I am right that it should find the file (as it does), let’s continue: Second question: should [file glob] resolve [symbol media/*.wav] ? Because it doesn’t and that makes me doubt the whole world. — Thanks for your help as usual pa

4 7

(Tcl) UNHANDLED ERRORR: window name starts with an upper-case letter
by hans w. koch 09 Jan '22

09 Jan '22

hello, don´t know, if this is known, but i see it with Pd-0.52-1-really and Pd-0.51-4-macosx: opening the patch E05.chebychev.pd from audioexamples, clicking in the array to display properties and selecting “listview” gives: (Tcl) UNHANDLED ERROR: window name starts with an upper-case letter: "E05-tabArrayWindow" while executing "toplevel $windowName -class DialogWindow" (procedure "pdtk_array_listview_new" line 6) invoked from within "pdtk_array_listview_new .gfxstub7fe688fc4330 E05-tab 0" ("uplevel" body line 2) invoked from within "uplevel #0 $docmds"(Tcl) UNHANDLED ERROR: window name starts with an upper-case letter: "E05-tabArrayWindow" while executing "toplevel $windowName -class DialogWindow" (procedure “pdtk_array_l creating a new patch with an array, starting with a capital (eg Array1) gives the same. weird, ain´t it? cheers hans

2 2

[file]: paths not relative to patch
by Roman Haefeli 08 Jan '22

08 Jan '22

Dear list When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch. This is unusual, as [text], [array], [table], [soundfile], etc. resolve relative paths relative to the patch. Also, I don't quite see the use case for relative to Pd's start. At least, _I_ never cared about where Pd was started from and when working on a patch meant to run on other people's computer I don't make any assumptions about Pd's start location. To me, relative to Pd's start location is pretty useless. Now, it's really unlucky I spotted this only now after 0.52 has been released. Fixing it would break backwards-compatibility. OTOH, the fact this hasn't been reported yet makes me assume [file] with relative paths wasn't used that much yet. If this is going to be fixed, it should be fixed rather soon. Best, Roman

4 16

Re: [PD] [file]: paths not relative to patch
by Dan Wilcox 08 Jan '22

08 Jan '22

I agree with Roman's point that "current working directory" as an idea is different, depending on the user. For some, it will be relative to the patch, for others it will be relative to the shell (and the resulting programs launched by it). I agree it makes technical sense that [file] would be relative to the Pd process, knowing the C api behind it, but for many it's a bit of friction for sure since it's something that now works different from other objects which handle paths implicitly. Additionally, I think it's perhaps a stretch to assume most beginners are aware of how shells and paths work. If it were up to me, I would make [file] work like the other objects and treat relative paths as relative to the canvas. OTOH I know this could complicate the implementation. I think at the very least, this difference needs to be well documented with the requisite canvas-oriented approaches documented. Forgive me if they are already as I've not used [file] yet, but Roman's question indicates to me perhaps not everything is covered yet. ;) Another approach is to provide a very explicit option to get the patch canvas location which fits into the api ala [file patchdir] or [file canvasdir]. I know this is probably redundant to [pdcontrol] but perhaps helps with the distinction..? > On Jan 8, 2022, at 1:07 AM, pd-list-request(a)lists.iem.at wrote: > > Message: 4 > Date: Sat, 8 Jan 2022 01:07:48 +0100 > From: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] [file]: paths not relative to patch > Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d94e(a)christofressi.com <mailto:0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com>> > Content-Type: text/plain; charset=UTF-8; format=flowed > >> If I pass a relative path to such an utility, I want it to resolve to >> the current working directy and *not* to the Pd patch itself. > In practice, I almost wrap such utilities in a shell script anyway and > there I would turn relative path arguments into absolute paths before > passing them on to Pd. But I just wanted to show that the current > directory is not completely useless. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 3

Re: [PD] [file]: paths not relative to patch
by Dan Wilcox 08 Jan '22

08 Jan '22

I assume you already have a relative & absolute path check implementation. If not, I have a simple set of vanilla path abstractions, pre-[file]: p_absolute, p_makeabsolute, p_makerelative, etc https://github.com/danomatika/rc-patches/tree/master/rc <https://github.com/danomatika/rc-patches/tree/master/rc> > On Jan 7, 2022, at 11:35 PM, pd-list-request(a)lists.iem.at wrote: > >> If you want to resolve an >> existing file using Pd's canvas: use [file which]. If you want create >> a >> new file relative to the patch, use [dir( -> [pdcontrol]. > > That's what I do now. That's the easy part. The less easy part is > reliably detecting whether a given path is relative. But knowing that > even Pd does it somewhat clumsily, I'll stick to the clumsy solution > (checking for / and :). -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD] [file]: paths not relative to patch
by Roman Haefeli 08 Jan '22

08 Jan '22

On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote: > > > > And what would you *do* want to use the current working directory? The patch's own directory, like all other file writing objects do. > Generally, [file] doesn't do any magic. I don't consider starting from a sane working directory magic. > If you want to resolve an > existing file using Pd's canvas: use [file which]. If you want create > a > new file relative to the patch, use [dir( -> [pdcontrol]. That's what I do now. That's the easy part. The less easy part is reliably detecting whether a given path is relative. But knowing that even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :). > > > Yeah, this works fine for finding already existing files, but as > > the > > help-file says, you cannot resolve directories with. So, it cannot > > be > > used for > > But that's a general limitation of Pd. At the moment, it can only > resolve files but not directories. This limitation can, of course, > be > removed and then [file which] will work as expection. Thinking about it some more, this isn't a severe limitation. As I understand, it looks into all search paths. However, when I configure 'myblobs' as directory, I don't mean to write to any other 'myblobs' directory that might be returned by [file which]. I think [file which] shouldn't be for finding directories to write new files into. It should only be used for finding existing files. > > I only need to append the > > configured path to the patch's path if the configured path is a > > relative path. But how can I reliably detect that? > I think what we actually need is something like [file isabsolute] > and > [file isrelative]! That would be a trivial but very useful addition. I think those would be valuable additions. Roman

2 4

Raspberry Pi 4 HDMI outputs
by Simon Iten 07 Jan '22

07 Jan '22

Hi list, Has somebody used the two HDMI outs from PD to play two videos on two different screens? I am finding infos from people doing it with omxplayer, but I need it synced and looped. Or are there any other Linux video players that can sync two streams on two different monitors?

6 5

[PD-announce] libpd powered instrument plugin: EXC!TE SNARE DRUM
by Max 06 Jan '22

06 Jan '22

Dear Pd community, in July this year, we, The Center for Haptic Audio Interaction Research (CHAIR for short), released a VST3i plug-in: EXC!TE SNARE DRUM. It's an exciter-resonator physical modelling snare drum syth. The exciter can be triggered via MIDI. The plug-in is a free download. In the PRO version of the plug-in (20€), on top of the MIDI triggers there is an audio sidechain which allows direct excitation of the waveguide resonator. Video here: https://www.chair.audio/product/excte-snare-drum-pro/ The VST3/AU is built using Steinberg's VST3 SDK and libpd. Yes, the audio synthesis is done in Pd. We are quite happy with the overall performance and negligible CPU overhead. We were able to run 70 instances of the plug-in before we started to hear dropouts. Nobody needs 70 parallel snares :) The core of the audio synthesis is open source, in fact you can open Pd, search for "CHAIR" in Deken and get the example patches with the snare drum sound. There is also a paper about the algorithm: "Efficient Snare Drum Model for Acoustic Interfaces with Piezoelectric Sensors" A bit longer story of the plug-in development can be read in our journal article: "EXC!TE SNARE DRUM — Making an Audio Plugin with Pure Data inside" both are to be found here: https://discourse.chair.audio/t/its-science-papers-about-our-work/44 We are thankful that we were able to build upon the work which has gone into Pd (and libpd on top of that). If you have contributed Pd or libpd in any form and would like to try the PRO version of the plug-in, please send me a quick email. Thank you Miller, Dan, IOhannes, Peter, Pierre, Christof, Antoine and everyone else. Max (+ Clemens, Philipp and Sebastian) _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

2 3

Re: [PD] [PD-announce] pd 0.52-1 released
by Dan Wilcox 06 Jan '22

06 Jan '22

Note: You can rename the .app to Pd-0.52.1.app without issue. ;) > On Dec 21, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Mon, 20 Dec 2021 22:36:33 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Cc: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Subject: Re: [PD] [PD-announce] pd 0.52-1 released > Message-ID: > <CAEAsFmi2T7TiakahmzVEQVzk4JXT6CRHt76c0Sia+NNAMV_6PA(a)mail.gmail.com <mailto:CAEAsFmi2T7TiakahmzVEQVzk4JXT6CRHt76c0Sia+NNAMV_6PA@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > awesome, really excited about this one :) > > now, the download I get for macOS 10.10 or later comes as > "0.52-1*-really*.app", > which is really funny. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

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

2001

2000

1999

1998

Pd-list January 2022