Pd-dev

pd-dev@lists.iem.at

9595 discussions

ready for 0.55-1?
by Miller Puckette 22 Aug '24

22 Aug '24

To Pd Dev - What do you think, is it time to put 0.55-1 out? If I don't hear any objections I'll stick out a "test" one Saturday, and maybe the real one in a week or so. cheers M

5 13

Pd 0.55-1 timeline?
by Dan Wilcox 08 Aug '24

08 Aug '24

Howdy all, is there an ETA on 0.55-1? I have been waiting on updating libpd based on the quit message bugfix, among other things. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

How can I split code for one object to more than one .c files?
by Alexandros Drymonitis 07 Aug '24

07 Aug '24

I'm trying to split the source of an external I'm writing to more than one .c files but I'm failing. I have two .h and two .c files, where one pair includes all the Pd specific functions, line new() and setup(). In the Makefile (pd-lib-builder), I include the following line: ``` common.sources = src/dense.c ``` This is the .c file where I want to include part of the code. The object compiles. I even get some warnings about this dense.c file, but when I try to load the object, Pd complains that it can't find certain functions that are included in this dense.c file.

4 9

Can I share object pointers?
by Alexandros Drymonitis 23 Jul '24

23 Jul '24

I'm trying to share pointers between different objects so I can access data of one object from another one. I thought of creating a pointer inlet and a pointer outlet and send the pointer of the data structure out the outlet, receive it in another object through the inlet, and use the received pointer to access the data. I'm copying/modifying the simple counter external from IOhannes' pd-externals-HOWTO, but it's not working. Here's the code I have so far: ``` #include "m_pd.h" static t_class *share_pntr_class; typedef struct _share_pntr { t_object x_obj; t_int i_count; t_gpointer obj_pnt; t_outlet *count_out, *addr_out; } t_share_pntr; void share_pntr_bang(t_share_pntr *x) { t_float f=x->i_count; x->i_count++; outlet_float(x->count_out, f); } void get_pntr_val(t_share_pntr *x) { outlet_float(x->count_out, x->obj_pnt.i_count); } void get_pntr(t_share_pntr *x) { outlet_pointer(x->addr_out, x); } void *share_pntr_new(t_floatarg f) { t_share_pntr *x = (t_share_pntr *)pd_new(share_pntr_class); x->i_count=f; pointerinlet_new(&x->x_obj, &x->obj_pnt); x->count_out = outlet_new(&x->x_obj, &s_float); x->addr_out = outlet_new(&x->x_obj, &s_pointer); return (void *)x; } void share_pntr_setup(void) { share_pntr_class = class_new(gensym("share_pntr"), (t_newmethod)share_pntr_new, 0, sizeof(t_share_pntr), CLASS_DEFAULT, A_DEFFLOAT, 0); class_addbang(share_pntr_class, share_pntr_bang); class_addmethod(share_pntr_class, (t_method)get_pntr, gensym("get_pntr"), 0, 0); class_addmethod(share_pntr_class, (t_method)get_pntr_val, gensym("get_pntr_val"), 0, 0); } ``` This is the error I'm getting: ``` src/share_mem_one.c:21:46: error: ‘t_gpointer’ {aka ‘struct _gpointer’} has no member named ‘i_count’ 21 | outlet_float(x->count_out, x->obj_pnt.i_count); ``` I understand why I get this error, but I can't see how I could share data between objects. Perhaps there's some other way to do that?

2 1

64-bit (and/or ARM) Pd change default cosine table?
by Miller Puckette 09 Jun '24

09 Jun '24

OK, so in a few years every new PC will probably have ARM or other RISC architecture. I just made the interesting discovery that, on Mac ARMs, there is a difference, probably a slight decrease, in numerical accuracy in Pd's DSP objects. So we've lost exact compatibliity and only have pretty-good-approximate compatibility. On one piece I tested the divergence is about -100 dB relative to maximum amplitude and in another, which I think has unstable feedback paths, the results are further off. SO... I can now relax my insistence on exact back-compatibility for osc~ and cos~ and ... make them more accurate! I think I should do this for 0.55. Now for the questions: 1. Unfortunately COSTABLESIZE (512) is declared in m_pd.h. Can I change this value (conditionally, increasing it for 64-bit PDs and for some or all ARM architectures) without breaking externals that might use the built-in cosine table? 2. should I make the table size variable, either by a new [declare] flag, or by passing a flag to osc~ and cos~? This could affect run time - I'd want to investigate that. 3. Alternatively, should I just leave COSTABSIZEE at 512 for specific architectures in non-double (Intel for compatibilty, and possibly RPI if there turns out to be a bad performance hit). I'd choose a new one after doing some profiling because at some point increasing table size will lead to bad cache behavior. (Historical note: the number 512 gives a 4096-point table which is the memory page size of the Intel I860, beyond qhich performance dropped by a factor of 10 or more. Recently I tested a 2048-point table, which is 36dB lower-noise, on a bog-standard Intel Linuix machine and... saw no penalty at all). I'm afraid it will take me (and whoever else is interested in this) some time to figure everything out. But I think at 0.55 we're still at a point where we don't have to be extremely strict about numerical reproducibilty on ARM/Macintosh or on Pd-double, and so this seems a good time to attack this. It's been a long-standing problem. cheers Miller

6 32

Re: [PD-dev] 64-bit (and/or ARM) Pd change default cosine table?
by Sebastian Shader 07 Jun '24

07 Jun '24

Years ago I found that 4096 was the right size for the cosine tables w/ linear interpolation in my externals, if I wanted to not hear any results of artifacts (usually). It was a while ago and I don't exactly remember what audio tests I did tho. anyways +1 for 4096. -seb >Date: Thu, 6 Jun 2024 10:25:50 -0500 From: Miller Puckette <mpuckette(a)cloud.ucsd.edu> To: Matt Barber <brbrofsvl(a)gmail.com>, Alexandre Torres Porres <porres(a)gmail.com> Cc: Christof Ressi <info(a)christofressi.com>, Miller Puckette <msp(a)ucsd.edu>, pd-dev(a)lists.iem.at Subject: Re: [PD-dev] 64-bit (and/or ARM) Pd change default cosine table? Message-ID: <44fd2d44-3601-4c1a-8e88-44516df22797(a)cloud.ucsd.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Well, as far as I can tell making the table "symmetric" won't matter at all since, for instance, 0.1 and 0.9 won't give the same lookup values anyway because they can't themselves be represented exactly and will be truncated differently (0.1 will be more accurately represented than 0.9).? On the other hand, values like 0.25 or -0.5 can be represented exactly so it might be worthwhile to bash true 1s, -1,s, and 0s where they belong in the table. Hearing that Max defaults to a ridiculously big table makes me wonder though... first, is 2048 really enough (and at what point is there a real performance penalty for bigger tables).? And: not for this release but later perhaps, should 64-bit Pd use a bigger table? As I figure it, the 2048-point table differs from the true cosine, absolute worst case, by (2pi/2048)^2 / 8, or about 2(-19.7) - i.e., 19.7 bit accuracy.? But the error is dominated by an amplitude change (the best-matching cosine to the line-segment approximation has amplitude less than 1).? Accounting for that and taking RMS error instead of worst-case gives an error estimate 2.7 bits more optimistic: 22.4 bits, which is close to the accuracy of a 32-bit number. I don't have my RPI3 handy (I'm on the road) but I'm now wondering if the default shouldn't be 4096, which would give us an additional 2 bits of goodness.? Any opinions? cheers M On 6/5/24 9:35 PM, Matt Barber wrote: > A couple of things: > > 1. I'm pretty sure any error in cos at pi and 2pi will be smaller in > double precision than float's epsilon, so I don't think that there's > any need to set -1.0 and 1.0 explicitly after all except to be extra > safe. However, at pi/2 and 3pi/2 the error is still larger than the > minimum normal number, so it is worth setting the zero crossings to 0.0. > > 2. For garray_dofo() there isn't a great way of using explicit 0.0 at > zero crossings without incurring an extra check, like don't add to the > sum if absolute value is less than e.g. 1.0e-10. For this, probably > just using M_PI and incrementing integer phase like for the cosine > table is enough. > > MB > > > On Wed, Jun 5, 2024 at 2:20?PM Alexandre Torres Porres > <porres(a)gmail.com> wrote: > > Em qua., 5 de jun. de 2024 ?s 14:31, Matt Barber > <brbrofsvl(a)gmail.com> escreveu: > > While we're at it, I think it would be worth tuning > garray_dofo() to use the same so that sinesum and > cosinesum?have the same level of accuracy, guarantees of > symmetry, etc. > > MB > > > Good catch! In fact, I think this is a great opportunity to also > fix this bug https://github.com/pure-data/pure-data/issues/371 > <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/3…> > which is totally related. I just reopened > https://github.com/pure-data/pure-data/issues/105 > <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/1…> > as well as I'm still considering the table could/should be still > "perfectly symmetric" considering 0 crossings and the start/end > points. > > > On Wed, Jun 5, 2024 at 12:52?PM Alexandre Torres Porres > <porres(a)gmail.com> wrote: > > For the record and sake of comparison, Cyclone uses > a?16384 points table, and linear interpolation, calculated > with double precision. We did this because MAX documents > it uses such a table, and we made it (well, Matt did) > simetric. > > I see Pd is doing kind of the same, huh? linear > interpolation on a table calculated with double precision. > > I see SuperCollider mentions it uses?8192 points and > linear interpolation on its oscillator. > > I guess MAX is exaggerating its table size a bit :) but I > wonder why Pd is still about to use a relatively smaller > table size. I'm curious to know how much an increase in > table size actually offers a better resolution and how > much it ruins performance. For instance, I'm using the > same as Cyclone in ELSE oscillators, could I just reduce > it at least to 8192 points or even less and down to Pd's > 2048 size worry free? > > Thanks > > > > Em qua., 5 de jun. de 2024 ?s 13:28, Alexandre Torres > Porres <porres(a)gmail.com> escreveu: > > Nice one Matt! > > Em qua., 5 de jun. de 2024 ?s 08:13, Christof Ressi > <info(a)christofressi.com> escreveu: > >> @Miller: what do you think? IMO we should >> make the cos table as good as we can, so we >> won't have any regrets :) >> > +1000!!! > ------------------------------ Message: 2 Date: Thu, 6 Jun 2024 12:51:45 -0400 From: Matt Barber <brbrofsvl(a)gmail.com> To: Miller Puckette <mpuckette(a)cloud.ucsd.edu> Cc: Alexandre Torres Porres <porres(a)gmail.com>, Christof Ressi <info(a)christofressi.com>, Miller Puckette <msp(a)ucsd.edu>, pd-dev(a)lists.iem.at Subject: Re: [PD-dev] 64-bit (and/or ARM) Pd change default cosine table? Message-ID: <CAOrke7GRQ+j7_HV5mSz1hXFqh+BpHaAOZtppFaXM2gN7j8mcyA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Since cos~ wraps, one could theoretically take advantage of the equal distribution of float values between 1.0 and 2.0. Profiling a larger table would be useful ? I prefer accuracy over performance in general, but I wonder where the performance hit would come from, outside of unpredictable cache misses. On Thu, Jun 6, 2024, 11:25?AM Miller Puckette <mpuckette(a)cloud.ucsd.edu> wrote: > Well, as far as I can tell making the table "symmetric" won't matter at > all since, for instance, 0.1 and 0.9 won't give the same lookup values > anyway because they can't themselves be represented exactly and will be > truncated differently (0.1 will be more accurately represented than > 0.9). On the other hand, values like 0.25 or -0.5 can be represented > exactly so it might be worthwhile to bash true 1s, -1,s, and 0s where > they belong in the table. > > Hearing that Max defaults to a ridiculously big table makes me wonder > though... first, is 2048 really enough (and at what point is there a > real performance penalty for bigger tables). And: not for this release > but later perhaps, should 64-bit Pd use a bigger table? > > As I figure it, the 2048-point table differs from the true cosine, > absolute worst case, by (2pi/2048)^2 / 8, or about 2(-19.7) - i.e., 19.7 > bit accuracy. But the error is dominated by an amplitude change (the > best-matching cosine to the line-segment approximation has amplitude > less than 1). Accounting for that and taking RMS error instead of > worst-case gives an error estimate 2.7 bits more optimistic: 22.4 bits, > which is close to the accuracy of a 32-bit number. > > I don't have my RPI3 handy (I'm on the road) but I'm now wondering if > the default shouldn't be 4096, which would give us an additional 2 bits > of goodness. Any opinions? > > cheers > > M > > On 6/5/24 9:35 PM, Matt Barber wrote: > > A couple of things: > > > > 1. I'm pretty sure any error in cos at pi and 2pi will be smaller in > > double precision than float's epsilon, so I don't think that there's > > any need to set -1.0 and 1.0 explicitly after all except to be extra > > safe. However, at pi/2 and 3pi/2 the error is still larger than the > > minimum normal number, so it is worth setting the zero crossings to 0.0. > > > > 2. For garray_dofo() there isn't a great way of using explicit 0.0 at > > zero crossings without incurring an extra check, like don't add to the > > sum if absolute value is less than e.g. 1.0e-10. For this, probably > > just using M_PI and incrementing integer phase like for the cosine > > table is enough. > > > > MB > > > > > > On Wed, Jun 5, 2024 at 2:20?PM Alexandre Torres Porres > > <porres(a)gmail.com> wrote: > > > > Em qua., 5 de jun. de 2024 ?s 14:31, Matt Barber > > <brbrofsvl(a)gmail.com> escreveu: > > > > While we're at it, I think it would be worth tuning > > garray_dofo() to use the same so that sinesum and > > cosinesum have the same level of accuracy, guarantees of > > symmetry, etc. > > > > MB > > > > > > Good catch! In fact, I think this is a great opportunity to also > > fix this bug https://github.com/pure-data/pure-data/issues/371 > > < > https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/3… > > > > which is totally related. I just reopened > > https://github.com/pure-data/pure-data/issues/105 > > < > https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/1… > > > > as well as I'm still considering the table could/should be still > > "perfectly symmetric" considering 0 crossings and the start/end > > points. > > > > > > On Wed, Jun 5, 2024 at 12:52?PM Alexandre Torres Porres > > <porres(a)gmail.com> wrote: > > > > For the record and sake of comparison, Cyclone uses > > a 16384 points table, and linear interpolation, calculated > > with double precision. We did this because MAX documents > > it uses such a table, and we made it (well, Matt did) > > simetric. > > > > I see Pd is doing kind of the same, huh? linear > > interpolation on a table calculated with double precision. > > > > I see SuperCollider mentions it uses 8192 points and > > linear interpolation on its oscillator. > > > > I guess MAX is exaggerating its table size a bit :) but I > > wonder why Pd is still about to use a relatively smaller > > table size. I'm curious to know how much an increase in > > table size actually offers a better resolution and how > > much it ruins performance. For instance, I'm using the > > same as Cyclone in ELSE oscillators, could I just reduce > > it at least to 8192 points or even less and down to Pd's > > 2048 size worry free? > > > > Thanks > > > > > > > > Em qua., 5 de jun. de 2024 ?s 13:28, Alexandre Torres > > Porres <porres(a)gmail.com> escreveu: > > > > Nice one Matt! > > > > Em qua., 5 de jun. de 2024 ?s 08:13, Christof Ressi > > <info(a)christofressi.com> escreveu: > > > >> @Miller: what do you think? IMO we should > >> make the cos table as good as we can, so we > >> won't have any regrets :) > >> > > +1000!!! > > >

1 0

Re: [PD-dev] Whoops, pushed to master
by Dan Wilcox 03 Jun '24

03 Jun '24

I did try a force push *immediately* but since the branch was locked it was rejected. I took that as a sign to revert. I generally avoid force pushing unless the repo is used by me or only a very small number of people. > On Jun 3, 2024, at 9:14 AM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Sun, 2 Jun 2024 23:40:21 +0200 > From: IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Whoops, pushed to master > Message-ID: <35c749e7-60b5-4228-8492-67c0358aca06(a)iem.at <mailto:35c749e7-60b5-4228-8492-67c0358aca06@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/2/24 21:37, Christof Ressi wrote: >> Hi Dan, >> >> On 02.06.2024 14:40, Dan Wilcox wrote: >>> Howdy all, >>> >>> sorry, I accidentally pushed a couple of commits to the master branch. >>> I reverted them after I realized. I suppose there is no clean way to >>> handle this otherwise. >> >> No worries, this has happened to me as well :) In the future, this is >> what you can do: >> >> 1. GitHub: in the repo settings (temporarily) enable force pushing to >> master >> >> 2. git reset <previous_master_head> >> >> 3. git push -f >> >> 4. GitHub: disable force pushing to master again > > > this is what i would do (and have done!) in the same situation as well. > > i was going to suggest that i could do that for dan, but miller has > already pushed on top your reverting commits, so I guess somebody will > have to live with eternal shame (or just keep contributing) :-) -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

external packaging guidelines regarding Pd64
by Roman Haefeli 03 Jun '24

03 Jun '24

Hi Following up the discussion about making Pd64 ready for prime time, I wonder if there is or - if not - if we can make up a few best practices rules regarding the packaging of Pd64 compatible externals. What I gathered so far: * Package both floatsizes together. This allows to switch between Pd and Pd64 without having to re-install a package. * Use the traditional suffix for floatsize=32, eg. ".l_amd64" so that older (floatsize=32) Pd versions still find their externals. * Use new-style suffix for floatsize=64, e.g ".linux-amd64-64.so", that Pd64 tries it first, before it tries the "wrong" one with the traditional suffix. * Don't pack too many archs and floatsize flavors in one package since the resulting filename might hit filename length limit of some filesystem (namely ecryptfs on Linux, but probably others as well) * Dummy bullet point Do those rules make sense? Are there any missing? Then I wonder how to go about existing Deken packages. In order to add Pd64 support, I would like to upload an upstream version that has been already uploaded. If I add only the floatsize=64 flavor as a new package, I violate the first rule. It is ok to upload the same version again, but with both floatsizes? Should the old packages be deleted or will it be automatically overwritten? Or is it mandatory to bump the version? Roman

2 5

d_osc.c needs to define M_PI for Windows
by Dan Wilcox 02 Jun '24

02 Jun '24

Howdy Miller, sorry, I can't make a PR for this right now but just a note: it looks like the CI Windows build fails because Windows does not define M_PI by default, although this might be for an *older* version of Windows/VS. I think it would be safe to check if M_PI exists in d_osc.c then define a reasonable default if not. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 3

Whoops, pushed to master
by Dan Wilcox 02 Jun '24

02 Jun '24

Howdy all, sorry, I accidentally pushed a couple of commits to the master branch. I reverted them after I realized. I suppose there is no clean way to handle this otherwise. In any case, they are small updates to the dialog/preference section headers regarding case usage (for consistency). In this branch now I "un-revert" the now reverted commits on the master branch. Ugg, apologies -> https://github.com/pure-data/pure-data/pull/2332 -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

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