Pd-dev March 2020

pd-dev@lists.iem.at

12 participants
8 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] no longer able to "send" to UDP -- correction
by Dan Wilcox 28 Mar '20

28 Mar '20

I wasn't aware that was supported and we didn't remove any existing capability, as far as I know. Sending via [netreceive] with TCP works as before. As Christof says, if there were obvious commits we can certainly (re_integrate them if they were lost along the line. > On Mar 28, 2020, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Fri, 27 Mar 2020 22:35:08 -0700 > From: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > To: pd-dev(a)iem.at <mailto:pd-dev@iem.at> > Subject: Re: [PD-dev] no longer able to "send" to UDP -- correction > Message-ID: <20200328053508.GA9452(a)ucsd.edu <mailto:20200328053508.GA9452@ucsd.edu>> > Content-Type: text/plain; charset=us-ascii > > correction: I forgot that Roman's netpd uses iemnet, not netsend/netreceive, > which I guess is why his jack~ implementation is working better than mine. > I can switch over as well, so I don't have any urgent need to send replies > from netreceive -u to netsend -u as I had thought. > > It would still be good if the new netsend/receive were able to do this, both > to maintain 0.50 compatibility, and to allow vanilla-only access to that > ability. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

no longer able to "send" to UDP (because now "connectionless"?
by Miller Puckette 28 Mar '20

28 Mar '20

To Pd dev (of interest to netsend/netreceive experts :) - One thing that was possible in pd 0.50 was to "send" to netreceive -u ... this was added by Shahrokh Yadegari a year or so ago. I think it gets used; for instance I don't see how to implement jacktrip without it (as Roman Haefeli did in his netpd system and as I'm now trying to do in a Camomile plugin). Would it be onerous to bring that capability back? For the moment we can fall back to 0.50 but we'd need a way to do this, even if it's impossible to do exactly compatibly with 0.50. thanks Miller

2 3

trying to understand class_new
by Boštjan Jerko 25 Mar '20

25 Mar '20

Hi, I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do? My guess is connecting puredata command with a function in C. Am I correct or completely missing the point? Thanks. B.

4 14

Default value for unconnected signal input, or connection detection in an external
by x nor 19 Mar '20

19 Mar '20

Hey Christof and dev list, Christof, I think it was you that did the work that allowed for a default value for unconnected [inlet~] in the inlet_features branch that didn't get merged? I'm wondering, is there a way to do that with externals as is without modifying the pure data source? Either that or a way to detect connectivity? I want to provide some audio rate controls to an external I'm writing but not *require* them for operation. 0 isn't a good default for some of these (amp or frequency multiplication). If its not possible to provide defaults or detect connectivity (so i can provide my own defaults) I'll probably just provide optional creation args to opt in to these audio rate parameters.. but that just ends up being a lot more work so I figured I'd ask first :) Thanks, Alex

3 5

loading externals on android (pddroidparty, mobmuplat, ...)
by IOhannes m zmölnig 18 Mar '20

18 Mar '20

hi, i'm currently trying to add support for building externals for android to pd-lib-builder. it build nicely, but so far i was unnsueccessfull in using the external in PdDroidParty. (the patch that uses the external does not seem to do anything that indicates that the external is indeed used). any pitfalls i should be aware of? i don't even know whether PdDroidParty is supposed to load externals. if not, is there any other available android project i could use for testing? i would rather not compile the host myself. i'm aware that i might have missed some documentation and/or debugging options in PdDroidParty that might give me more info; but... so little time. gmsard IOhannes PS: oh, and i don't have google play store installed, so any project should either be available via f-droid or provide a direct apk download...

2 1

Current Leapmotion Windows
by Tanner Yilmaz 10 Mar '20

10 Mar '20

2 1

Re: [PD-dev] [PD] double precision merged
by Dan Wilcox 07 Mar '20

07 Mar '20

Forgive me if this has been gone over, but what's the behavior if a single-precision Pd tries to load a double-precision external or vice versa? Does it fail to load or simply crash? If it crashes, maybe there needs to be some mechanism to query the compiled precision of the external, ie. some sort of function pointer or define, etc. If it's not there, then assume single-precision and act accordingly. It would be nice to have useful error print concerning this. I'm just musing here. :) > On Feb 26, 2020, at 1:58 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 4 > Date: Wed, 26 Feb 2020 13:58:50 +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] [PD] double precision merged > Message-ID: <7f65121f-810d-c952-40f8-4f0facbbb1a3(a)christofressi.com <mailto:7f65121f-810d-c952-40f8-4f0facbbb1a3@christofressi.com>> > Content-Type: text/plain; charset=utf-8; format=flowed > > I see you point and I think it's a philosophical issue. In > Supercollider, for example, I can't compile a UGen plugin and expect it > to run on both Scsynth and Supernova, I rather have to pass the correct > define ("SUPERNOVA"). Plugins are therefore usually built twice - with > and without "-DSUPERNOVA" - and since they have different extensions and > export different symbols, they can coexist. I think this could be a > solution for Pd as well. If we had some naming convention for double > precision externals, we can then just built both versions > unconditionally and Pd will load the correct version. This can be > automated by pd-lib-builder. > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

7 18

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 2020