Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

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] error missing in Pd 0.52
by Dan Wilcox 01 May '22

01 May '22

You missed the discussion because it took place in libpd-land: https://github.com/libpd/libpd/issues/336 <https://github.com/libpd/libpd/issues/336> It was not a decision taken lightly, but it's necessary as Pd's previous "error()" could conflict with libc "error()". The replacement already existed for sometime, so changing calls to "error(...)" with "pd_error(0, ...)" should be equivalent and not break the external in old versions of Pd. > On Apr 29, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Fri, 29 Apr 2022 09:51:48 +0200 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] error missing in Pd 0.52 > Message-ID: <96224f3ab47171eff50b17d1507974c6d8b13fd5.camel(a)gmail.com <mailto:96224f3ab47171eff50b17d1507974c6d8b13fd5.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hey all > > Since 0.52, compiling of some externals fails with an error like: > > ~~ > binfile.c:103:9: error: implicit declaration of function 'error' is invalid in C99 [-Werror,-Wimplicit-function-declaration] > error("binfile: Could not create..."); > ~~~ > > In 0.51-4, the error function was still defined in m_pd.h. Was 'error' > deprecated in favor of pd_error? > > Sorry, if I missed the related discussions, but I feel introducing > breaking changes in Pd is generally not done lightly. And I found > similar issues in active developments like aoo, so I'm probably not the > only one having missed this. > > Roman -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 1
by Sebastian Shader 01 May '22

01 May '22

I just compiled universal Pd on catalina I had to add the correct -isysroot Cflagshere are the commands I have saved to configure (I'm not sure they're the exact ones I used): SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/./configure CFLAGS="-arch x86_64 -arch arm64 -isysroot $SDKROOT -mmacosx-version-min=10.6" --host aarch64-apple-darwin" hope it helps-seb ------------------------------ Date: Sat, 30 Apr 2022 21:50:51 -0300 From: Alexandre Torres Porres <porres(a)gmail.com> To: Dan Wilcox <danomatika(a)gmail.com> Cc: pd-dev <pd-dev(a)lists.iem.at> Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? Message-ID: <CAEAsFmhzsxKuUxRrUXrf0Z6xc=JaJ6wrcwQ7AEQhhLL8X9J-zA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Em qui., 10 de mar. de 2022 ?s 19:57, Dan Wilcox <danomatika(a)gmail.com> escreveu: > 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 > > 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. > So, I now have a partition with Catalina (10.15.7) and Xcode 12.4, which is the last version catalina accepts. According to https://developer.apple.com/pt/support/xcode/ I believe 12.1 could have been possible already. 12.5 needs Big Sur. Here's a table from the link Vers?o do XcodeSistema operacional m?nimo necess?rioSDKArquiteturaDestinos de implanta??oSimuladorSwift Xcode 12.4 macOS Catalina 10.15.4 (Mac com processador Intel) macOS Big Sur 11 (Mac com Apple Silicon) iOS 14.4 macOS 11.1 tvOS 14.3 watchOS 7.2 DriverKit 20.2 x86_64 armv7 armv7s armv7k arm64 arm64e arm64_32 iOS 9-14.4 iPadOS 13-14.4 macOS 10.9-11.1 tvOS 9-14.3 watchOS 2-7.2 DriverKit 19-20.2 It says it can build for 'arm64' alright, but I tried creating a fat binary for both intel and M1 as I was doing in my monterey partition and didn't succeed. I'm using pd-lib-builder, verdsion 6.0, so I did: make install objectsdir=../ arch="i386 x86_64" extension=d_fat and that works just fine but... make install objectsdir=../ arch="arm64 x86_64" extension=d_fat fails miserably, this is what I get */Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: **error: **Unsupported architecture* #error Unsupported architecture What should I do? My attempt here is to be able to build a binary for fluidsynth~ that works for a wide range of OSes thanks cheers > 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> > To: Sebastian Shader <sebfumaster(a)aol.com> > Cc: "pd-dev(a)lists.iem.at" <pd-dev(a)lists.iem.at> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: > <CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w(a)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 > robotcowboy.com > > > >

1 0

error missing in Pd 0.52
by Roman Haefeli 29 Apr '22

29 Apr '22

Hey all Since 0.52, compiling of some externals fails with an error like: ~~ binfile.c:103:9: error: implicit declaration of function 'error' is invalid in C99 [-Werror,-Wimplicit-function-declaration] error("binfile: Could not create..."); ~~~ In 0.51-4, the error function was still defined in m_pd.h. Was 'error' deprecated in favor of pd_error? Sorry, if I missed the related discussions, but I feel introducing breaking changes in Pd is generally not done lightly. And I found similar issues in active developments like aoo, so I'm probably not the only one having missed this. Roman

1 0

Re: [PD-dev] [SPAM?] Re: Externals in Pd.52.2(Rosetta Mode) on Mac M1!
by IOhannes m zmoelnig 28 Apr '22

28 Apr '22

On 4/27/22 21:06, Jakob Skouborg wrote: > > In activity monitor it shows this, one process runs native(Apple) and the other process runs Intel: > that looks as if you were runing Pd-0.52.1, rather than Pd-0.52.2 gfasdmr IOhannes

1 0

mrpeach midifile maintenance
by Dan Wilcox 19 Apr '22

19 Apr '22

Howdy all, there appears to be some questions/issues regarding mrpeach [midifle] on GitHub: https://github.com/pd-externals/mrpeach/issues <https://github.com/pd-externals/mrpeach/issues> I use the object quite a bit but don't have time to look into this as I want to finalize some libpd & PdParty stuff. Maybe other users of this object can pitch in? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

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

04 Apr '22

Mmmm I wouldn't make this assumption. By default, the libpd repo makefile throws in LIBDL when linking on platforms that support it, so desktop apps *could* support loading externals. I for one, however, have not relied on this myself, but I could imagine *someone, somewhere* does? > On Apr 4, 2022, at 3:01 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Mon, 4 Apr 2022 15:00:52 +0200 > 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] PDINSTANCE for Pd (was Re: call for discussion > double-precision file extension) > Message-ID: <0861a01f-14da-166c-df62-d8cebe2ed823(a)christofressi.com <mailto:0861a01f-14da-166c-df62-d8cebe2ed823@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> I was thinking to a way for the transition: we could: >> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_* >> replacement? macros accordingly), >> - export "hidden" globals s_* >> - initialize pd_maininstance pd_s_* fields to the global versions. > Yes, this would work. Of course, it would be an ABI break for > multi-instance libpd, but I think it would be justified. I guess libpd > users rarely rely on pre-build externals, and even if they do, I think > it's ok to ask them to recompile. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

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

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