Pd-dev January 2004

pd-dev@lists.iem.at

24 participants
35 discussions

zexy compile for OSX from CVS
by ben＠ekran.org 21 Jan '04

21 Jan '04

Hello, I'm having trouble compiling zexy for OSX, the compile fails at: gcc -bundle -bundle_loader ../../../pd/bin/pd -o zexy.pd_darwin *.o -lc -lm ld: Undefined symbols: _z_operating_system_setup make: *** [all] Error 1 This is a CVS update from about a week ago. Thanks Ben

2 1

OSCx for OS X
by ben＠ekran.org 21 Jan '04

21 Jan '04

Hello All, I'm trying to get OSCx to work on OSX (10.3) but I can't get past compile errors from libOSC (following message). Any help would be appreciated. Does anyone have OSCx working, a pd binary perhaps? Thanks Ben cc -c -O2 -Wall -fPIC -Dunix OSC-client.c In file included from OSC-client.c:68: /usr/include/netinet/in.h:255: error: parse error before "in_addr_t" /usr/include/netinet/in.h:312: error: parse error before "u_char" /usr/include/netinet/in.h:314: error: parse error before "sin_port" /usr/include/netinet/in.h:317: error: parse error before '}' token /usr/include/netinet/in.h:329: error: field `ip_dst' has incomplete type /usr/include/netinet/in.h:398: error: field `imr_multiaddr' has incomplete type /usr/include/netinet/in.h:399: error: field `imr_interface' has incomplete type In file included from /usr/include/netinet/in.h:518, from OSC-client.c:68: /usr/include/netinet6/in6.h:123: error: parse error before "u_int8_t" /usr/include/netinet6/in6.h:125: error: parse error before "__u6_addr32" /usr/include/netinet6/in6.h:126: error: parse error before '}' token /usr/include/netinet6/in6.h:127: error: parse error before '}' token /usr/include/netinet6/in6.h:145: error: parse error before "u_int8_t" /usr/include/netinet6/in6.h:147: error: parse error before "sin6_port" /usr/include/netinet6/in6.h:148: error: parse error before "sin6_flowinfo" /usr/include/netinet6/in6.h:150: error: parse error before "sin6_scope_id" /usr/include/netinet6/in6.h:384: error: field `ro_dst' has incomplete type /usr/include/netinet6/in6.h:455: error: field `ipv6mr_multiaddr' has incomplete type /usr/include/netinet6/in6.h:463: error: field `ipi6_addr' has incomplete type /usr/include/netinet6/in6.h:615: error: syntax error before "struct" /usr/include/netinet6/in6.h:617: error: parse error before "__P" /usr/include/netinet6/in6.h:618: error: parse error before "__P" /usr/include/netinet6/in6.h:619: error: parse error before "__P" /usr/include/netinet6/in6.h:621: error: parse error before '*' token /usr/include/netinet6/in6.h:622: error: parse error before "__P" /usr/include/netinet6/in6.h:623: error: parse error before "__P" /usr/include/netinet6/in6.h:625: error: parse error before "inet6_rthdr_space" /usr/include/netinet6/in6.h:626: error: parse error before "__P" /usr/include/netinet6/in6.h:627: error: parse error before "__P" /usr/include/netinet6/in6.h:629: error: parse error before "__P" /usr/include/netinet6/in6.h:633: error: parse error before "__P" /usr/include/netinet6/in6.h:634: error: parse error before "__P" /usr/include/netinet6/in6.h:635: error: parse error before "__P" /usr/include/netinet6/in6.h:637: error: parse error before "__P" /usr/include/netinet6/in6.h:638: error: parse error before "__P" /usr/include/netinet6/in6.h:640: error: parse error before "__P" /usr/include/netinet6/in6.h:641: error: parse error before "__P" /usr/include/netinet6/in6.h:643: error: parse error before "__P" /usr/include/netinet6/in6.h:645: error: parse error before "__P" /usr/include/netinet6/in6.h:647: error: parse error before "__P" /usr/include/netinet6/in6.h:648: error: parse error before "inet6_rth_space" /usr/include/netinet6/in6.h:649: error: parse error before "__P" /usr/include/netinet6/in6.h:650: error: parse error before "__P" /usr/include/netinet6/in6.h:651: error: parse error before "__P" /usr/include/netinet6/in6.h:652: error: parse error before "__P" /usr/include/netinet6/in6.h:653: error: parse error before "__P" In file included from /usr/include/machine/types.h:30, from /usr/include/sys/types.h:72, from /usr/include/stdio.h:65, from OSC-client.c:69: /usr/include/ppc/types.h:69: error: syntax error before "typedef" /usr/include/netinet/in.h:315: error: storage size of `sin_addr' isn't known /usr/include/netinet6/in6.h:149: error: storage size of `sin6_addr' isn't known make: *** [libOSC.a(OSC-client.o)] Error 1

2 5

Fw: [GEM-dev] pd/Gem crash pains
by B. Bogart 20 Jan '04

20 Jan '04

I tried the patch today without the gem objects and it does not crash, so its some interaction between gem and pd. :( B. ----- Original Message ----- From: "chris clepper" <cgc(a)humboldtblvd.com> To: <ben(a)ekran.org>; <gem-dev(a)iem.at> Sent: Monday, January 19, 2004 11:56 PM Subject: Re: [GEM-dev] Gem crash pains > This looks like a pd crash as I don't see any GEM function calls in > the backtrace. forward this to miller and see what he has to say. > maybe GEM is doing something wrong with the pd scheduler? > > cgc > > At 7:14 PM -0800 1/19/04, <ben(a)ekran.org> wrote: > >Hello all, > > > >I'm now on an OSX machine and having gem segfaults. (attached is my gem > >crashlog from today) On a hunch I thought I would try my linux > >crash-test patch on OSX, and low and behold, left control crashes 0.37-0 > >on OSX the same way as it did in linux: > > > >Program received signal EXC_BAD_ACCESS, Could not access memory. > >0x90000e70 in strcmp () > >(gdb) where > >#0 0x90000e70 in strcmp () > >#1 0x00033048 in dogensym () > >#2 0x00035aa4 in binbuf_text () > >#3 0x0003b4d0 in socketreceiver_doread () > >#4 0x0003b810 in socketreceiver_read () > >#5 0x0003b320 in sys_domicrosleep () > >#6 0x0003c184 in sys_pollgui () > >#7 0x00039c04 in m_scheduler () > >#8 0x000020cc in _start (argc=466652, argv=0x0, envp=0x1) at > >/SourceCache/Csu/Csu-47/crt.c:267 #9 0x8fe1a700 in __dyld__dyld_start > >() > > > >Well after trying it a couple times I found you may have to leave it for a > >while counting and then hit it with crtl-l, at least that did it for me. > >Please try the attached test patch and see what happens. > > > >As for the crashes in the attached log file, these all happend at the same > >time as the linux crashes, when sending 1/0 messages to the gemwin while > >the window is created. > > > >Thanks > >Ben > > > > > >Attachment converted: Macintosh HD:crash_gem.log (eApp/CSOm) (0012C0C6) > >Attachment converted: Macintosh HD:01.redSquare-crash.pd (eApp/CSOm) > >(0012C0C7) >

1 0

pd 0.37 bugs with canvases + gcc 3.3 compile??
by ben＠ekran.org 18 Jan '04

18 Jan '04

Hello Miller, I found a bug to do with canvas names in pd 0.37-1 test2 and test3 (I'm compiling 37-0 now) The send/receive and name params seem to be all mixed up. If I create a canvas with the send "1" receive "2" and name "3" close and open the patch I get a canvas with send "1" receive "2" and name "2" (the receive param seems to be copied into the name param.) Ok so there is this issue so I'm trying to compile a working pd but... 37-0 fails with: d_ctl.c: In function `line_tilde_perform': d_ctl.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules d_ctl.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules d_ctl.c: In function `vline_tilde_float': d_ctl.c:285: warning: dereferencing type-punned pointer will break strict-aliasing rules d_ctl.c:285: warning: dereferencing type-punned pointer will break strict-aliasing rules make: *** [d_ctl.o] Error 1 36-0 fails with: g_bang.c: In function `bng_new': g_bang.c:442: warning: dereferencing type-punned pointer will break strict-aliasing rules g_bang.c:443: warning: dereferencing type-punned pointer will break strict-aliasing rules make: *** [g_bang.o] Error 1 using gcc3.3 Sounds a little too familar! Any ideas for a fix before I wreak all my canvases!!!? Thanks Ben

4 7

pthread_setschedparam problem on OSX + fix
by cgc 17 Jan '04

17 Jan '04

I've been meaning to post this change for a long time, and have been negligent about it. The pthread_setschedparam() hack that helps pd's audio not drop on OSX is absolutely fatal when used with GEM. The reason for this is that OSX uses OpenGL for the entire UI and GL requires context switches to handle multiple applications sharing the hardware. When Pd sets it's pthread priority higher than the UI, this context switch can be blocked resulting in a complete lockout of UI events as GEM grabs all the CPU resources and refuses to relinquish the context. The fix is to add the -rt option as prerequisite and not make this the default action (a check to make sure GEM is not loaded would be good to have as well): #ifdef MACOSX if (sys_hipriority) { struct sched_param param; int policy = SCHED_RR; int err; param.sched_priority = 80; // adjust 0 : 100 post("pd: real-time mode - using pthread_setschedparam\n"); err = pthread_setschedparam(pthread_self(), policy, &param); if (err) post("warning: high priority scheduling failed\n"); } #endif /* MACOSX */

3 2

$0 broken for "symbol" obj's internal send/receive
by zack 14 Jan '04

14 Jan '04

It looks like the symbol object doesn't know what to do with a "$0-send-receive-name" in the "send symbol" or "receive symbol" fields. Take away the $0 and it works fine. Other graphical objects (toggle, bang etc...) have no problem with $0. -Z

1 0

CVS write access.
by Kjetil Svalastog Matheussen 07 Jan '04

07 Jan '04

Hi, I wonder if I can get write access to the sf CVS? I want to include k_cext, k_vst~ and k_guile, if thats okey? My sourceforge user name is "ksvalast". --

2 1

writesf~ bug?
by Jorge Cardoso 05 Jan '04

05 Jan '04

Hi, I have been playing around with writesf~, trying to save '.au' files (nextstep), and I'm getting weird results. I'm hoping someone else can verify this. I have a Windows machine running PD 0.37.0. When I use writesf~ to save a file in 'au' format (using the -nextstep flag) the resulting file is malformed (I can't open it with any sound program). After a little inspection to the generated file it seems to me that the file is always big-indian encoded (it also seems that the -little/-big flags have no effect, the file is always the same). Also it seems that field 2 of the file header (data size) is filled with zeroes when, according to http://brandt.kurowski.net/projects/lsa/wiki/view.cgi?doc=588, it should be filled with ones. I made a test patch (see attach) to reproduce these results . I experimented re-arranging the file manually and it can be played afterwards... Hope someone can shed some light on this. Thanks, jc PS: I have just joined this list and I don't know if this was the right place to post possible bugs in PD or if the cvs list would be more appropriate... --- Jorge Cardoso <-> jorgecardoso(a)ieee.org Centro de Investigação em Ciência e Tecnologia das Artes (CITAR) Univ. Católica - CRP -> Escola das Artes -> Dept. Som e Imagem Rua Diogo Botelho 1327 4169 - 005 Porto Portugal "Whether you believe you can, or whether you believe you can't, you're absolutely right." - Henry Ford

1 0

Re: [PD-announce] pd 0.37-1 test 2 out (source only)
by Krzysztof Czaja 05 Jan '04

05 Jan '04

hi Miller, Miller Puckette wrote: ... > I've put out more bugfixes... source only so far. 1. in order to compile, I have had to put (without much thinking): #define sys_dacblocksize DEFDACBLKSIZE into s_audio_jack.c 2. vexp.c should be patched, or at least -Wshadow option removed from extra/expr~'s makefile (linux part) 3. no time to check, but I am pretty sure the 2-pixel effect on Windows is going to be replaced by a 4-pixel effect... I think, the easiest way to go is adding the -highlightthickness option to pd.tk. This is from the tcl/tk8.4.4 source: tkUnixDefault.h: #define DEF_CANVAS_HIGHLIGHT_WIDTH "1" tkWinDefault.h: #define DEF_CANVAS_HIGHLIGHT_WIDTH "2" tkMacOSXDefault.h: #define DEF_CANVAS_HIGHLIGHT_WIDTH "3" Happy new year, Krzysztof

1 0

pdogg and CVS
by Olaf Matthes 04 Jan '04

04 Jan '04

Hi there, because I didn't want to be too ignorant I tried to check in latest pdogg (version 0.25) stuff myselfe: CVS says I don't have write permission... ;-( So, if anybody could please commit the sources from http://www.akustische-kunst.org/puredata/pdogg/pdogg-0.25-source.tar.gz that would be very nice. It inlcudes minor updates to oggamp~ to get rid of the audio clicks and some small bug-fixes. This will be the last pdogg version provided by me, so it really makes sense to have these files in CVS. thanks, Olaf

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 January 2004