Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

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 03 Jun '24

03 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

pd 0.55 status
by Miller Puckette 20 May '24

20 May '24

To Pd dev - I've gone ahead and pushed 0.55-0test3 to github in hopes it will work OK. I think I've fixed the startup order problems, but two problems remain... 1. startup is noticeably slower than 0.54 on MacOS. I've been trying to track this down, and pushed a branch to git that should have improved the startup time but I don't see any improvement on my Mac. OTOH, when I compile Pd locally it starts up noticeably faster than either 'master' or 'startup-order' branches compiled in the online CI system. I'm baffled but will keep trying to figure this out. Second, and more serious, on Mac Pd now hangs if you save an audio device and then restart Pd without the saved audio device connected. This might be generally true when starting Pd with "no audio device" - I haven't managed to look more closely at this. Once you switch Pd to an existing audio device it un-hangs. Meanwhile I'm working on a production this week so will have limited time to look at these til next weekend. cheers Miller

4 4

portmidi update
by Dan Wilcox 15 May '24

15 May '24

Howdy all, I noticed Miller needed to make a change to the portmidi sources and that the update script is out of date as it still uses the old Portmidi Sourceforge SVN link. I have updated the script to now use the active Portmidi Github repo and made a PR: https://github.com/pure-data/pure-data/pull/2305 As it's late in the release process, I haven't updated the sources themselves yet as I first wanted to check that the macOS midi rate limiting patch is still being applied successfully. This is the only major patch we need to apply for now. @Cyrille: Can you check that this macOS arm64 build sends & receives MIDI ok? I believe you first noticed the issue back around 2018. http://docs.danomatika.com/pdbuilds/0.55/Pd-0.55.0-pm-no-ratelimit.zip -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

trouble with Pd version strings
by Miller Puckette 12 May '24

12 May '24

I almost pushed out a test release and then found out that "about Pd" gives insane version strings like this: Pd version 0 #define PD_VERSION_CODE PD_VERSION(PD_MAJOR_VERSION, PD_MINOR_VERSION, PD_BUGFIX_VERSION).54 #define PD_VERSION_CODE PD_VERSION(PD_MAJOR_VERSION, PD_MINOR_VERSION, PD_BUGFIX_VERSION).1 #define PD_VERSION_CODE PD_VERSION(PD_MAJOR_VERSION, PD_MINOR_VERSION, PD_BUGFIX_VERSION) I'm pretty sure the culprit is "Makefile.am" in pd/doc: # get version info from m_pd.h to use in doc/1.manual/1.introduction.txt PD_MAJOR_VERSION = $(shell grep PD_MAJOR_VERSION $(M_PD) | \ sed 's|^.define *PD_MAJOR_VERSION *$[0-9]*$.*|\1|' ) [...] This is catching the definition of PD_VERSION_CODE in m_pd.h ... I couldn't immediately figure out how to fix the ugly Makefile.am stuff, and anyway the whole thing feels fragile to me. What if we change PD_VERSION_CODE to PD_CODE_VERSION ? Will that cause anyone trouble? cheers Miller

4 7

Re: [PD-dev] ready to release 0.55 test version?
by Alexandre Torres Porres 10 May '24

10 May '24

Sent this last one only to miller, so I am also sending here On Mon, 6 May 2024 at 15:39 Alexandre Torres Porres <porres(a)gmail.com> wrote: > Ok, then I see that 0.55 is coming real soon :) > > > All this is worth continuing to think about. > > Let's keep thinking about [clip~] then please. I did get rid of the one in > Cyclone thinking and assuming vanilla's could also take signal inlets and, > better yet, offer multichannel expansion. What would be the problem with > it? In my PR I was careful to add different DSP states for whether there > are signal connections or not (like [lop~]), so it uses the same slightly > more efficient algorithm if no signals are connected. > > And since the clock is ticking, and also about multichannel goodies, I > wanna move on in my wish list to lobby for adding signal comparison/logical > operators https://github.com/pure-data/pure-data/pull/2054 seems like a > very good feature addition for 0.55 and easy to take. I agree with > Christoph that it is a bit silly that we currently need externals (zexy, > cyclone) or [expr~] for these basic math operations, and he makes a strong > point that these are (still) single channel. I can say I don't have plans > at all to add multichannel awareness to Cyclone's objects, and that like > [clip~] I would gladly deprecate them in favor of Vanilla objects. So > please consider this as well. > > Thanks > > Em seg., 6 de mai. de 2024 às 14:27, Miller Puckette < > mpuckette(a)cloud.ucsd.edu> escreveu: > >> I'm putting it off because I think it will do just fine in 0.56 :) >> >> On 5/6/24 19:16, Alexandre Torres Porres wrote: >> > Em seg., 6 de mai. de 2024 às 14:01, Miller Puckette >> > <mpuckette(a)cloud.ucsd.edu> escreveu: >> > >> > Well, I need to get this release out - ther's stuff in there >> > that's way >> > overdue. >> > >> > >> > What about the other features and ideas you had in mind for this >> > release, like a message to Pd to toggle between GUI and no-GUI and >> stuff? >> > >> > cheers >> >

4 7

libpd Makefile still doesn't clear extras (aded note now)
by Dan Wilcox 10 May '24

10 May '24

Howdy all, I *thought* I fixed this, but libpd/Makefile in the pure-data repo (not the separate libpd repo), still does not correctly clear the object files out of the extra subdirectories, ie. extra/bob~/bob~.o, etc. In any case, I pushed a small commit to the develop branch adding a note about this to readme. I don't feel like figuring out the VPATH trickery to properly fix this. In the separate libpd repo Makefile, we use full paths. ;) -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

← Newer
1
2
3
4
5
6
7
...
962
Older →

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