Pd-dev June 2005

pd-dev@lists.iem.at

22 participants
69 discussions

devel_0_38 probs on osx 10.4.1
by james tittle 06 Jul '05

06 Jul '05

hey, ...thought I'd start using this devel version, but can't compile it using gcc 4.0 on osx 10.4.1...I've heard about a scons version of the build system, but know even less about that than configure/make, so I went that route... ...right off the bat, I couldn't do "./bootstrap.sh", because I have newer versions of some of the called programs (both aclocal and automake are 1.9.5 here): perhaps we should just change the script to "aclocal" and "automake", rather than expect specific versions? ...anyway, here's what I used to configure, based on some email suggestion of tim's: ./configure --enable-lockfree --enable-newhash --enable-jack --enable- fftw --enable-simd --enable-optimize=G4 --enable-atomic --enable- debug --prefix=/Users/tigital/devel_0_38 --libdir=/Users/tigital/dev/ libs --enable-fftw ...sidenote: is this the correct way to tell configure where my fftw3f is? I have it in a non-standard place... ...and here's where the compile dies: if gcc -DPACKAGE_NAME=\"PureData\" -DPACKAGE_TARNAME=\"pd\" - DPACKAGE_VERSION=\"0.38-4-devel-2\" -DPACKAGE_STRING=\"PureData\ 0.38-4-devel-2\" -DPACKAGE_BUGREPORT=\"pd-list(a)iem.at\" -DPACKAGE=\"pd \" -DVERSION=\"0.38-4-devel-2\" -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 - DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 - DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 - DHAVE_LIMITS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 - DHAVE_UNISTD_H=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 - DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 - DHAVE_STRERROR=1 -DDL_OPEN=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 - DHAVE_LIBX11=1 -DHAVE_LIBTK8_4=1 -DUSEAPI_JACK=1 -DUSEAPI_ALSA=1 - DATOMIC=1 -DNEWHASH=1 -DLOCKFREE=1 -DUSEAPI_PORTAUDIO=1 - DPA_BIG_ENDIAN=1 -DMACOSX=1 -I. -I. -DINSTALL_PREFIX=\"/Users/ tigital/devel_0_38\" -fno-strict-aliasing -g -DJACK_XRUN -O2 -MT pd- m_obj.o -MD -MP -MF ".deps/pd-m_obj.Tpo" -c -o pd-m_obj.o `test -f 'm_obj.c' || echo './'`m_obj.c; \ then mv -f ".deps/pd-m_obj.Tpo" ".deps/pd-m_obj.Po"; else rm -f ".deps/pd-m_obj.Tpo"; exit 1; fi m_obj.c: In function 'outlet_bang': m_obj.c:384: error: redeclaration of 'scp_i' with no linkage m_obj.c:373: error: previous declaration of 'scp_i' was here m_obj.c:384: error: 'i' undeclared (first use in this function) m_obj.c:384: error: (Each undeclared identifier is reported only once m_obj.c:384: error: for each function it appears in.) m_obj.c:384: error: 'scp_' undeclared (first use in this function) m_obj.c:384: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_pointer': m_obj.c:414: error: redeclaration of 'scp_i' with no linkage m_obj.c:393: error: previous declaration of 'scp_i' was here m_obj.c:414: error: 'i' undeclared (first use in this function) m_obj.c:414: error: 'scp_' undeclared (first use in this function) m_obj.c:414: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_float': m_obj.c:433: error: redeclaration of 'scp_i' with no linkage m_obj.c:422: error: previous declaration of 'scp_i' was here m_obj.c:433: error: 'i' undeclared (first use in this function) m_obj.c:433: error: 'scp_' undeclared (first use in this function) m_obj.c:433: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_symbol': m_obj.c:452: error: redeclaration of 'scp_i' with no linkage m_obj.c:441: error: previous declaration of 'scp_i' was here m_obj.c:452: error: 'i' undeclared (first use in this function) m_obj.c:452: error: 'scp_' undeclared (first use in this function) m_obj.c:452: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_list': m_obj.c:471: error: redeclaration of 'scp_i' with no linkage m_obj.c:460: error: previous declaration of 'scp_i' was here m_obj.c:471: error: 'i' undeclared (first use in this function) m_obj.c:471: error: 'scp_' undeclared (first use in this function) m_obj.c:471: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_anything': m_obj.c:490: error: redeclaration of 'scp_i' with no linkage m_obj.c:479: error: previous declaration of 'scp_i' was here m_obj.c:490: error: 'i' undeclared (first use in this function) m_obj.c:490: error: 'scp_' undeclared (first use in this function) m_obj.c:490: error: invalid lvalue in asm output 0 make[1]: *** [pd-m_obj.o] Error 1 make: *** [all-recursive] Error 1 ...so, I've looked at the source here, but I don't understand the macro's being used... l8r, jamie

4 8

re: branch convergence
by cr 06 Jul '05

06 Jul '05

hi, my last mail got nuked by the server, did you change config? it never used to have a prob with a faked 'from' field to match the subscribed address... anyways my vote is do away with the numbers. ive made a lot of minor tweaks to devel, which ive already made to impd as well, and definitely don't want to make them a 3rd time (that would be 3 strikes..). to fix/add stuff like: / .pdrc not being read on windows (pd.ini) / not being able to select 2 outs and 6 ins with portaudio / not being able to put tcl in your system path on win32 / no ASIO with non-MSVC on win32. / a few linux64 fixes / merge jsarlo's VST io sppt / almost everything from impd that wasnt in g_* files nonetheless in the actual code theyre too trivial for anyone else to notice, and an order of magnitude smaller than the contributions Tim has made, but i wouldnt want them to get lost..so in order of preference from most to least 1: do away with numbering, and just have a 'devel'. every month or so, make sure it compiles on all 3 platforms and dump into MAIN..theres few enough developers and i dont think theyre stepping on toes and generally work on difft things.. 2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's stuff isnt lost, and so he doesnt have to bug miller or guenter or whoever and possibly paste a bunch of stuff in again and get grey hairs.. 3: crazy all-night frankenstein hack/merge fest with version # change that might lose features and add new bugs.. i mean the same reason i'd vote for 'devel' as rather using debian 'sid' than 'sarge' or something thats doomed (like win32)...

8 41

devel_0_39
by Tim Blechmann 06 Jul '05

06 Jul '05

hi carmen, i tried to work on devel_0_39 again ... saw your extended use of colors ... since it makes patches pretty unreadable, i'd propose to remove it for the first time... i'd like to have all these fancy colors as an optional feature only, but not as default appearance of devel ... anyway, if you adapt your patch to easily customize the gui, i'll include it into devel again ... 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

2 3

Re: [PD-dev] compiling pd-devel & pd 0.38-4 noise on startup
by B. Bogart 01 Jul '05

01 Jul '05

Hi Tim, Thanks for the note I checked out that branch as you suggested. After the autoconf and ./configure I got stuck on the definition of sin(). Seems PD (g_array.c) expects to find sin() in math.h but it seems on my debian sarge /usr/include/math.h does not define sin(). I'm not sure where it is defined... any pointers?? Debian Sarge kernel 2.6.8 I'm keen on trying devel for the first time! :) Also I forgot to run ./bootstrap.sh but upon trying I got ./bootstrap.sh: line 4: aclocal-1.8: command not found I could not find any aclocal package, not on the debian site and not in the apt repository... What package provides "aclocal-1.8"? Ok back onto compiling Gem... Thanks Tim, b> Tim Blechmann wrote: >>I've checked out pd HEAD and I'm not sure if I should have used a >>release tag? Anyhow the usual ./configure does not work due to the >>fact that there is no "configure" file in pd/src. >> >>What tag should I be using? Does compiling pd-devel take steps other >>than the usual ./configure && make depend && make ? > > well first of all HEAD is not devel! > the missing configure script should be easy to rebuild: "cd ./src/ && > autoconf" > > if you want to use devel, i'd recommend to try the branch tagged > "devel_0_38" or the latest tarball on sf.net > there are currently two ways to build devel_0_38, an autoconf system > (after running the ./bootstrap.sh script) or the brand new scons build > system (which will most likely work on linux only, since i don't have > access to a mac and i haven't finished installing windoze on my laptop). > > in general, i'd recomment devel_0_38, since it's pretty stable, has an > improved scheduler tuned for lowest latencies and performs faster due to > handcoded simd code ... > > for the noise problem ... if you can reproduce this on devel, i'd be > willing to look into it ... > > cheers ... tim >

3 7

pow~
by Tim Blechmann 01 Jul '05

01 Jul '05

hi krzysztof, i know that msp has reversed inlets for pow~, but i'd propose to change the inlet order if cyclone is not loaded as maxmode, since it's the same inlet order as pow then ... might break some older patches, but i'd prefer to have a consistent behaviour between normal and ~ objects ... maybe we could also rename pow~ to !pow~ or something similar ... 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

1 0

abs~ benchmarking
by Tim Blechmann 30 Jun '05

30 Jun '05

hi krzysztof, after doing some benchmarking of abs~, i'd suggest the attached patch: - it uses fabsf, which is much faster (possibly a bitmask rather than a branch - it introduces loop unrolling, which speeds up the perform routine as well also it should be easy to write simd code ... but this would break compatibility with miller ... 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

1 0

[ pure-data-Patches-1224768 ] checks for NULL-pointers in g_rtext.c & g_graph.c
by SourceForge.net 30 Jun '05

30 Jun '05

Patches item #1224768, was opened at 2005-06-21 11:57 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224768&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-dev Group: bugfix Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) >Summary: checks for NULL-pointers in g_rtext.c & g_graph.c Initial Comment: most funtions in g_rtext.c do not check whether a passed pointer is non-zero and thus crash with NULL-pointers. the added patch performs these checks. is this a performance hog ??? this should fix BUG-1186531 (which i wasn't able to reproduce at all) ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-30 20:27 Message: Logged In: YES user_id=564396 the same for g_graph.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224768&group_…

1 0

Re: [PD-dev] Trouble compiling PDP on debian sarge
by ydegoyon＠free.fr 30 Jun '05

30 Jun '05

ola, > > Maybe -Werror ?? > > Thanks for taking a stab at it, I guess the PDP folks are on vacation. > yeh, you're right ) but there are nice internet café in maroccan villages )) of course, you should kill all '-Werror', that's the answer. salam, sevy

1 0

[ pure-data-Bugs-1160770 ] crash on saving changed iem-guis in subpatchers
by SourceForge.net 30 Jun '05

30 Jun '05

Bugs item #1160770, was opened at 2005-03-10 18:12 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1160770&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: Fixed Priority: 7 Submitted By: Thomas Grill (xovo) Assigned to: Nobody/Anonymous (nobody) Summary: crash on saving changed iem-guis in subpatchers Initial Comment: A reproducible crash with pd-0.38 stable and devel: try out the attached patch. The patch, contains a subpatcher, containing a iem-numberbox with "init" enabled. When the content is changed and the subpatcher already closed (and the numberbox value not saved yet), saving the patcher will crash pd. This is because in g_graph.c, function glist_grab, x2->gl_editor is used, although it is NULL (subpatcher already closed) ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-30 19:51 Message: Logged In: YES user_id=564396 i have submitted a patch that fixes this at: http://sourceforge.net/tracker/index.php?func=detail&aid=1230498&group_id=5… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1160770&group_…

1 0

[ pure-data-Patches-1230498 ] crash on saving changed iem-guis in subpatchers
by SourceForge.net 30 Jun '05

30 Jun '05

Patches item #1230498, was opened at 2005-06-30 19:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1230498&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: bugfix Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: crash on saving changed iem-guis in subpatchers Initial Comment: as described by t.grill, the "numberbox2" (from the iemguis) crashes pd, when an abstraction is saved, where there is an active nbx2 in a closed subpatch. attached is a patch against 0.38-4 that resolves this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1230498&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 June 2005