Pd-dev November 2009

pd-dev@lists.iem.at

19 participants
65 discussions

UTF-8 for pd-devel (again)
by Bryan Jurish 20 Jan '10

20 Jan '10

moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes & comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

5 13

netsend (and more) crash bug
by Ivica Ico Bukvic 20 Jan '10

20 Jan '10

Hi all, In our recent troubleshooting trying to hunt down a mysterious crash at patch closing we uncovered a bug that appears to be present in pd-extended 0.41.4 and 0.42.5, as well as pd vanilla (svn checked out yesterday). Following is reproducible on Linux 9.04 Ubuntu i386. To reproduce the crash if you run the patch included below (pretty much vanilla version of netsend/netreceive) as follows: #N canvas 511 186 450 322 10; #X floatatom 80 -44 0 0 0 0 - - -; #X floatatom 71 32 0 0 0 0 - - -; #X obj 125 -117 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 74 -177 loadbang; #X obj 71 5 netsend 1; #X floatatom 212 -18 5 0 0 0 - - -; #X obj 214 -44 netreceive 3000 1; #X msg 80 -17 send \$1; #X msg 71 -157 connect 192.168.1.8 3000; #X obj 122 -95 metro 2; #X obj 151 -53 +; #X msg 114 -69 1; #X connect 0 0 7 0; #X connect 0 0 10 1; #X connect 2 0 9 0; #X connect 3 0 8 0; #X connect 4 0 1 0; #X connect 6 0 5 0; #X connect 7 0 4 0; #X connect 8 0 4 0; #X connect 9 0 11 0; #X connect 10 0 0 0; #X connect 11 0 10 0; 1) save the patch and click on "connect" message 2) start the metro 3) close the patch *without* stopping the metro 4) reopen it again, and you'll find pd reporting that the old connection still exists (explained below) 5) at this point you can start the metro again (it should work) 6) however, when closing the patch pd will crash Part of the problem: x->x_fd in netsend_disconnect is the same flag used in netsend_send function, so when one tries to close socket but there is still a stream of data coming in, because x->x_fd is reverted to -1 after the attempt to close the socket, the data keeps coming in through netsend_send function potentially (and I speculate here) preventing socket from closing. This leaves a stale open socket and eventually causes the whole thing to crash. Below is the problematic code. static void netsend_disconnect(t_netsend *x) { if (x->x_fd >= 0) { sys_closesocket(x->x_fd); x->x_fd = -1; outlet_float(x->x_obj.ob_outlet, 0); } } Solution is changing the netsend_disconnect to create a temp value from the x->x_fd, change x->x_fd to -1 to prevent other incoming data from being processed, and only then try to close the socket. This has apparently fixed part of the problem on our end here. Please see x_net.c patch below: --- x_net.c.old 2009-11-18 17:45:24.000000000 -0500 +++ x_net.c 2009-11-18 17:41:38.000000000 -0500 @@ -106,8 +106,9 @@ { if (x->x_fd >= 0) { - sys_closesocket(x->x_fd); - x->x_fd = -1; + int tmp = x->x_fd; + x->x_fd = -1; + sys_closesocket(tmp); outlet_float(x->x_obj.ob_outlet, 0); } } The problem is this fixes crashing in a non-rt version of Pd. The rt version however still suffers sporadically from the same problem. It may take several tries to instigate it, but when it finally occurs, in my case the reopening of the patch at first misbehaves in that whatever I do on canvas with a mouse or keyboard, everything is being reported twice (e.g. clicking on the toggle creates an on and an off event, creating a new object creates two, typing into it creates 2 letters per each keypress, etc.). After that closing the patch crashes pd. I've had this occur before as well but now at least the other bug with open socket is not there any more. Any ideas as to why? Ico

2 5

Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
by Spencer Russell 14 Jan '10

14 Jan '10

Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd <dmotd(a)gmx.net> wrote: > hi spencer, > > afaik there hasn't been any progress with > the 64bit translation, i was going to > attempt it last time i needed it but got > distracted along the way - and i sent a > similar message to thomas at the time, so > its going to be on his todo list, but > proabably not a priority. > > i'd be happy to test any changes you > make, and collaborate time permitted. > > ciao, > > dmotd > > Spencer Russell wrote: >> Thought this should probably go to the list: >> >> ---------- Forwarded message ---------- >> From: Spencer Russell <spencer.f.russell(a)gmail.com> >> Date: Tue, Sep 29, 2009 at 11:13 AM >> Subject: Re: fixing Flext for 64-bit? >> To: Thomas Grill <gr(a)grrrr.org> >> >> > >> > Am 29.09.2009 um 15:00 schrieb Spencer Russell: >> > >> >> Hi Thomas, >> >> >> >> I'm writing a Flext external to implement Iannis Xenakis's Dynamic >> >> Stochastic Synthesis, and running into some problems with buffer >> >> handling on my 64-bit system. >> >> >> >> It seems that currently flext uses the deprecated >> >> garray_getfloatarray() function and t_sample arrays, instead of the >> >> new garray_getfloatwords() function with t_word unions. >> >> >> >> Changing the code would make flext incompatible with older versions of >> >> PD, but some other external developers are currently using an #ifdef >> >> workaround to change to the newer API call for PD versions that >> >> support it. >> >> >> >> I was going to get in there and see if i can't get it working in the >> >> flext code, but I wanted to check with you first to see if you had >> >> already done any work on that front. I'll of course send you the diffs >> >> if i get it working. Shouldn't be that hard and i think it should >> >> really only effect the buffer-handling code, but I don't know the >> >> flext codebase that well so there might be some hidden gotchas. >> >> >> >> -spencer >> >> On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill <gr(a)grrrr.org> wrote: >> > Hi Spencer, >> > i know that this is something i should work on, but my schedule is insanely >> > tight and i don't get to it. >> > So, if you can make any contributions and testing on 64-bit systems i'd be >> > very grateful. >> > I'd also go for the Pd API selecton by #ifdef statements. >> > gr~~~ >> > >> >> As far as i can tell, PD since 0.41 changed arrays to be arrays of >> t_words instead of t_samples or t_floats. >> >> On 32-bit architectures they're all the same size, but on 64-bit >> architectures t_word is 64-bit, while t_sample and t_float are still >> 32-bit. >> >> For a normal PD external, it's pretty easy to just modify the external >> to use t_words, but I'm not sure the best way to modify flext to do >> this without breaking compatibility for externals. One problem is that >> when an external calls mybuffer.Data(), what should they receive? if >> the system is PD newer than 0.41, they should receive a pointer to >> t_word, but MAX or older PD should receive a pointer to t_sample. >> >> The other problem is that accessing an element for newer PD requires >> accessing the w_float member of the t_word union, but the others just >> use the element itself. >> >> There could be some sort of GetValue() wrapper for buffer elements >> that could be made cross-platform, but would break compatibility with >> existing flext externals, so that seems seriously sub-optimal. >> >> thoughts? >> >> -s- >> _______________________________________________ >> http://grrrr.org/ext/flext >> >> flext mailing list >> flext(a)grrrr.org >> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext >

2 3

[declare] bug (id 2251387)
by Roman Haefeli 26 Dec '09

26 Dec '09

hi everyone i once posted a bug to the tracker and it still appears to be there in version 0.42.3. since this bug is kind of viral, so that it corrupts patches invisibly and without being noticed by the author, and also since quite some of my own patches got affected by that bug, i would like to ask to raise the priority of this one. BEWARE: everyone, who was working on patches in 0.42.X, that contain abstractions containing [declare]'s is most likely affected, or i should rather say: infected. read the description here: http://sourceforge.net/tracker/index.php?func=detail&aid=2251387&group_id=5… roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 3

Re: [PD-dev] pd-extended vs. gui-rewrite on X86_64 WAS: [PD] pd-extended build on 9.10
by András Murányi 08 Dec '09

08 Dec '09

> > >>> >>> do all externals have the problem, or just a few? >>> >>> >> mmm, seems to me that none of them load. >> >> >> THat's an odd one. My guess is that perhaps the pd you are using and the >> externals that you are loading are different bitnesses, i.e. 32-bit and >> 64-bit. Use the 'file' command to see: >> >> hans@blinky:~ > file /usr/bin/pd >> /usr/bin/pd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), >> dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped >> >> .hc >> > > pd binary and some externals: > > muranyia@zero:~$ file /usr/bin/pd >> /usr/bin/pd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for >> GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped >> /usr/lib/pd/extra/libdir.pd_linux: ELF 64-bit LSB shared object, x86-64, >> version 1 (SYSV), stripped >> /usr/lib/pd/extra/Gem/Gem.pd_linux: ELF 64-bit LSB shared object, x86-64, >> version 1 (SYSV), stripped >> /usr/lib/pd/extra/cyclone/cycle.pd_linux: ELF 64-bit LSB shared object, >> x86-64, version 1 (SYSV), not stripped >> > > I took a look and i don't have other pd installs in /usr/local or anything > like that. > > Hello guys, any ideas on this one? -- Muranyi Andras

2 2

adding standard install paths to the 'puredata' package
by Hans-Christoph Steiner 05 Dec '09

05 Dec '09

Hey all, For the new 'puredata' package, I think we should add the user- installed paths that have been included with Pd-extended for a while now. Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) and add /usr/lib/pd-externals for the install path for libraries that can be used with 'puredata', 'pd-extended', 'desiredata', etc. Here are the user-installed locations: http://www.puredata.info/docs/faq/how-do-i-install-externals-and-help-files… The user-installed folders would not be created by the package, just searched if they exist, so people can completely ignore them if they want. I propose the search order look like this: - paths from preferences ~/pd-externals/ /usr/local/lib/pd-externals /usr/lib/pd-externals /usr/lib/puredata Ultimately, I think some of this stuff should end up in a 'pd-common' package, including things like the file mime types and the directory / usr/lib/pd-externals. .hc ---------------------------------------------------------------------------- I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

5 20

Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
by Ivica Ico Bukvic 04 Dec '09

04 Dec '09

Oops, still getting used to the microscopic phone keyboard... BTW if this thing is top-posting, my apologies. It appears the droid leaves me no choice here :-( So, what I was trying to say is that there are two issues at hand here that are mistakenly being interpreted as one. Pd.tk in and of itself has not been submitted for inclusion, but (as per your request) as a means to test new scrolling method. And while the pd.tk in question has a wrapper in place to allow use on both <8.4 and >=8.5 it has not been fully tested nor fully implemented for non-linux platforms. Hene if you wish to test it out as I indicated before, you either need to test it on linux or use updated replacement function in your existing pd.tk I sent out in my earlier email. Reporting any failures of it running otherwise is imho irrelevant to the scrolling algorithm. So, may I suggest that for the sake of clarity, let us not discuss any potential inclusion of pd.tk in this thread, as that clouds the matter at hand which is the scrolling algorithm. Cheers! Ivica Ico Bukvic <ico(a)vt.edu> wrote: >I think we are confusing two things here, the whole pd.tk which does offer

4 8

externals for timecoded vinyl
by komika 03 Dec '09

03 Dec '09

hello list i have set up a download site at http://www.komika.org for externals which read and play back timecoded vinyl (at the moment only traktor scratch vinyl is supported). These externals are written for Max/MSP. I am wondering if anybody is interested to port those externals to PD. - - - - - - - - - - - www.komika.org - - - - - - - - - - -

2 2

[ pure-data-Bugs-2724318 ] 'pd -alsa -send "; pd dsp 1"' fails with -nogui
by SourceForge.net 30 Nov '09

30 Nov '09

Bugs item #2724318, was opened at 2009-03-31 22:23 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2724318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Miller Puckette (millerpuckette) Summary: 'pd -alsa -send "; pd dsp 1"' fails with -nogui Initial Comment: $ pd -alsa -send "; pd dsp 1" works fine $ pd -alsa -nogui -send "; pd dsp 1" snd_pcm_open (output): Device or resource busy if i send to a custom receiver and delay the message by 100ms it seems to work ok, but still, not perfect at a guess there's a race condition somewhere, and using the gui slows it down enough to work? just a guess though tested on GNU/Linux/Debian/Lenny/pure:dyne with pd-0.41 may also affect other sound APIs, but I haven't tested with anything other than ALSA ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-11-30 11:21 Message: Confirmed on Debian/lenny/i386 running Pd-vanilla 0.41.4 and Pd-extended 0.41.4 and 0.42.5. ---------------------------------------------------------------------- Comment By: Cesar Mauri-Loba (cmauri) Date: 2009-08-24 11:21 Message: Confirmed in pd 0.42-5 under WinXP SP3. These are the error messages: Error number -9985 opening portaudio stream Error message: Device unavailable As a workaround I've added a delay after the loadbang that enables the dsp. ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2009-06-15 06:51 Message: Again in Ubuntu Jaunty, Running the same startup patch which loadbangs "pd dsp 1" in pd-extended 0.40.3 with "-rt" yields the same problem. I suppose in realtime mode, pd runs too fast to avoid the race condition. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-06-15 06:47 Message: Confirmed in pd-extended 0.41.4 on Ubuntu Jaunty. Cannot open the soundcard when starting pd with "pd -nogui -alsa -audiodev 4 ~/StartupPatch.pd" where "StartupPatch.pd" loadbangs a "pd dsp 1" message: snd_pcm_open (input): Device or resource busy snd_pcm_open (output): Device or resource busy Using jack, "-jack -channels 2" connects ok. I have not not tried oss. Doing the same on pd-extended 0.40.3 works fine. Well, at least I can just delay the dsp switch for now to make it work. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-02 10:22 Message: oh forgot to say: OSS: /dev/dsp (writeonly): Device or resource busy /dev/dsp (readonly): Device or resource busy with jack it seems to work fine (though i often have other problems with jack, so i don't know how reliable this is) ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-02 10:20 Message: confirmed with Pd-0.42.4 (debian lenny/squeeze; x86) however i thought the proper way to specify the send-message was "pd dsp 1" (without the leading semicolon) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2724318&group_…

1 0

[ pure-data-Bugs-2838114 ] zexy fwriteln buffer overflow
by SourceForge.net 30 Nov '09

30 Nov '09

Bugs item #2838114, was opened at 2009-08-15 12:33 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: zexy fwriteln buffer overflow Initial Comment: The buffer for the prefix is too small. gcc -I. -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD -I/usr/src/pd/src -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall -O2 -c -o fwriteln.o fwriteln.c In file included from /usr/include/string.h:640, from fwriteln.c:26: In function 'strcpy', inlined from 'fwriteln_new' at fwriteln.c:233: /usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer In function 'strcpy', inlined from 'fwriteln_new' at fwriteln.c:236: /usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer Line 195: char prefix[2]="%"; Line 233: strcpy(prefix,"%-"); Line 236: strcpy(prefix,"%+"); The strcpy will copy an additional '\0' byte which will overflow the buffer. Suggested fix: increase the prefix buffer size ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-11-30 10:03 Message: submitted with r18215 thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_…

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 November 2009