Pd-dev August 2023

pd-dev@lists.iem.at

13 participants
10 discussions

Re: [PD-dev] comport "pollintervall" option
by Dan Wilcox 29 Aug '23

29 Aug '23

From the comport 1.2 help file: > On Aug 29, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Mon, 28 Aug 2023 13:33:32 +0200 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] comport "pollintervall" option > Message-ID: <6a883c6ecb57904edc045fb363e15d27882c9da7.camel(a)gmail.com <mailto:6a883c6ecb57904edc045fb363e15d27882c9da7.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > On Mon, 2023-08-28 at 10:49 +0200, Dan Wilcox wrote: >> >> I am working on a project and am using the [comport] object. I >> noticed it has an option named "pollintervall" and my OCD on such >> things wonders if this can be "pollinterval" without the extra 'l' >> since the word is "interval". I wouldn't remove the original but add >> the second, possibly with a post to suggest the original is >> deprecated etc. > > ?? > > Roman -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

comport "pollintervall" option
by Dan Wilcox 28 Aug '23

28 Aug '23

Howdy all, I am working on a project and am using the [comport] object. I noticed it has an option named "pollintervall" and my OCD on such things wonders if this can be "pollinterval" without the extra 'l' since the word is "interval". I wouldn't remove the original but add the second, possibly with a post to suggest the original is deprecated etc. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

signal division with scalar values
by Matt Barber 26 Aug '23

26 Aug '23

Hello, I'm finding some bugs in patches due to the different implementation of division in the scalar versions of the /~ object. The scalar versions precalculate the reciprocal of the scalar and then multiply by the incoming signal vector. The problem is that in floating point, y*(1/x) is not always equal to y/x. In fact, for some floats, x*(1/x) is not always equal to 1.0f, which can cause problems for e.g. wrap~. It's possible to work around by using sig~, but as far as I know it's not in the documentation. [image: image.png]

1 0

why must one never send a message from a perform routine ?
by Joseph Larralde 24 Aug '23

24 Aug '23

Howdy, I just read in an answer from Christof to Alexandre : "never ever send a Pd message directly from a perform routine ! Always use a clock !" But I never took the time to deeply understand Pd's inner working and am not sure why it is bad practice. Not sure what could be the consequences of doing this, but it might explain a random bug I've been experiencing with one of my externals. I wrote a couple of plugins with juce so I'm aware of the most basic good lock-free programming practices in C++ (which seems to boil down to : use atomic variables in C++, or a lock-free queue if needed). Could Christof's advice be related to threading issues ? I thought I'd read somewhere that everything was running on the same thread in Pd (at least the "backend", maybe not the GUI), but please correct me if I'm wrong. Also, I'm having a hard time finding any doc about clocks, is there a known object that uses them that I could take as an example ? Sorry if this has been brought up before (which is probably the case), and thanks in advance for your enlightenments. Cheers, Joseph Larralde -- freelance developer www.josephlarralde.fr

5 16

Re: [PD-dev] why must one never send a message from a perform routine ?
by Dan Wilcox 23 Aug '23

23 Aug '23

Joseph: Do not be embarrassed. Understanding the engine is relatively opaque IMO and info is scattered in different places. Christof: IMO these kinds of important details should really by in m_pd.h. The API is pretty stable at this point, so it would pay to fill out the header. This was my approach with libpd: https://github.com/pure-data/pure-data/blob/master/src/z_libpd.h We originally had docs for libpd on a wiki page but once things stabilized I did the painful, but IMO necessary, step to move it into minimal header documentation. This also made it trivial to include basic docs when libpd was integrated into the pure-data repo. > On Aug 23, 2023, at 5:05 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 23 Aug 2023 17:04:41 +0200 > From: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] why must one never send a message from a perform > routine ? > Message-ID: <7a96c4d0-10ec-1d18-b016-df0304498623(a)christofressi.com <mailto:7a96c4d0-10ec-1d18-b016-df0304498623@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Glad that I could help! Very little of this is really documented > (accurately). Personally, I figured this out by reading the source code. > > Ideally, we should improve the official documentation in > http://msp.ucsd.edu/Pd_documentation/x3.htm#s1.0. Some things are > outdated, misleading or just plain wrong (in particular the section > "audio buffer size and block size"). I just put this on my > (ever-growing) TODO list. > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 3

switching app-id to info.puredata.pd?
by IOhannes m zmölnig 14 Aug '23

14 Aug '23

hi, i've played a little bit with getting Pd up on flatpak (yet another linux package manager), and currently the major showstopper is the app-id (:facepalm:) the app-id is just a unique identifier for an application, that is based on some (reverese) domain scheme. the app-id is used in a number of places, and for flatpak the app-id *must* match what we have in the "metainfo.xml" file. our "metainfo.xml" file is "org.puredata.pd-gui.metainfo.xml" (found in the linux/ folder). which means that the app-id is "org.puredata.pd-gui". even though normally the app-id is not very visible to the user, i am sure that i DO NOT want the "pd-gui" part in there (for the full Pd application). i have no idea what came over me when i picked this id when i added that file to the repository (because obviously it was yours sincerely who did that). anyhow. since i am about to change this id to some meaningful value, i wonder *which* would be a good one. the obvious choice is "org.puredata.pd" (removing the "-gui" part). now, i wouldn't write this email if i had no concerns about this name(and instead i would just change it). my issue is that this id is depending on the ownership of "puredata.org". now, "puredata.org" is gratefully sponsored to the Pd-community by A.van de Ven (at least it was, last time i was able to check; in the meantime you can no longer check who registered a domain...). while i'm really thankful for this, it also has a few problems: - avdv is not a really active member of the community (afaIk). in fact, it's rather hard to get in contact with them. the last record of a successfull contact between the two of us has been in...2007 or so. the last status i had was that avdv is willing to "perpetually sponsor" the domain, but eternity has become short in these days, and i don't know what will happen if anything ever happens to avdv (so let's hope for the best) - "we" do not really control the nameservers. right now they are setup so that any requests for "puredata.org" or any subdomain thereof just points to the iem's IP address (that runs puredata.info). this kind of works, but only as long as we can serve everything from this IP. i vaguely remember a problem due to this non-control of the nameservers with the libpd-for-android (or -ios?) packages a couple of years ago. otoh, "puredata.info" is owned by the iem (my university). while this is very practical for me ("master of the dns" and what not; my bus-factor is another problem in this context, but let's talk about that another time), the real benefit is that the university is not likely to go away within the next decades. unis typically last longer than mere humans/mortals. so my question is: could (and should) we switch the app-id from "org.puredata..." to "info.puredata...", just in case we ever need to *prove* that "we" actually own the domain. there are of course caveats: Pd uses the "org.puredata" namespace for storing settings: - the GUI settings (on all platforms) - on macOS it is used for storing the "normal" Pd-settings as well so changing the namespace to "info.puredata" will discard all settings. what do you think? gamsdr IOhannes

3 2

Closing old Github issues
by Dan Wilcox 12 Aug '23

12 Aug '23

Howdy all, I have Github notifications turned off on the main pure-data repo (otherwise I would go crazy), but I do check now and then. We have almost 400 open issues, many of which go back 5 years or so. Can we go through and close things which have been resolved or are simply inactive? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD-dev] switching app-id to info.puredata.pd?
by Dan Wilcox 11 Aug '23

11 Aug '23

I have thought about this before and yes I would do it, as long as the .info is and will be the main domain for the foreseeable future. We should consider adding a detection mechanism that checks if the new settings exist and, if not, imports the old settings. Perhaps this can be a dialog which pops up asking if the import is desired? In any case, a transition should be well-communicated so no one is surprised, ie. I have some scripts to swap out configurations which expect a certain path, etc. > On Aug 11, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > so my question is: could (and should) we switch the app-id from > "org.puredata..." to "info.puredata...", just in case we ever need to > *prove* that "we" actually own the domain. > > there are of course caveats: > Pd uses the "org.puredata" namespace for storing settings: > - the GUI settings (on all platforms) > - on macOS it is used for storing the "normal" Pd-settings as well > > so changing the namespace to "info.puredata" will discard all settings. > > > > what do you think? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

is "dsp_addv" ready for multichannel?
by Alexandre Torres Porres 09 Aug '23

09 Aug '23

Hi, I am having a hard time using "dsp_addv" with a multichannel external. I am trying to make a multichannel version of [else/xgate~], which routes a signal to different outputs with crossfading. It originally uses "dsp_addv" so it can have a DSP routine with a variable number of outlets, which is specified by an argument. So now I want these outlets to output multichannel signals and I have run into trouble before trying to use "dsp_addv" with multichannel signals. I was able to avoid it before but now I can't and I wanna be sure before I try it. thanks

2 3

compiling externals with gnu gsl library
by Vinicius Cesar 09 Aug '23

09 Aug '23

I'm trying to compile an object with pd-lib-builder that uses the gnu gsl library on the code. I would like to compile this object in a way that the gsl library stays statically linked so it could run on other computers without the need to install the gsl. How can I do this using pd-lib-builder? Thanks!

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 August 2023