Pd-dev September 2005

pd-dev@lists.iem.at

18 participants
48 discussions

glibc pthread_join freezing on sarge using pd/pdp/gem
by B. Bogart 21 Sep '05

21 Sep '05

Hi all again, Time is running out for this machine... After spending some time on debian-glibc it seems they are not convinced that it is pthread crashing on my machine, but something happening in the other threads. So lets get to the tracing... after I manually kill PD this is what I'm seeing in gdb: Program received signal SIGTERM, Terminated. [Switching to Thread 1076308992 (LWP 9384)] 0xffffe410 in __kernel_vsyscall () (gdb) (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4012f288 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x403f7dad in videoV4L::stopTransfer () from /usr/lib/pd/extra/Gem.pd_linux #3 0x403f7f66 in videoV4L::setNorm () from /usr/lib/pd/extra/Gem.pd_linux #4 0x403f3755 in pix_videoNEW::normMess () from /usr/lib/pd/extra/Gem.pd_linux #5 0x403f3f1a in pix_videoNEW::modeMessCallback () from /usr/lib/pd/extra/Gem.pd_linux #6 0x0809ba47 in pd_typedmess () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x00000000 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0xbfffdc30 in ?? () #20 0x00000000 in ?? () #21 0xbfffdc00 in ?? () #22 0xbfffdc20 in ?? () #23 0xbfffe1b8 in ?? () #24 0x0025771c in ?? () #25 0x00000000 in ?? () #26 0x08257628 in ?? () #27 0x00000000 in ?? () #28 0x080eccff in _IO_stdin_used () #29 0x082147b8 in ?? () #30 0x0809cf77 in outlet_anything () #31 0x08250728 in ?? () #32 0x080eccc3 in _IO_stdin_used () #33 0xbfffdc78 in ?? () #34 0x4050244c in ?? () from /usr/lib/pd/extra/Gem.pd_linux #35 0x08250728 in ?? () #36 0xbfffdc60 in ?? () #37 0xbfffdc78 in ?? () #38 0x08257690 in ?? () #39 0x080f73d0 in stderr () #40 0x00000002 in ?? () #41 0x082318e0 in ?? () #42 0x0809cf77 in outlet_anything () #43 0x00000000 in ?? () #44 0x00000000 in ?? () #45 0x08256e48 in ?? () #46 0x00000002 in ?? () #47 0x080f73d0 in stderr () #48 0x0820b558 in ?? () #49 0x082508fc in ?? () #50 0x0809b696 in pd_typedmess () #51 0x404a60cc in GemMan::m_border () from /usr/lib/pd/extra/Gem.pd_linux #52 0x00000000 in ?? () #53 0xbfffdcc8 in ?? () #54 0x40331af1 in GemMan::startRendering () from /usr/lib/pd/extra/Gem.pd_linux Previous frame inner to this frame (corrupt stack?) (gdb) info threads 2 Thread 1146301360 (LWP 9389) 0xffffe410 in __kernel_vsyscall () * 1 Thread 1076308992 (LWP 9384) 0xffffe410 in __kernel_vsyscall () (gdb) thread 2 [Switching to thread 2 (Thread 1146301360 (LWP 9389))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40203fe9 in ioctl () from /lib/tls/i686/cmov/libc.so.6 #2 0x403f7481 in videoV4L::capturing () from /usr/lib/pd/extra/Gem.pd_linux #3 0x4012ee40 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 This means very little to me, and it sure meant little to the glibc folks. For completness here is the same deal for PDP, which is also crashing with pdp_v4l: Program received signal SIGTERM, Terminated. [Switching to Thread 1076308992 (LWP 9395)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4012f288 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x40294440 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux (gdb) info threads 3 Thread 1109560240 (LWP 9399) 0xffffe410 in __kernel_vsyscall () 2 Thread 1099164592 (LWP 9398) 0xffffe410 in __kernel_vsyscall () * 1 Thread 1076308992 (LWP 9395) 0xffffe410 in __kernel_vsyscall () (gdb) thread 2 [Switching to thread 2 (Thread 1099164592 (LWP 9398))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40130d46 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x402b16fc in pdp_procqueue_flush () from /usr/lib/pd/extra/pdp.pd_linux #3 0x402b7350 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #4 0x00000001 in ?? () #5 0x00000001 in ?? () #6 0x402b7320 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x402b1898 in pdp_procqueue_add () from /usr/lib/pd/extra/pdp.pd_linux #10 0x402b7320 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #11 0x40137ff4 in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #12 0x00000000 in ?? () #13 0x007d0f00 in ?? () #14 0x4183e4c8 in ?? () #15 0x4000aaa0 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #16 0x00000002 in ?? () #17 0x4183e490 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x4183ebb0 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x40137ff4 in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #26 0x00000000 in ?? () #27 0x007d0f00 in ?? () #28 0x4183e4c8 in ?? () #29 0x4183e470 in ?? () #30 0x4012ee14 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #31 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread 1109560240 (LWP 9399))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40203fe9 in ioctl () from /lib/tls/i686/cmov/libc.so.6 #2 0x40294626 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux #3 0x0000000a in ?? () #4 0x40047612 in snd_config_searcha () from /usr/lib/libasound.so.2 #5 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 Not I am running libc 2.3.5 BUT the above trace contains: #1 0x40130d46 in pthread_cond_wait@@GLIBC_2.3.2 () So looking through here I noticed that /lib/tls/i686/cmov/libpthread.so.0 is what is being used, which says: Native POSIX Threads Library by Ulrich Drepper et al Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Forced unwind support included. And /lib/tls/i686/cmov/libc.so.6 says: GNU C Library stable release version 2.3.5, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.0.2 20050725 (prerelease) (Debian 4.0.1-3). Compiled on a Linux 2.6.13 system on 2005-08-27. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. What I'm confused about it how this libc differs from /lib/libc.so.6: Compiled by GNU CC version 4.0.2 20050725 (prerelease) (Debian 4.0.1-3). Compiled on a Linux 2.6.13 system on 2005-08-27. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. So why is /lib/tls/i686/cmov/libc.so.6 used and not /lib/libc.so.6 ? Anyhow I'm way over my head debugging this so please lend me a hand, what the heck is going on?!?!?! pdp_v4l does not happen to be very similar to pix_video does it? Perhaps based on pix_video? Thanks to all on glibc for at least getting me this far, I hope the gem and PDP developers have a closer look at this. b.

2 2

pyext crash
by Georg Holzmann 21 Sep '05

21 Sep '05

Hallo Thomas, all! just playing around with pyext to make a simple remote procedure call I have the following problem: (python script is attached) when I try to call the method "trigger" from an other program, PD always is crashing with the following backtrace: ----------8<---------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1345365072 (LWP 7095)] 0xb6d34602 in pyext::pyext_outlet () from /usr/lib/pd/extra/py.pd_linux (gdb) bt #0 0xb6d34602 in pyext::pyext_outlet () from /usr/lib/pd/extra/py.pd_linux #1 0xb6c57308 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0 #2 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #3 0xb6c8dd4c in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #4 0xb6c91a4a in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0 #5 0xb6c44845 in PyFunction_SetClosure () from /usr/lib/libpython2.3.so.1.0 #6 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #7 0xb6c8f422 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #8 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #9 0xb6c91a4a in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0 #10 0xb6c90b1f in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #11 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #12 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #13 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #14 0xb6c91a4a in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0 #15 0xb6c44845 in PyFunction_SetClosure () from /usr/lib/libpython2.3.so.1.0 #16 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #17 0xb6c314c3 in PyMethod_New () from /usr/lib/libpython2.3.so.1.0 #18 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #19 0xb6c8b11d in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.3.so.1.0 #20 0xb6c33c0a in PyInstance_New () from /usr/lib/libpython2.3.so.1.0 #21 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 ---Type <return> to continue, or q <return> to quit--- #22 0xb6c8dd4c in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #23 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #24 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #25 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #26 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #27 0xb6c90da5 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0 #28 0xb6c91a4a in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0 #29 0xb6c44845 in PyFunction_SetClosure () from /usr/lib/libpython2.3.so.1.0 #30 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #31 0xb6c314c3 in PyMethod_New () from /usr/lib/libpython2.3.so.1.0 #32 0xb6c29f2a in PyObject_Call () from /usr/lib/libpython2.3.so.1.0 #33 0xb6c8b11d in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.3.so.1.0 #34 0xb6cbdf71 in PyGC_Collect () from /usr/lib/libpython2.3.so.1.0 #35 0xb7f9fccd in start_thread () from /lib/tls/libpthread.so.0 #36 0xb7f33b0e in clone () from /lib/tls/libc.so.6 (gdb) -------------8<------------ I gues I am using something in a wrong way, but if I don't try to send the number to the outlet (line 31 in xmlrpc_server.py) there is no crash (e.g. a simple print in python works fine ...) Thanks for any hint, LG Georg -- =%)!:?"§<§0&-"|>* http://grh.mur.at

2 3

building DesireData with scons on OSX
by Kyle Klipowicz 16 Sep '05

16 Sep '05

Hello all~ I was trying to figure this out with matju on #dataflow, but he had to go. So I will document it here, since it might be a problem for other OSX users wanting to try DesireData and drool a little. here is the error message scons gives me: Hunab-Ku:~/pd kyleklipowicz$ sudo scons desire=1 debug=1 wall=1 scons: Reading SConscript files ... Checking for dlopen() in C library dl... yes Checking for sin() in C library m... yes Checking for pthread_create() in C library pthread... yes Checking for main() in C library fftw3f... no scons: done reading SConscript files. scons: Building targets ... scons: `bin/pdsend' is up to date. scons: `bin/pdreceive' is up to date. scons: `bin/libpdtcl.dylib' is up to date. gcc -g -faltivec -maltivec -DDL_OPEN -DNEWHASH -DLOCKFREE -DDESIRE -DUNISTD -DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX -DUSEAPI_PORTAUDIO -DPA19 -DDEBUG -DHAVE_ALLOCA -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -Isrc -Iportmidi_osx -Iportaudio/pa_common -Iportaudio/pablio -c -o src/desire.o src/desire.c src/desire.c:1202: error: static declaration of 'iemgui_new' follows non-static declaration src/desire.c:118: error: previous declaration of 'iemgui_new' was here src/desire.c:1221: error: static declaration of 'iemgui_propertiesfn' follows non-static declaration src/desire.c:119: error: previous declaration of 'iemgui_propertiesfn' was here src/desire.c:1227: error: static declaration of 'iemgui_constrain' follows non-static declaration src/desire.c:121: error: previous declaration of 'iemgui_constrain' was here src/desire.c:1233: error: static declaration of 'iemgui_init' follows non-static declaration src/desire.c:124: error: previous declaration of 'iemgui_init' was here src/desire.c:1235: error: static declaration of 'binbuf_update' follows non-static declaration src/desire.c:125: error: previous declaration of 'binbuf_update' was here src/desire.c:1245: error: static declaration of 'iemgui_loadbang' follows non-static declaration src/desire.c:126: error: previous declaration of 'iemgui_loadbang' was here src/desire.c:1250: error: static declaration of 'iemgui_forward' follows non-static declaration src/desire.c:127: error: previous declaration of 'iemgui_forward' was here scons: *** [src/desire.o] Error 1 scons: building terminated because of errors. ---------------------------------------------------------------------------- This is all with the latest devel cvs on :pserver: and the first line of desire.c says this: /* $Id: desire.c,v 1.1.2.11 2005/09/14 17:36:44 matju Exp $ Also, since matju requested it, I have the first line of ChangeLog: $Id: ChangeLog,v 1.1.4.2 2005/09/11 23:37:33 matju Exp $ And finally, here is the version of gcc I am using: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/configure --disable-checking --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.0 (Apple Computer, Inc. build 5026) I hope that we can fix this! (By "we" I mean the real coders. I'm just a beta tester.) ~Kyle -- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO

3 2

Fwd: adding new developer to sf.net
by Franz Zotter 15 Sep '05

15 Sep '05

Hi! I've been working with pd mainly as an instrument for my scientific work, so far. Recently I wrote additional externals for the iemmatrix providing some octave like matrix manipulations/operations (fft, index, find,...). I'm looking forward to sharing and discussing pieces of my work on this platform. best, Franz. ---------- Forwarded Message ---------- Subject: adding new developer to sf.net Date: Thursday 15 September 2005 13:37 From: IOhannes m zmoelnig <zmoelnig(a)iem.at> To: pd-dev <pd-dev(a)iem.kug.ac.at>, Franz Zotter <zotter(a)iem.at> hi list. franz zotter (currently working at our institute) wants to join the pure-data.sf.net as a developer. [...]

4 3

dumpOSC crashes with long messages
by Frank Barknecht 15 Sep '05

15 Sep '05

Hi, a friend brought to my attention, that dumpOSC doesn't handle lists with more than 50 elements properly. It simply crahes Pd. Attached patch shows this. (pd 0.39 required for "list"). The reason actually is quite simple: dumpOSC.c defines a maximum of atoms to hold in x->x_outat of being 50 as default, but later doesn't check at all, if this space is exceeded. Here's the relevant part of the struct declaration: /* ----------------------------- dumpOSC ------------------------- */ #define MAXOUTAT 20 static t_class *dumpOSC_class; typedef struct _dumpOSC { t_object x_obj; t_outlet *x_msgout; t_outlet *x_connectout; t_atom x_outat[MAXOUTAT]; int x_outatc; /* ... */ } t_dumpOSC; Then later in the functions "dumpOSC_PrintTypeTaggedArgs" and "dumpOSC_PrintHeuristicallyTypeGuessedArgs" x->x_outat is happily filled with atoms as long as the incoming message list lasts, which of course is a recipe for desaster. Now with my limited experience in C coding, I wonder, what's the best way to fix this. I already wrapped all tries to append to x->x_outat in a big "if" clause which checks, if MAXOUTAT is reached. This works and keeps Pd from crashing. However somehow it doesn't feel right to just truncate the incoming message, even when posting a big warning message. OTOH I suppose, that declaring *x_outat with a fixed size was done for speed reasons. Having to allocate memory everytime a message comes in would be very slow. Maybe one could introduce an argument to dumpOSC which sets the maximum allowed message length (with a default of 50)? So what to do about this? Any advice or opinions? (Apart from using liblo and totally rewriting OSCx, which of course probably is the best solution ...) Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__

2 3

osx packages build question
by james tittle 15 Sep '05

15 Sep '05

hey everyone, ...well, finally did it! It was tough headscratching work, but now I've learned a ton about basic shell programming and regex and such, so it's worth it ;-) ...Just committed a new Makefile++ and resource file to packages which allow building the whole shebang via gcc4.0 & using tcl/tk 8.4.10 (or newer) :-) This really opens the door for the following releases: devel_0_38, devel_0_39, devel_0_39+carmen's stuff+tcl/tk8.5 +tcl/tkextensions+gridflow/ruby.framework, etc., but also it's time to really talk about (and fix) the unified distro, like what new stuff to include, how to fix up path/startup entry preferences, whether or not we should put everything inside the .app (thinking here about example patches that need to be opened, but can't be because the app package is not visible in the open file dialog)... ...I'm also curious as to how up-to-date the "build" directory files are? Fr'instance, I know zexy's been updated & split up into parts recently, as has the iem stuff... ...sorry I didn't get this to ya before the 0.39-0 release, miller...anyway, I'll upload an example of what I have built when I get home tonight... jamie ps: there's also some changes to pd itself, in that I've got it using dl_open instead of the deprecated NSwhateverbundleloader stuff: I'll get this in cvs soon...

2 3

adding new developer to sf.net
by IOhannes m zmoelnig 15 Sep '05

15 Sep '05

hi list. franz zotter (currently working at our institute) wants to join the pure-data.sf.net as a developer. he probably should write some words about himself, so people that don't know him would get some ideas about what he is doing. after he has done so and nobody objects, i'll add him to the devs. mfg.as.dr IOhannes

1 0

[ pure-data-Bugs-1180148 ] silence when there's only output device
by SourceForge.net 14 Sep '05

14 Sep '05

Bugs item #1180148, was opened at 2005-04-10 04:14 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1180148&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: 7 Submitted By: Thomas Grill (xovo) Assigned to: Miller Puckette (millerpuckette) Summary: silence when there's only output device Initial Comment: Currently, when there is no input device (but there is output, like on the Minimac), in the audio config dialog the input is enabled but the input device list is empty. In this situation there is no audio output either. Disabling the input helps - this should be the default when there is no input device. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2005-09-13 16:30 Message: Logged In: YES user_id=313747 I can't reproduce this at the moment... perhaps this only happens on macintosh??? ---------------------------------------------------------------------- Comment By: Thomas Grill (xovo) Date: 2005-09-02 12:57 Message: Logged In: YES user_id=350252 Ok, increased priority since this bug report has been here for _quite_ a while and the issue becomes increasingly nasty by the time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1180148&group_…

1 0

amd64: rsqrt~
by Tim Blechmann 12 Sep '05

12 Sep '05

hi miller, hi devs ... the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ... static void init_rsqrt(void) { int i; for (i = 0; i < DUMTAB1SIZE; i++) { float f; long l = (i ? (i == DUMTAB1SIZE-1 ? DUMTAB1SIZE-2 : i) : 1)<< 23; *(long *)(&f) = l; rsqrt_exptab[i] = 1./sqrt(f); } for (i = 0; i < DUMTAB2SIZE; i++) { float f = 1 + (1./DUMTAB2SIZE) * i; rsqrt_mantissatab[i] = 1./sqrt(f); } } couldn't really look into it, but i guess, the wild cast in *(long *)(&f) = l; might be a problem on th x86_64 architecture ... not really a problem for devel, since devel most likely uses sse instructions to do the rsqrt computation ... but someone who is into vanilla pd might be interested in having a look at it .. cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk latest mp3: kMW.mp3 http://mattin.org/mp3.html latest cd: Gohü Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/ After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

5 10

table/array issues (broken mouse editing)
by Claude Heiland-Allen 12 Sep '05

12 Sep '05

Hi all, There is a bug in array editing with the mouse: if you draw in a table so that the whole line is outside the bounds of the graph, it is no longer editable with the mouse. (This bug hit me in a performance last night, I slipped on the mousepad and was left with a silent volume envelope on one sound - ouch!) Bug exists with 0.39test6 (my install) and 0.39-0 (dyno on #dataflow's install). Claude

2 1

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 September 2005