Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

tilde object rework ideas
by Miller Puckette 03 Sep '22

03 Sep '22

Hi Pd dev - I'm preparing to rework the DSP network to give tilde objects more control over their inputs and outputs, for instance allowing for multi-channel signals and to allow objects to decide for themselves whether to promote float inputs to signals (so that you don't have to say "+~ 0 to get the faster version, and so that I can make the hip/lop/bp/vcf frequency and Q inputs available as signals or as floats). Of course I mean to make this compatible with existin DSP objects, although for simplicity I'm going to propose one slightly risky move, changing the size of the t_signal structure -- as iohannes mentioned a few years ago, this seems very unlikely to break anyone's tilde objects. The new structure would now look as follows: typedef struct _signal { int s_n; /* *TOTAL* number of points in the array */ t_sample *s_vec; /* the array */ t_float s_sr; /* *TOTAL* samples per second */ int s_refcount; /* number of times used */ int s_isborrowed; /* whether we're going to borrow our array */ struct _signal *s_borrowedfrom; /* signal to borrow it from */ struct _signal *s_nextfree; /* next in freelist */ struct _signal *s_nextused; /* next in used list */ int s_vecsize; /* allocated size of array in points */ /* *** NEW STUFF *** */ t_float s_rate; /* sample rate */ int s_length; /* number of points in each channel */ int s_nchans; /* number of channels */ int s_overlap; /* number of times each sample will appear */ } (one question about this... I _could_ take a sightly bigger risk and put the last 3 fields ahead of s_refcount, etc, which I don't think anyone should be using... this would make things look cleaner). For example, the FFT object's outputs should really have a sample rate of 1/N times the input sample rate, a vector length of 1, and a channel count of N. For compatibility, I'd take the "s_n" field to just be N, although in the future one could optionally use s_length as N and run as many DFTs as there are channels. (This would be incompatible with current practice in wierd situations in which one ran an fft~ objects into another fft~ objects as input - a real bad idea but perhaps the only way in vanilla to time-reverse a signal block by block, so I bet someone is depending on being able to do that :) Meanwhile, before the DSP routine is called, all signal inputs are populated with vectors by promoting float inputs to signals, all inputs are guaranteed to have the same s_n field, and all outputs are automatically generated to match all the inputs. I want that to be the default option but to allow the object to access non-matching signals, not-filled-in signals (so that it can schedule scalar versions, as in "+~", and to take care of generating its own output signals (which may thus have different sizes from the input signals). I could then design a "trunk~" object that combines or splits one-channel signals into multichannel ones, and I could extend +~, etc., to know how to add one-channel signals to multichannel ones. Also, clone~ could (optionally) unpack multichannel signals to distribute among copies. it might also be useful to have the option to ask for the output signals, if auto-generated, never to reuse the same vector as the input; I guess that can be provided if there's a demand for it. I'm thinking this is a big enough and dangerous enough change that I should do it on a separate branch first. I've got some travel coming up but hope to start coding soonish. cheers Miller

5 6

Re: [PD-dev] tilde object rework ideas
by Dan Wilcox 02 Sep '22

02 Sep '22

Howdy Miller, Multi-channel will be very useful, especially in the context of some of the sound spatialization work we have used libpd for at ZKM. A good idea from Ableton/Max which we can profit from as well. :) I agree with the naming suggestion from IOhannes. The CoreAudio API also uses "frames" in it's AudioStreamBasicDescription struct: https://developer.apple.com/documentation/coreaudiotypes/audiostreambasicde… <https://developer.apple.com/documentation/coreaudiotypes/audiostreambasicde…> I don't mention CoreAudio to say we should slavishly copy it, but I find the API pretty well designed in abstraction and naming. I think "s_frames" would be equivalent to "mBytesPerFrame". > On Sep 2, 2022, at 9:36 AM, pd-dev-request(a)lists.iem.at wrote: > > apart from that: > probably "s_length" might be called "s_frames" as this seems to be the > less ambiguous term. > > and i would personally prefer "s_samplerate" and "s_channels". > that would make for an easy distinction: the abbreviated names "s_n" and > "s_sr" are the convoluted ones, whereas the long names have the data > you'd expect. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Saving comments
by David Rush 16 Aug '22

16 Aug '22

Soo...I'm getting really tired of directly editing my *.pd files to escape the newlines in my comment objects so that they stay readable when I restore the canvas. After reading into the code, this looks like the root cause is the insistence on using a binbuf as an intermediate representation for the literal text. So I have two questions: 1 - is this a thing that anyone actually cares about? 2 - are there any known pitfalls to adopting a more literal intermediate representation? re question 2: I've not really read through the entire parser, but I recognize that there is meant to be some compatibility with the TCL reader. TCL *can* represent complex string literals, so can that facility be leveraged, or would that have to be brought into the general PD patch parser (with all of the attendant complications) - d -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

1 0

How to solve -Wcast-function-type when pass A_GIMME for arguments
by Charles K. Neimog 24 Jul '22

24 Jul '22

Hi Everyone, I am having a warning about -Wcast-function-type when I pass an A_GIMME, in myObject_new. My question is, without suppressing it, have some way to solve the warning? - I saw this: https://stackoverflow.com/questions/59041367/silence-wcast-function-type-on…, but I could not understand it, I am really start to learn how C work. - I know that the object work, but I have a curiosity about it! Thank you!

1 0

Can't upload package with deken
by Alexandros 30 Jun '22

30 Jun '22

I'm trying to upload a new package with deken, but I get the following error: ModuleNotFoundError: No module named 'hy' I do have a module called "hy" in my python packages though. The deken installed on my system is version 0.6.0. Is it possible it's outdated? I saw the discussion about the latest deken, so I downloaded the source and tried to make it, but nothing really happened. I'm on UbuntuStudio 21.10.

3 6

Re: [PD-dev] Compiling fat external binaries for Mac OS X
by Dan Wilcox 17 Jun '22

17 Jun '22

Safest way is to statically link everything into the external itself. Yes, this makes it huge but that's the *safest* method. Next method is to bundle the libs *with* the external *and* modify the externals' lib search path (RPATH) to check a local location first so the system loader will find your dylibs. Both methods are what macOS .app bundles do: either statically link *or* ship the dylibs inside the bundle. That being said, if the libs require internal APIs which change between macOS versions, then you may have to consider separate builds. However, despite all of the FUD mostly from people who don't use the platform often, Apple clearly deprecates APIs long in advance. The only libs that are generally *safe* to link to across macOS versions are libraries included with the system such as libxml2... but I would say that is about the only C system lib that I have directly linked to in *any* software I have written for macOS, that is beyond the internal Obj-C / Swift frameworks. I generally recommend *against* asking users to install libs via Homebrew. macOS is not Linux and Homebrew is not apt. Homebrew is heavily oriented towards developers and lib versions change pretty dynamically. There is no guarantee the lib you linked again on your build machine will match that of whatever version of macOS & Homebrew a user has. I have tried this approach with macOS .app bundles at work and only run into problems. For Homebrew to be a viable option, the best way is to require users to install the libs via Homebrew and build the external themselves. This is basically what HB is designed for, however, I assume this is what you are trying to avoid. That same goes for trying to pull a dylib from Homebrew and bundling it within your .app. I only ran into problems with as well and have generally written scripts or Makefiles to build all of my dependencies manually for distribution. Linking to a static version *may* work, but you still may run into issues if you require a *specific* version of the lib. > On Jun 16, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Would it be better for externals shipping with local dependencies to > provide them as fat binaries? For externals using localdeps I use > separate non-fat files, because they both link to different hard-coded > paths. I wouldn't how to do it differently. > > Is there a best way for shipping externals with local dependencies? If > yes, which is it? > > Roman -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] Compiling fat external binaries for Mac OS X
by Dan Wilcox 15 Jun '22

15 Jun '22

> On Jun 15, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Tue, 14 Jun 2022 14:23:16 +0200 > From: 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] Compiling fat external binaries for Mac OS X > Message-ID: <3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel(a)gmail.com <mailto:3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel@gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote: >> You can simply pass in the arches you want using the "arch" makefile >> variable: >> >> make arch="x86_64 arm64" > > That's cool to know. In the case of purest_json, I believe it ships > with other dependencies (libjson?) and if those come from homebrew, > they're probably not fat. Is my assumption correct, that a fat binary > would have to link to fat binary? I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

Re: [PD-dev] Compiling fat external binaries for Mac OS X
by Dan Wilcox 15 Jun '22

15 Jun '22

In my opinion (and experience), it's easier to make a fat lib. This is how most things are distributed on the platform moving forward. Technically, providing the arches as separate files should be possible but the question comes down to naming and/or separating the distribution in such a way that the system lib loading can find them correctly. With a fat lib build, you don't have to worry about it. I have honestly never bothered to figure out the separate arch, separate lib approach beyond major differences of OS versions ie. macOS 10.6 - 10.9, macOS 10.10+, etc. > On Jun 15, 2022, at 1:32 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Wed, 15 Jun 2022 13:32:09 +0200 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X > Message-ID: <ce868065d84420fd1d5115a34b0f433ba0a82d70.camel(a)gmail.com <mailto:ce868065d84420fd1d5115a34b0f433ba0a82d70.camel@gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2022-06-15 at 12:53 +0200, Dan Wilcox wrote: >> >>> On Jun 15, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at> wrote: >>> >>> Message: 1 >>> Date: Tue, 14 Jun 2022 14:23:16 +0200 >>> From:?reduzent@gmail.com <mailto:?reduzent@gmail.com> >>> To:?pd-dev@lists.iem.at <mailto:?pd-dev@lists.iem.at> >>> Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X >>> Message-ID: >>> <3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel(a)gmail.com <mailto:3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel@gmail.com>> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote: >>>> You can simply pass in the arches you want using the "arch" >>>> makefile >>>> variable: >>>> >>>> make arch="x86_64 arm64" >>> >>> That's cool to know. In the case of purest_json, I believe it ships >>> with other dependencies (libjson?) and if those come from homebrew, >>> they're probably not fat. Is my assumption correct, that a fat >>> binary >>> would have to link to fat binary?? >> >> I don't believe so. I think (not 100%) the system lib loading >> mechanism just needs to find the lib *and* have the right arch. I >> don't believe it matters if the lib is fat or not. >> > > Thanks for the clarification. The interesting question (to me at least) > is: If I want to support both archs, does the linked library need to be > fat, or can I link to two separate files per dependency? If I can't > link to different files for different archs, this means there is no > other way for maintaining support of both archs than to link to a fat > library. > > Roman -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] Compiling fat external binaries for Mac OS X
by Dan Wilcox 14 Jun '22

14 Jun '22

You can simply pass in the arches you want using the "arch" makefile variable: make arch="x86_64 arm64" For example: danomatika@danomatika helloworld % make arch="x86_64 arm64" ++++ info: using Makefile.pdlibbuilder version 0.6.0 ++++ info: using Pd API /Applications/Pd-0.52-2.app/Contents/Resources/src/m_pd.h ++++ info: making target all in lib helloworld ++++ info: making helloworld.o in lib helloworld cc -DPD -I "/Applications/Pd-0.52-2.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.o -c helloworld.c ++++ info: linking objects in helloworld.pd_darwin for lib helloworld cc -undefined suppress -flat_namespace -bundle -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.pd_darwin helloworld.o -lc ++++info: target all in lib helloworld completed danomatika@danomatika helloworld % file helloworld.pd_darwin helloworld.pd_darwin: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64:Mach-O 64-bit bundle arm64] helloworld.pd_darwin (for architecture x86_64): Mach-O 64-bit bundle x86_64 helloworld.pd_darwin (for architecture arm64): Mach-O 64-bit bundle arm64 As to which versions of macOS (that's the official name for some years now) to build on, I believe you can still build the i386 arch with Xcode on macOS 10.15, so judging from the following it may be Xcode 11 or 12: https://xcodereleases.com <https://xcodereleases.com/>. I think Alex Porres is using this set up, so maybe he can chime in with his combo of OS and Xcode. The irony is that you can't run the 32 bit arch on 10.15, but at least you can build for it. Xcode on macOS 11 (version after 10.15) only allows for building x64_64 and arm64. I did add an "automatic" fat lib checker which determines which arch are available for the Xcode version but it's sitting in a PR right now. IN the end, I think I agree with IOhannes that it's maybe better to document and ask the user to set the required arch manually. It certainly keeps things simpler to maintain. The readme should probably be updated with this info as these questions keep resurfacing. > On Jun 8, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 8 Jun 2022 01:18:39 +0200 > From: Thomas Mayer <thomas(a)residuum.org <mailto:thomas@residuum.org>> > To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] Compiling fat external binaries for Mac OS X > Message-ID: <7fd6ada6-3f36-316b-9000-30e0cd64118a(a)residuum.org <mailto:7fd6ada6-3f36-316b-9000-30e0cd64118a@residuum.org>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > I am currently working on the last steps for releasing a new version of > PuREST JSON. > > My main concern is now building fat binaries for Mac OS X. > > When I look at the list at the different versions for 0.52-2 at > https://puredata.info/downloads/pure-data <https://puredata.info/downloads/pure-data> there is a version labeled "M1 > and Intel/64bit". I guess, I should link to it. > > Is there any environment variable I have to set for building building? > > I am using the current master version of pd-lib-builder, and I do not > see any reference to M1 in the block there: > https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6… <https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6…> > > Also, what should be in the filename for deken zips? > > Any other version of Mac OS X that I should compile the external as > well, since there are downloads for 32 and 64 bit Intel as well? > Especially, because the 64 bit version is labeled as OS X 10.7 - 10.9. > > The question about filename of deken zips applies to these as well. > > Thanks, > Thomas > -- > "As long as people kept worrying that the machines were taking over, > they wouldn't notice what was really happening. Which was that the > programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons) > http://www.residuum.org/ <http://www.residuum.org/> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Compiling fat external binaries for Mac OS X
by Thomas Mayer 08 Jun '22

08 Jun '22

Hi, I am currently working on the last steps for releasing a new version of PuREST JSON. My main concern is now building fat binaries for Mac OS X. When I look at the list at the different versions for 0.52-2 at https://puredata.info/downloads/pure-data there is a version labeled "M1 and Intel/64bit". I guess, I should link to it. Is there any environment variable I have to set for building building? I am using the current master version of pd-lib-builder, and I do not see any reference to M1 in the block there: https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6… Also, what should be in the filename for deken zips? Any other version of Mac OS X that I should compile the external as well, since there are downloads for 32 and 64 bit Intel as well? Especially, because the 64 bit version is labeled as OS X 10.7 - 10.9. The question about filename of deken zips applies to these as well. Thanks, Thomas -- "As long as people kept worrying that the machines were taking over, they wouldn't notice what was really happening. Which was that the programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons) http://www.residuum.org/

1 0

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