Pd-dev February 2014

pd-dev@lists.iem.at

12 participants
21 discussions

Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers
by Dan Wilcox 07 Mar '14

07 Mar '14

Howdy again Miller, I manually applied your last 2 commits to the libpd pd_0.45-4 branch. Hopefully people with the actual hardware will give it a test and chime in. I also put together a little script to check for string patterns in source files and ran it on the externals in the sourceforge svn for the mess* functions and t_got_fn. It doesn't look that bad overall. Here's the output: -------------------------------------------------------------------------------- Checking for " mess1(" ... ./algocomp/m_pd.h: 231:#define mess1(x, s, a) ((*getfn((x), (s)))((x), (a))) ./grill/dynext/src/main.cpp: 952: mess1((t_pd *)canvas,const_cast<t_symbol *>(sym_dsp),NULL); -------------------------------------------------------------------------------- Checking for " mess2(" ... ./algocomp/m_pd.h: 232:#define mess2(x, s, a,b) ((*getfn((x), (s)))((x), (a),(b))) -------------------------------------------------------------------------------- Checking for " mess3(" ... ./algocomp/m_pd.h: 233:#define mess3(x, s, a,b,c) ((*getfn((x), (s)))((x), (a),(b),(c))) -------------------------------------------------------------------------------- Checking for " mess4(" ... ./algocomp/m_pd.h: 234:#define mess4(x, s, a,b,c,d) ((*getfn((x), (s)))((x), (a),(b),(c),(d))) -------------------------------------------------------------------------------- Checking for " mess5(" ... ./algocomp/m_pd.h: 235:#define mess5(x, s, a,b,c,d,e) ((*getfn((x), (s)))((x), (a),(b),(c),(d),(e))) -------------------------------------------------------------------------------- Checking for "t_gotfn" ... ./algocomp/m_pd.h: 204:typedef void (*t_gotfn)(void *x, ...); 226:EXTERN t_gotfn getfn(t_pd *x, t_symbol *s); 227:EXTERN t_gotfn zgetfn(t_pd *x, t_symbol *s); ./chaos/attract1.c: 168: if (lyapunov_full((void *) attract1, (t_gotfn) calc, M_var_count, attract1 -> vars, results) != NULL) { 297: attract1 -> lyap_exp = lyapunov((void *) attract1, (t_gotfn) calc, M_var_count, (double *) attract1 -> vars); ./chaos/base.c: 135: if (lyapunov_full((void *) base, (t_gotfn) calc, M_var_count, base -> vars, results) != NULL) { 212: base -> lyap_exp = lyapunov((void *) base, (t_gotfn) calc, M_var_count, (double *) base -> vars); ./chaos/base3.c: 135: if (lyapunov_full((void *) base3, (t_gotfn) calc, M_var_count, base3 -> vars, results) != NULL) { 212: base3 -> lyap_exp = lyapunov((void *) base3, (t_gotfn) calc, M_var_count, (double *) base3 -> vars); ./chaos/chaos.h: 17:double lyapunov(void *fractal, t_gotfn calc, int var_count, double *vars); 25:double *lyapunov_full(void *fractal, t_gotfn calc, int var_count, double *vars, double *results); ./chaos/dejong.c: 156: if (lyapunov_full((void *) dejong, (t_gotfn) calc, M_var_count, dejong -> vars, results) != NULL) { 259: dejong -> lyap_exp = lyapunov((void *) dejong, (t_gotfn) calc, M_var_count, (double *) dejong -> vars); ./chaos/henon.c: 144: if (lyapunov_full((void *) henon, (t_gotfn) calc, M_var_count, henon -> vars, results) != NULL) { 221: henon -> lyap_exp = lyapunov((void *) henon, (t_gotfn) calc, M_var_count, (double *) henon -> vars); ./chaos/hopalong.c: 150: if (lyapunov_full((void *) hopalong, (t_gotfn) calc, M_var_count, hopalong -> vars, results) != NULL) { 240: hopalong -> lyap_exp = lyapunov((void *) hopalong, (t_gotfn) calc, M_var_count, (double *) hopalong -> vars); ./chaos/ikeda.c: 159: if (lyapunov_full((void *) ikeda, (t_gotfn) calc, M_var_count, ikeda -> vars, results) != NULL) { 262: ikeda -> lyap_exp = lyapunov((void *) ikeda, (t_gotfn) calc, M_var_count, (double *) ikeda -> vars); ./chaos/latoocarfian.c: 156: if (lyapunov_full((void *) latoocarfian, (t_gotfn) calc, M_var_count, latoocarfian -> vars, results) != NULL) { 259: latoocarfian -> lyap_exp = lyapunov((void *) latoocarfian, (t_gotfn) calc, M_var_count, (double *) latoocarfian -> vars); ./chaos/latoomutalpha.c: 156: if (lyapunov_full((void *) latoomutalpha, (t_gotfn) calc, M_var_count, latoomutalpha -> vars, results) != NULL) { 259: latoomutalpha -> lyap_exp = lyapunov((void *) latoomutalpha, (t_gotfn) calc, M_var_count, (double *) latoomutalpha -> vars); ./chaos/latoomutbeta.c: 156: if (lyapunov_full((void *) latoomutbeta, (t_gotfn) calc, M_var_count, latoomutbeta -> vars, results) != NULL) { 259: latoomutbeta -> lyap_exp = lyapunov((void *) latoomutbeta, (t_gotfn) calc, M_var_count, (double *) latoomutbeta -> vars); ./chaos/latoomutgamma.c: 156: if (lyapunov_full((void *) latoomutgamma, (t_gotfn) calc, M_var_count, latoomutgamma -> vars, results) != NULL) { 259: latoomutgamma -> lyap_exp = lyapunov((void *) latoomutgamma, (t_gotfn) calc, M_var_count, (double *) latoomutgamma -> vars); ./chaos/libchaos.c: 22:double lyapunov_eval(void *fractal, t_gotfn calc, int var_count, double *vars, double *test) { 53:double lyapunov(void *fractal, t_gotfn calc, int var_count, double *vars) { 65:double *lyapunov_full(void *fractal, t_gotfn calc, int var_count, double *vars, double *results) { ./chaos/logistic.c: 129: if (lyapunov_full((void *) logistic, (t_gotfn) calc, M_var_count, logistic -> vars, results) != NULL) { 193: logistic -> lyap_exp = lyapunov((void *) logistic, (t_gotfn) calc, M_var_count, (double *) logistic -> vars); ./chaos/lorenz.c: 163: if (lyapunov_full((void *) lorenz, (t_gotfn) calc, M_var_count, lorenz -> vars, results) != NULL) { 266: lorenz -> lyap_exp = lyapunov((void *) lorenz, (t_gotfn) calc, M_var_count, (double *) lorenz -> vars); ./chaos/lotkavolterra.c: 156: if (lyapunov_full((void *) lotkavolterra, (t_gotfn) calc, M_var_count, lotkavolterra -> vars, results) != NULL) { 259: lotkavolterra -> lyap_exp = lyapunov((void *) lotkavolterra, (t_gotfn) calc, M_var_count, (double *) lotkavolterra -> vars); ./chaos/martin.c: 138: if (lyapunov_full((void *) martin, (t_gotfn) calc, M_var_count, martin -> vars, results) != NULL) { 202: martin -> lyap_exp = lyapunov((void *) martin, (t_gotfn) calc, M_var_count, (double *) martin -> vars); ./chaos/mlogistic.c: 129: if (lyapunov_full((void *) mlogistic, (t_gotfn) calc, M_var_count, mlogistic -> vars, results) != NULL) { 193: mlogistic -> lyap_exp = lyapunov((void *) mlogistic, (t_gotfn) calc, M_var_count, (double *) mlogistic -> vars); ./chaos/pickover.c: 163: if (lyapunov_full((void *) pickover, (t_gotfn) calc, M_var_count, pickover -> vars, results) != NULL) { 266: pickover -> lyap_exp = lyapunov((void *) pickover, (t_gotfn) calc, M_var_count, (double *) pickover -> vars); ./chaos/popcorn.c: 138: if (lyapunov_full((void *) popcorn, (t_gotfn) calc, M_var_count, popcorn -> vars, results) != NULL) { 202: popcorn -> lyap_exp = lyapunov((void *) popcorn, (t_gotfn) calc, M_var_count, (double *) popcorn -> vars); ./chaos/quadruptwo.c: 150: if (lyapunov_full((void *) quadruptwo, (t_gotfn) calc, M_var_count, quadruptwo -> vars, results) != NULL) { 240: quadruptwo -> lyap_exp = lyapunov((void *) quadruptwo, (t_gotfn) calc, M_var_count, (double *) quadruptwo -> vars); ./chaos/rossler.c: 163: if (lyapunov_full((void *) rossler, (t_gotfn) calc, M_var_count, rossler -> vars, results) != NULL) { 266: rossler -> lyap_exp = lyapunov((void *) rossler, (t_gotfn) calc, M_var_count, (double *) rossler -> vars); ./chaos/standardmap.c: 138: if (lyapunov_full((void *) standardmap, (t_gotfn) calc, M_var_count, standardmap -> vars, results) != NULL) { 202: standardmap -> lyap_exp = lyapunov((void *) standardmap, (t_gotfn) calc, M_var_count, (double *) standardmap -> vars); ./chaos/strange1.c: 204: if (lyapunov_full((void *) strange1, (t_gotfn) calc, M_var_count, strange1 -> vars, results) != NULL) { 411: strange1 -> lyap_exp = lyapunov((void *) strange1, (t_gotfn) calc, M_var_count, (double *) strange1 -> vars); ./chaos/tent.c: 129: if (lyapunov_full((void *) tent, (t_gotfn) calc, M_var_count, tent -> vars, results) != NULL) { 193: tent -> lyap_exp = lyapunov((void *) tent, (t_gotfn) calc, M_var_count, (double *) tent -> vars); ./chaos/three_d.c: 169: if (lyapunov_full((void *) three_d, (t_gotfn) calc, M_var_count, three_d -> vars, results) != NULL) { 285: three_d -> lyap_exp = lyapunov((void *) three_d, (t_gotfn) calc, M_var_count, (double *) three_d -> vars); ./chaos/threeply.c: 150: if (lyapunov_full((void *) threeply, (t_gotfn) calc, M_var_count, threeply -> vars, results) != NULL) { 240: threeply -> lyap_exp = lyapunov((void *) threeply, (t_gotfn) calc, M_var_count, (double *) threeply -> vars); ./chaos/tinkerbell.c: 156: if (lyapunov_full((void *) tinkerbell, (t_gotfn) calc, M_var_count, tinkerbell -> vars, results) != NULL) { 259: tinkerbell -> lyap_exp = lyapunov((void *) tinkerbell, (t_gotfn) calc, M_var_count, (double *) tinkerbell -> vars); ./miXed/riddle/riddle.c: 873: t_gotfn freefn = zgetfn((t_pd *)rd, gensym("_free")); ./miXed/shared/unstable/fragile.c: 54: if (mp->me_fun == (t_gotfn)thiscall) 102: if (mp->me_name == cname && mp->me_fun != (t_gotfn)thiscall) ./miXed/shared/unstable/pd_imp.h: 17: t_gotfn me_fun; -------------------------------------------------------------------------------- On Feb 22, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote: > From: Dan Wilcox <danomatika(a)gmail.com> > Subject: Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers > Date: February 21, 2014 at 8:58:25 AM EST > To: Miller Puckette <msp(a)ucsd.edu> > Cc: pd-dev(a)iem.at > > > Thanks Miller. Is that to the Sourceforge git or some other place? I'll pull it down into libpd and get people to test it. > > On Feb 21, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote: > >> It looks like the whole mess1() (etc) macro system is going to fail on >> 64-bit ARM - I can't see how to patch that. I can fix the local problems in >> the Pd vanilla source but I don't know whether it's better to take out the >> "mess()" macros altogether, or to take them out only for ARM64. (The >> former would be source incompatible but object compatible, but I'm thinking >> source compatibilty with a non-working feature is maybe actually worse than >> simply being source incompatible.) >> >> I've gone ahead and git-pushed an attempted fix (changing mess1() etc, >> potentially source-incompatibly) but am open to other ideas how to fix this. > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

2 3

Rewriting a unified phasor / metro object for reading tables
by Ed Kelly 07 Mar '14

07 Mar '14

Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be "yes" but I want to make sure. I suppose I should just try it really... Cheers, Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/

8 10

Question for Dennis: How do you use Pd?
by Dan Wilcox 27 Feb '14

27 Feb '14

Howdy Dennis, You mentioned in your udp object emails that you're interfacing with a mixer setup for your church. How do you use Pd in that setup? Are there live effects for a praise band, studio automation control, etc? I'm thinking how I'd integrate Pd into my parents church where, currently, the most advanced tech involves turning the PA on and off. I'm always amazed at how open source software can find uses beyond it's "usual contexts", which for me would be academic / digital noise festivals :D -- Dan Wilcox danomatika.com robotcowboy.com

2 1

Re: [PD-dev] [PD-DEV] Requesting SVN commit access
by Dennis Engdahl 27 Feb '14

27 Feb '14

Martin: I have attached the file to this e-mail. Let me know if it doesn't arrive. As you saw in my previous e-mail, the X32 does not allow TCP. Nor does it communicate in any other manner than I described. By the way, just to be clear. I do not claim any authorship of this routine. It is simply the combining of some of the code from your udpsend and udpreceive into one routine to make communication with the X32 possible. Dennis Engdahl engdahl(a)snowcrest.net (530) 926-2996

2 2

Link for file
by Dennis Engdahl 26 Feb '14

26 Feb '14

Martin: In case the list doesn;t allow attachments, you can get the zip file of my routines at: http://www.snowcrest.net/engdahl/udpsndrcv.zip Thanks, Dennis Engdahl engdahl(a)snowcrest.net (530) 926-2996

1 0

Requesting SVN commit access
by Dennis Engdahl 26 Feb '14

26 Feb '14

To the list members: My name is Dennis Engdahl. I have been developing computer programs since the days of the keypunch (and paper tape), and have taught computer science at the college level for 20 years. I am now retired, and have started an internet providing company which my sons now run. I am an expert at communications software (TCP/IP, etc.), and am interested in pd to communicate with my church's new Behringer X32. Since the UDP routines Martin Peach wrote are not able to receive data successfully from the X32, I researched the problem and created a new routine which will communicate. If you're interested in the details, you can either look at my source, or pm me. At this time, I would like to commit this routine (udpsndrcv.c) and its help file to Martin's area, to allow others to communicate with hardware with the same requirements as the X32. I am interested also in the audio aspects of pd, and may be developing other routines to help out in the future. Please allow me SVN commit access to be able to accomplish this. Thank you, Dennis Engdahl engdahl(a)snowcrest.net (530) 926-2996

4 9

Re: [PD-dev] Requesting SVN commit access
by IOhannes m zmoelnig 26 Feb '14

26 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 (taking this back to the list) On 2014-02-26 14:55, Martin Peach wrote: > On 2014-02-26 03:47, IOhannes m zmoelnig wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 2014-02-26 04:57, Martin Peach wrote: >> >> >> how come? how does DNS (after all, a central service in the >> internet) work with this assumption? >> >> UDP works fine with as a challenge/response system (less so as >> client/server, given that there is no notion of a "connection"), >> and for responses you need o be able to send messages somewhere. >> >> for whatever reasons, many hardware manufacturers have the idea >> that sending/receiving on the *same* port is a good idea. > > I see; but for DNS with [udpsend] and [udpreceive], it should work > since one [udpsend] can send to port 53 of the DNS server and a > separate [udpreceive 53] will receive its replies. it seems i was a bit unclear here, and thus two separate things got mixed up: - DNS is a bi-directional protocol: you send a query (from a random port N) to a DNS-server (on port 53), and the server sends a response from port 53 to that port N. - hardware-manufacturers like the idea that the receiving port is the same as the sending port. DNS does not have this limitation of using the same port (thus you can query a DNS-server on localhost without stepping on your own ports). so having both [connect dns.server 53(->[udpsend] + [udpreceive 53] is not sufficient to query a DNS-server. > The problem seems to be that [udpsend] will assign itself a random > port to which the remote device will send replies, but [udpsend] > doesn't know its own port number. well, but that's only half of the solution (for the DNS-problem): even if [udpsend] had a notion of it's sending port, it would discard all messages arriving on this port. but it still *listens* on (and thus blocks) this port, so you cannot tell a [udpreceive] to (also) use it. fg,asd IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTDf0gAAoJELZQGcR/ejb4+3gP/jHgX0wRrIBNPPMC92+y8ssL dokmoX/tQa5ZYhPwcUg68xwORPKzldql2PsMx1hY19ud9kzoIbFXmfy/uBk9mTNX VATEb2d7vMY5lk3/iGApefl+gnugm9rCPyD88J80U/Q5gRDBUvCFH1hbtABXccRA AXRGRcZ5C9pMYPlCE6R0O4EF0553Dudscsitu2/wMx+hpqAfdS51bIbwSd6vU56I CGIc3QIohipwnQmhMQ9EAdFD/i3zxXg2xuC5HzHpc/Q4hipsuw0169V19pn6ucFM yx6iKW2j6P60QW3D7y8betwyBOmRfgpyF9ip4AkDvWqZuzfng0YxAWco3v9rDpvZ PITxRicLL50EyemI1rms6mPiw6nWmATfbYSQBPGdxTG/J6vUBlijNdrl1FdEIv0n 7dyLOLMk4rmfGivSrKFBsX2JcicPPapUv9grpm4d277mIn+oFhMVurfWHHp5DiPJ m66KkWMYwiAqK1+TjMzI+PI9yK+3gYZy54ExXi8/xxlZjC1F8nNHNv0ti2z+uk/Z DUERnsE42nzZ2pxNKTsSkaNv3GHMAFe0H7MRsdUD5+3CrtqBuHLpyJIQxjEHmP/4 /BGNhFJXiGnK+MOb84/8kq2W0QkYoIvF2LDdUUV/qNbj1Z0b0Ft1cRJjBwELX5Is iDAK9hFfnmz7uzdFkVur =s8u4 -----END PGP SIGNATURE-----

1 0

Re: [PD-dev] Multiple Instance of pdlib
by Dan Wilcox 26 Feb '14

26 Feb '14

On Feb 24, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote: > when i (last) looked into the libpd API, i noticed that libpd works on > a global namespace as well...what i mean is, that the API (at least > the C-API, i haven't checked the others) does not allow to specify an > "instance" of pd. That's correct. Because there isn't currently a way to multiple instances beyond previously mentioned hacks to the core or non-portable linker flags, the api isn't in place to support it. > but i fail to see why libpd doesn't provide the API for this, even if > the "instance" pointer would not be used (until Pd does support > multiple instances). > > e.g. the application programmer would have to check that libpd_init() > returns non-NULL anyhow, and in the current implementation it would > always return NULL but the first time being called. > > this would have allowed for a transition to multiple instances without > having to change the API... Good point. I wasn't involved when Peter first started the project and I'm sure, back then, multiple PD instances seemed waaay off into the future. I think the best/easiest way to handle this without breaking anyone's current code, would be to shadow all of the functions with functions that take an instance pointer, as you suggest. The default ones would simply handle a single internal pointer to the first opened instance, as it does now. If you use the pointer manually, then it's up to you to keep track of it. I we don't mind breaking compatibility, we can simply add an instance handle to each function we have now. Either way, not that difficult. The C++ wrapper I wrote has api support for multiple instances (aka you can create multiple PdBase classes). Internally, that is handled by a PdContext static class which would theoretically return new instance pointers but, for now, it simply calls the global libpd functions and there is a big warning in the documentation about only using 1 PdBase instance for now. Again, wouldn't be too hard to add, just currently waiting whether this could become a reality. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

2 1

My Sourceforge ID
by Dennis Engdahl 25 Feb '14

25 Feb '14

I neglected to include my SourceForge ID in my previous e-mail. It is "dengdahl". Thanks, Dennis Engdahl engdahl(a)snowcrest.net (530) 926-2996

1 0

[pure-data:bugs] #1138 [mrpeach/tcpserver] send data to wrong client
by Antoine Villeret 25 Feb '14

25 Feb '14

--- ** [bugs:#1138] [mrpeach/tcpserver] send data to wrong client** **Status:** open **Created:** Tue Feb 25, 2014 10:51 AM UTC by Antoine Villeret **Last Updated:** Tue Feb 25, 2014 10:51 AM UTC **Owner:** nobody --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

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 February 2014