Pd-dev April 2022

pd-dev@lists.iem.at

8 participants
9 discussions

building fluidsynth~ (was: building fluid~ on Linux)
by Alexandre Torres Porres 04 May '22

04 May '22

Hi, after more than a year, I'm finally going to release my fluidsynth~ object as part of ELSE. There were lots of discussion on this list about this. One big issue was how to ship the external along with the library dependencies. There are scripts taken from https://git.iem.at/pd/iem-ci to copy the libs to the same folder as the external. It seems we got to a point of being able to build it for mac and windows. This last thread (from where I'm now opening a new one) was about building it for Linux. After so long I just tried to build it on my new system and my new challenge would be to see if it'd work for apple silicon macs. First I just tried building for mac intel using my new setup, a monterey machine with the latest XCode. I started by installing fluidsynth, now at a much more recent version 2.2.7, I then built the external and it worked fine in the system I built this on. I tried the localdeps.macos.sh script and it did copy all the libs to the same folder as the external, so I zipped it and uploaded to https://github.com/porres/pd-fluidsynth/releases/tag/0.0.0-test so I could test on another machine without fluidsynth and all... guess what? it didn't work! By the way, someone built it for windows and I was able to test that it works on a virtual windows machine, so I don't know what could be wrong with my setup... See https://github.com/charlesneimog/pd-fluidsynth/releases/tag/v0.0.1 note that there's also a mac version there, but it doesn't work either and seems to be worse than my attempt as there a no libs copied. You cal also test the linux version in there. Hope someone can give me a hint why my new attempt didn't work for mac, I don't know what could be different other than having a new system a new version of the OS, of XCode and fluidsynth. cheers Em qui., 14 de jan. de 2021 às 18:16, Roman Haefeli <reduzent(a)gmail.com> escreveu: > On Thu, 2021-01-14 at 16:52 +0100, IOhannes m zmölnig wrote: > > On 1/14/21 10:42 AM, Roman Haefeli wrote: > > > See PR: > > > https://github.com/porres/pd-fluidsynth/pull/5 > > > > > > > given that i consider myself upstream of the original > > "localdeps.*.sh" > > scripts and those scripts are located under > > https://git.iem.at/pd/iem-ci > > where they are used by a number of (our, that is: the iem's) > > libraries, > > i would highly welcome it if you could submit a PR to that central > > location rather than a single one of the consumers of those scripts. > > Sure. I wasn't even aware of the origin of those files. > > Re PR/MR: > While logged in as reduzent, I see only comport listed as repos I can > create MRs for. I don't seem to have privileges for forking on > git.iem.at nor for creating MRs for the iem-ci repo. Tell me if I'm > overseeing something. > > I created a fork on: > https://gitlab.zhdk.ch/rhaefeli/iem-ci > > You'll find the script addition in the linuxdep branch. > > Roman > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-dev >

4 23

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] 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

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

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