Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

Re: [PD-dev] [PD] double precision merged
by IOhannes m zmoelnig 26 Feb '20

26 Feb '20

(i'm not sure how this ended on pd-list, m oving it back to pd-dev) On 25.02.20 23:53, Dan Wilcox wrote: >> On Feb 25, 2020, at 11:41 PM, Christof Ressie wrote: >> >> I think there's no configure flag (yet). In the meantime you can >> compile Pd with >> >> make CPPFLAGS="-DPD_FLOATSIZE=64" > > I'd suggest --enable-double or --enable-double-precision > TL;DR adding a configure-flag opens a whole can of worms that are not related to double-precision long version: the reason why i have not added a configure flag to enable/disable double-precision builds is, that i was not satisfied with the implications of such a flag. enabling a feature via a configure-flag is (at least for me) a way of saying that "from now on, whatever i do with the so-generated project (Pd) will have this feature enabled". however, this is not the case in for a double-precision build. why? a double-precision Pd changes two fundamental things: - the precision of the Pd-core - the interface to externals the former is obvious, as this is what double-precision is about. the latter is not a problem per se, as we have taken steps to make sure to neither break API (so you can compile any well-written external with double-precision) nor ABI (so externals built for one precision won't fail *catastrophically* in a runtime of a different precision). however, the main expectation from any API is, that if you compile something against a given version of header-files, then the result outght to work *flawlessly* (which is much more strict than "not catastrophically") with the corresponding runtime (of the same version). with double-precision this is currently *not* the case: if you build Pd in double-precision mode, its headers will still be identical to a single-precision build. compiling an external against these headers will therefore produce a single-precision binary - which will not work properly in the double-precision Pd. if we want to pass the selected precision on to the entire ecosystem that depends on a given Pd runtime (that is: all externals that are built against a specific version of Pd), than the only solution is to replace the default value for PD_FLOATSIZE in m_pd.h. i have not done that, because traditionally Pd never modified (or generated) any headers during build. implementing that would not be hard, but it would be a major change in the build-system, which i didn't feel like proposing or even discussing (and i'm sure there are zillions of pitfalls where such a change would result in failing builds). otoh, adding a pre-processor flag to the build process is much more ephemeral. it basically says "i'm hacking some properties of the build-system to do what i want". nobody^Wi wouldn't expect such a temporary hack to be picked up by any external that happens to build against the given runtime (unless of course i apply the same or similar hack to those externals). which is exactly what we get with the current way to enable double-precision. the actual overhead for compiling a double-precision build is not that high. cf > configure CPPFLAGS="-DPD_FLOATSIZE=64" vs > configure --enable-double-precision mfgasdr IOhannes PS: i'm absolutely sure i write this up before (months, years ago?) but cannot find it anymore :-(

4 7

Re: [PD-dev] [PD] double precision merged
by Alexandre Torres Porres 26 Feb '20

26 Feb '20

Em ter., 25 de fev. de 2020 às 20:44, Alexandre Torres Porres < porres(a)gmail.com> escreveu: > I was expecting to see huge numbers in the atom boxes and print, but I > still get it with the same resolution as before. > So, does it mean we still have single precision on floats?

3 6

Re: [PD-dev] PRs for 0.51 (was: macOS direct plist reading)
by Dan Wilcox 25 Feb '20

25 Feb '20

As a note, I will finalize the soundfile updates by then, if you want to take a look at them. > On Feb 24, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Sun, 23 Feb 2020 18:01:14 -0800 > From: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > To: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > Cc: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] PRs for 0.51 (was: macOS direct plist reading) > Message-ID: <20200224020114.GA17561(a)ucsd.edu <mailto:20200224020114.GA17561@ucsd.edu>> > Content-Type: text/plain; charset=us-ascii > > Well, I didn't get through all the PRs in December (by a long shot) - and my > next good block of time to work on this isn't til beginning of April. So > hopefully msometime this spring. > > cheers > Miller -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 9

macOS direct plist reading
by Dan Wilcox 24 Feb '20

24 Feb '20

Howdy all, Pd's start time on macOS has always felt a bit *slow*. Recently, someone on the pd-list noticed starting Pd with -noprefs helps a great deal. I did some digging and the core basically performs a system call to the "defaults" command for *each* key/value in s_file.c, including a stat() check if the preferences file exists. That's a good amount of filesystem IO and probably explains why it takes *3-4 seconds* on my machine. For a proposed update to fix this, I just got some code working which reads the plist into a dictionary object directly using the macOS CoreFoundation framework (all C). Reading keys and values is then much faster and Pd starts up almost instantaneously now. Next step would be to updating preference saving as well. I hope to finalize this and put it up as a PR in a week or two for testing. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 9

MSYS2 Portable and PD
by Henri Augusto Bisognini 20 Feb '20

20 Feb '20

Hey list! How are you? I'm trying to compile PD in a Win 10 computer using MSYS2 portable. I've did it exactly the same steps as when I've installed MSYS2 on my Win 7 pc. When running ./configure I've got an error configure: error: no acceptable C compiler found in $PATH "Makes sense", i think. This is an portable version after all. So I've added D:\software\msys2\mingw64\bin to the Win 10 %PATH% variable. Got the same error. Then I've added d/software/msys2/mingw64/bin to MSYS2's $PATH and still got the same error. To add to $PATH I've used : export PATH=$PATH:d/software/msys2/mingw64/bin Anybody have any clues in what is going wrong? Full output of ./configure : configure: loading site script /etc/config.site checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests configure: Android SDK only available for arm-linux hosts, skipping tests checking for as... no checking for dlltool... no checking for objdump... no checking how to print strings... printf checking whether make supports the include directive... yes (GNU style) checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/e/Users/User/Desktop/Software/PureData/pure-data-0.49-0-kbd': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details

1 1

Bit fields in t_editor
by Henri Augusto Bisognini 14 Feb '20

14 Feb '20

Quick C question: i was taking a look at struct _editor and I've noticed that the bitfields sum up to 6 with no (2 bits) padding for alignment. typedef struct _editor { t_updateheader e_upd; /* update header structure */ [...] unsigned int e_onmotion: 3; /* action to take on motion */ unsigned int e_lastmoved: 1; /* one if mouse has moved since click */ unsigned int e_textdirty: 1; /* one if e_textedfor has changed */ unsigned int e_selectedline: 1; /* one if a line is selected */ t_clock *e_clock; /* clock to filter GUI move messages */ int e_xnew; /* xpos for next move event */ [...] } t_editor; All the resources I've found on google used some padding (either manually or with a zero value). My guess here is that since the next member is not a bit field then the compiler will align it for you. Is that right? Cheers, Henri.

3 2

Re: [PD-dev] Tips on debugging dip crashes?
by Dan Wilcox 09 Feb '20

09 Feb '20

That's good to know. Something seemed funny about that cast and I figure it was a left over while the other sample conversion functions were updated. It's probably one of those things that worked fine for a long time but was never explicitly allowed to work. Reminds me of parts of Pd. :) I'm not super familiar with C++14 & C++20, so it's good to know. > On Feb 9, 2020, at 2:29 AM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Sun, 9 Feb 2020 02:29:49 +0100 > 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] Tips on debugging dip crashes? > Message-ID: <f1514d4a-dc01-cb71-f271-98e53ca7a629(a)christofressi.com <mailto:f1514d4a-dc01-cb71-f271-98e53ca7a629@christofressi.com>> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > >> by applying a union used in one part of the code to another to > replace a dereferencing cast > > Type punning via pointer casts often violates the "strict aliasing > rules" and the compiler might do wonky optimizations. Type punning via > unions, on the other hand, is explicitly allowed in C. It is *not* > allowed in C++, although in practice I haven't encountered a case where > it didn't work. (The legal way to do type punning in C++ has been > memcpy() , which gets fully optimized away; C++20 finally has > std::bit_cast()). > > You probably know this anyway. Just writing for other people who are > reading :-) > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] Tips on debugging dip crashes?
by Dan Wilcox 09 Feb '20

09 Feb '20

The stack trace was really not that useful, but I did look into the dip-specific functions. In the end I think I fixed it, but I'm not 100% sure how. I did some simple cleanup in the float sample conversion by applying a union used in one part of the code to another to replace a dereferencing cast. That seems to have helped, at least in my testing so far. > On Feb 8, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Sat, 8 Feb 2020 11:06:30 +0100 > 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] Tips on debugging dip crashes? > Message-ID: <99ab2074-1961-26c3-7d75-1de6067435f6(a)christofressi.com <mailto:99ab2074-1961-26c3-7d75-1de6067435f6@christofressi.com>> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Hi Dan, > > if you're accidentally writing beyond the stack, then the backtrace > becomes useless. You can notice this by looking at the function > addresses/names. If they have low addresses like 0x9 or don't show a > name (although Pd is built with debug symbols), than this is strong > indication for a stack overflow. Sometimes GDB will detect a stack overflow. > > Two things you can do: 1) set appropiate breakpoints in the debugger to > find out where it crashes 2) good ol' printf-debugging :-) > > I'm currently working on a complicated external and I highly appreciate > the visual debugging tools IDEs like QtCreator give me. > > Maybe you can post the stacktrace? > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Tips on debugging dip crashes?
by Dan Wilcox 08 Feb '20

08 Feb '20

Howdy all, I've been working on an update to Pd's sound file handling. There is a bug with 32 bit file playback which causes an immediate crash when DSP is on. The backtrace is not very helpful as it just unwinds Pd's main DSP loop. Are there any tricks to help debug this situation? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

array/table and canvas memory management
by x nor 30 Jan '20

30 Jan '20

I'm working on an external that loads analysis data into tables for use in re-synthesis and I want to make sure I'm not going to be leaking memory with this approach. I'd like to be able to load several sets of tables with a single object, and then access that data with an arbitrary number of resynthizers. So my question is: if I allocate an array/table in an external, do I have to manage its de-allocation or is there some sort of reference counter? How about with canvases? If I create a canvas per analysis data set, do I have to manage the canvas de-allocation? If I de-allocate an array (inside a canvas I create in code or not) and some other object is using that array, what happens? Thanks, Ale

3 5

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