Pd-dev March 2022

pd-dev@lists.iem.at

9 participants
10 discussions

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Dan Wilcox 01 May '22

01 May '22

I have a fork of pd-lib-builder which supports arm64 & universal builds on macOS. The PR has been sitting for some time but we have been using it successfully for a few projects for some time now: https://github.com/pure-data/pd-lib-builder/pull/69 <https://github.com/pure-data/pd-lib-builder/pull/69> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. > On Mar 10, 2022, at 11:30 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Thu, 10 Mar 2022 17:57:23 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Sebastian Shader <sebfumaster(a)aol.com <mailto:sebfumaster@aol.com>> > Cc: "pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: > <CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w(a)mail.gmail.com <mailto:CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I guess I can install catalina on a partition, but I was hoping to use > pdlibbuilder in an easy way, is it possible? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

Doppler effect implementation
by Frodo Jedi 01 May '22

01 May '22

Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested? Cheers FJ

9 15

Re: [PD-dev] call for discussion double-precision file extension
by Dan Wilcox 04 Apr '22

04 Apr '22

I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway. > On Mar 30, 2022, at 5:40 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 30 Mar 2022 16:06:23 +0200 > From: IOhannes m zmoelnig <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] call for discussion double-precision file > extension > Message-ID: <3a9d2e07-a831-eb18-7797-5ff5b191e0b4(a)iem.at <mailto:3a9d2e07-a831-eb18-7797-5ff5b191e0b4@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote: >> >> I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) > > good question. > > afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1 > (but i have no idea, really). > > can we expect developers of PDINSTANCE-enabled (lib)Pds to also provide > the binaries for the extrenals? > i guess it would be nice if you (as a patch-developer with a > compiler-allergy) could just install whatever externals you want to be > included with your camomille-based VST plugin. > > gfmdras > IOhannes -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 8

Re: [PD-dev] call for discussion double-precision file extension
by Sebastian Shader 30 Mar '22

30 Mar '22

As IOhannes says the hope is that somehow externals can simply be dynamically loaded from vst plugins at runtime.(I think I heard camomile might have some other limitations for this with permissions or something right now anyways) an example is plugdata https://github.com/timothyschoen/PlugData which is based on camomile. it would be great if users of the plugin wouldn't have to go about compiling their own externals and/or compiling the plugin themselves, if those other issues are resolved. -seb Date: Wed, 30 Mar 2022 17:45:41 +0200 From: Dan Wilcox <danomatika(a)gmail.com> To: pd-dev <pd-dev(a)lists.iem.at> Subject: Re: [PD-dev] call for discussion double-precision file extension I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway. > On Mar 30, 2022, at 5:40 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 30 Mar 2022 16:06:23 +0200 > From: IOhannes m zmoelnig <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] call for discussion double-precision file > extension > Message-ID: <3a9d2e07-a831-eb18-7797-5ff5b191e0b4(a)iem.at <mailto:3a9d2e07-a831-eb18-7797-5ff5b191e0b4@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote: >> >> I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) > > good question. > > afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1 > (but i have no idea, really). > > can we expect developers of PDINSTANCE-enabled (lib)Pds to also provide > the binaries for the extrenals? > i guess it would be nice if you (as a patch-developer with a > compiler-allergy) could just install whatever externals you want to be > included with your camomille-based VST plugin. > > gfmdras > IOhannes -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

call for discussion double-precision file extension
by IOhannes m zmoelnig 30 Mar '22

30 Mar '22

hi, TL;DR i'd like to suggest to use deken-specifiers as (optional) part of external filenames, in order to allow co-installability of externals of different OSs, architectures and floatsizes (and more to come). i would really love to push the double precision saga towards a (happy) end. we have been able to compile Pd for 64bit double precision numbers. there's even a double-precision variant available in the Debian "experimental" repositories (but who knows that?) *very* few people have started to provide externals (i counted: 4). afaict the biggest hurdle is that you can't really co-install single and double variants of the same external. since there are so few double-precision externals available, people who rely on externals will be forced to use single-precision Pd for some time. but since installing a double-precision external might overwrite an existing single-precision external (required in your other project), i understand why people are not exactly eager to do that.¹ one solution to this problem is to use different installation paths (e.g. ~/Documents/Pd/extra/ vs ~/Documents/Pd/extra64/). this doesn't play well with how deken currently works (as it stores the installation path globally (for all versions/variants of Pd). Lucas suggested to use different file extensions (a year ago...time flies), by inserting `.float64` (and possibly `.float32`) right before our known extension (so we get `foo.float64.m_amd64`) I didn't especially like this back then, but in the meantime i've come to the conclusion that it's probably the best way forward. however, i think that we might do better than just inserting a single `.float64`, and just unify the entire naming scheme to hold all the information we need. i'd therefore suggest to use the deken-specifier together with the native extension (for dynamic-link libraries), as a new extension. the "native extension for dynamic-link libraries" is typically defined on an OS level, and is something like ".dll" on Windows, ".dylib" on macOS and ".so" in the un*x world. the "deken-specifier" is what we use in deken packages to know that they contain binaries for your specific combination of CPU, OS and precision, and looks like "<OS>-<CPU>-<precision>", e.g. "Darwin-arm64-32" (which denotes a macOS binary ("Darwin") that runs on the M1 processor ("arm64") and uses single-precision numbers ("32" bits). this would give us filenames like "zexy.windows-amd64-32.dll" to keep things simple (and reduce the noise with -verbose), i would suggest to only allow lower case specifiers, and no arch variants (e.g. i386 for all x86_32 variants, and amd64 for all x86_64 variants) pros - using the system extension does not require us to invent our own extension for each new platform - system tools often use the file-extension to recognize the file type - deken-specifiers fully cover what we need to know (the problem space is the same for deken package files and externals: allow coexistence of files with multiple OS/arch/precision specs) - people can relate the files within a deken-package with the deken-package-filename - if we ever need to add a new parameter, the deken specifier and the externals are likely to be affected in a similar way, so we need to solve the problem only once. - it gets rid of the super-cryptic .<first-letter-of-the-os>_<cpu-arch> specifier (.o_ia64 anybody?) cons it shares the same (final) extensions as any support libraries. eg. "zexy.linux-amd64-32.so" + "libzexy.linux-amd64-32.so" (or even libzexy.linux-amd64-32.so.so, but I guess we don't want this) probably some more... instead of using the system extension for dynamic libraries, we might pick a general unified (final) extension, instead of the system ones, e.g. .pdx (but that is already taken) or .pd_external. but i think the less we invent ourselves, the better. Lucas had started a feature-request/discussion on this very topic a year ago, but it was dormant until now. https://github.com/pure-data/pure-data/issues/902 i would like to hear your opinion on this (here or at the issue tracker; or both), and eventually get this done. once this is solved, i will start to push Pd64 packages to the Debian repositories, so people can start to use it (without having to compile themselves). gfmsdr IOhannes ¹ just for the record: the biggest hurdle is of course that there is no double-precision download available right now... but that's a bit of an egg-hen problem.

5 13

Re: [PD-dev] call for discussion double-precision file extension
by Sebastian Shader 30 Mar '22

30 Mar '22

I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) -seb Date: Tue, 29 Mar 2022 11:28:57 +0200 From: IOhannes m zmoelnig <zmoelnig(a)iem.at> To: Pd-dev(a)lists.iem.at Subject: [PD-dev] call for discussion double-precision file extension hi, TL;DR i'd like to suggest to use deken-specifiers as (optional) part of external filenames, in order to allow co-installability of externals of different OSs, architectures and floatsizes (and more to come). i would really love to push the double precision saga towards a (happy) end. we have been able to compile Pd for 64bit double precision numbers. there's even a double-precision variant available in the Debian "experimental" repositories (but who knows that?) *very* few people have started to provide externals (i counted: 4). afaict the biggest hurdle is that you can't really co-install single and double variants of the same external. since there are so few double-precision externals available, people who rely on externals will be forced to use single-precision Pd for some time. but since installing a double-precision external might overwrite an existing single-precision external (required in your other project), i understand why people are not exactly eager to do that.? one solution to this problem is to use different installation paths (e.g. ~/Documents/Pd/extra/ vs ~/Documents/Pd/extra64/). this doesn't play well with how deken currently works (as it stores the installation path globally (for all versions/variants of Pd). Lucas suggested to use different file extensions (a year ago...time flies), by inserting `.float64` (and possibly `.float32`) right before our known extension (so we get `foo.float64.m_amd64`) I didn't especially like this back then, but in the meantime i've come to the conclusion that it's probably the best way forward. however, i think that we might do better than just inserting a single `.float64`, and just unify the entire naming scheme to hold all the information we need. i'd therefore suggest to use the deken-specifier together with the native extension (for dynamic-link libraries), as a new extension. the "native extension for dynamic-link libraries" is typically defined on an OS level, and is something like ".dll" on Windows, ".dylib" on macOS and ".so" in the un*x world. the "deken-specifier" is what we use in deken packages to know that they contain binaries for your specific combination of CPU, OS and precision, and looks like "<OS>-<CPU>-<precision>", e.g. "Darwin-arm64-32" (which denotes a macOS binary ("Darwin") that runs on the M1 processor ("arm64") and uses single-precision numbers ("32" bits). this would give us filenames like "zexy.windows-amd64-32.dll" to keep things simple (and reduce the noise with -verbose), i would suggest to only allow lower case specifiers, and no arch variants (e.g. i386 for all x86_32 variants, and amd64 for all x86_64 variants) pros - using the system extension does not require us to invent our own extension for each new platform - system tools often use the file-extension to recognize the file type - deken-specifiers fully cover what we need to know (the problem space is the same for deken package files and externals: allow coexistence of files with multiple OS/arch/precision specs) - people can relate the files within a deken-package with the deken-package-filename - if we ever need to add a new parameter, the deken specifier and the externals are likely to be affected in a similar way, so we need to solve the problem only once. - it gets rid of the super-cryptic .<first-letter-of-the-os>_<cpu-arch> specifier (.o_ia64 anybody?) cons it shares the same (final) extensions as any support libraries. eg. "zexy.linux-amd64-32.so" + "libzexy.linux-amd64-32.so" (or even libzexy.linux-amd64-32.so.so, but I guess we don't want this) probably some more... instead of using the system extension for dynamic libraries, we might pick a general unified (final) extension, instead of the system ones, e.g. .pdx (but that is already taken) or .pd_external. but i think the less we invent ourselves, the better. Lucas had started a feature-request/discussion on this very topic a year ago, but it was dormant until now. https://github.com/pure-data/pure-data/issues/902 i would like to hear your opinion on this (here or at the issue tracker; or both), and eventually get this done. once this is solved, i will start to push Pd64 packages to the Debian repositories, so people can start to use it (without having to compile themselves). gfmsdr IOhannes ? just for the record: the biggest hurdle is of course that there is no double-precision download available right now... but that's a bit of an egg-hen problem.

2 1

Re: [PD-dev] pd 0.52-2 release plan
by Dan Wilcox 28 Mar '22

28 Mar '22

I think it's worth documenting it as a debuting tool, since that's what it's there for, as far as I can tell for Miller's response. > On Mar 24, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Wed, 23 Mar 2022 17:39:36 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Cc: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] pd 0.52-2 release plan > Message-ID: > <CAEAsFmhxRSpD5pLg0TBjxH08Ugo1zw7LQV2jv=+1arDdBA0m5w(a)mail.gmail.com <mailto:CAEAsFmhxRSpD5pLg0TBjxH08Ugo1zw7LQV2jv=+1arDdBA0m5w@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Not sure it's worth documenting then... I should test and see it for myself > how it works so I actually get it. > > keeping it as a hidden feature for now. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

6 7

Re: [PD-dev] pd 0.52-2 release plan
by Sebastian Shader 24 Mar '22

24 Mar '22

I'm hoping to maybe get this pr bugfix in - fixing setting the canvas dirty flag for the font dialog/"font" message (fixes a partial regression I accidentally introduced in 0.51)https://github.com/pure-data/pure-data/pull/1591 thanks-seb >Date: Tue, 22 Mar 2022 08:50:51 -0700 >From: Miller Puckette <msp(a)ucsd.edu> >To: pd-dev(a)lists.iem.at >Subject: [PD-dev] pd 0.52-2 release plan >Message-ID: <YjnwW+D6a4VO7KMZ(a)ucsd.edu> >Content-Type: text/plain; charset=us-ascii > >to Pd dev - > >I'm hoping to put out a bugfix release, 0.52-2, into which I hope to keep >folding the develop branch (as it 'develops'), some other bug fixes >like https://github.com/pure-data/pure-data/pull/1566, and Alexandre's >documentation updates in whatever state it's in. > >Hoping to put out a 'test' today or tomorrow and a final one this weekend... > >Miller

1 0

pd 0.52-2 release plan
by Miller Puckette 23 Mar '22

23 Mar '22

to Pd dev - I'm hoping to put out a bugfix release, 0.52-2, into which I hope to keep folding the develop branch (as it 'develops'), some other bug fixes like https://github.com/pure-data/pure-data/pull/1566, and Alexandre's documentation updates in whatever state it's in. Hoping to put out a 'test' today or tomorrow and a final one this weekend... Miller

2 3

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Sebastian Shader 10 Mar '22

10 Mar '22

(replied to dev list, seems more appropriate)I think you can cross-compile for arm on intel if you have xcode 12.2 (which I believe requires MacOS 10.15 Catalina)https://developer.apple.com/documentation/apple-silicon/building-a… -seb -----Original Message----- From: Alexandre Torres Porres <porres(a)gmail.com> To: Pd-List <pd-list(a)lists.iem.at> Sent: Thu, Mar 10, 2022 11:29 am Subject: [PD] how to compile externals for apple silicon? In my next update of my libraries I wanna see if I can provide externals for M1 macs. I'm assuming I need an apple silicon computer for that, right? Since I don't, I'll ask for someone who has one to help me. Now, what's the next step, is pdlibbuilder ready for apple silicon macs? I see zexy is already provided for apple silicon by the way. cheers _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

2 2

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 March 2022