Pd-dev June 2008

pd-dev@lists.iem.at

24 participants
90 discussions

[ pure-data-Bugs-1893096 ] pd-0.41-0.msw: path and startup dialog don't show values
by SourceForge.net 12 Jun '08

12 Jun '08

Bugs item #1893096, was opened at 2008-02-13 12:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893096&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: v0.41.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pd-0.41-0.msw: path and startup dialog don't show values Initial Comment: in pd 0.41-0 on msw i set my paths and libraries using the file-path/file-startup dialogs in the gui. the settings seem to be stored all right (according to the windows registry) and the libraries are loaded at next startup. but they don't show up in the path and dialog menus when opened again, so when adding a new library for instace, all the other ones have to be entered again. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-11 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-28 09:18 Message: Logged In: YES user_id=27104 Originator: NO is this still an problem with 0.41-4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893096&group_…

1 0

[ pure-data-Bugs-1976100 ] colorgrid not working on osx
by SourceForge.net 12 Jun '08

12 Jun '08

Bugs item #1976100, was opened at 2008-05-27 23:39 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1976100&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: pd-extended Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: stffn (stffn) Assigned to: Hans-Christoph Steiner (eighthave) Summary: colorgrid not working on osx Initial Comment: colorgrid is not working properly on intel mac osx running Pd-extended 0.40.3 22th of May build. It does output the RGB values when moving the red square around the grid but the there is no colors in the grid so it's fairly pointless. (still no 0.40.3 group to choose from in the dropdown) ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-11 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-28 04:52 Message: Logged In: YES user_id=27104 Originator: NO Ok, this should be fixed in tomorrow's build. Works on my machine. Please test :) ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2008-05-27 23:40 Message: Logged In: YES user_id=1658640 Originator: YES That is pdp_colorgrid of cause. Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1976100&group_…

1 0

[ pure-data-Bugs-1991224 ] [declare -std<path/lib>] crashes on pd 0.42.0-test1
by SourceForge.net 11 Jun '08

11 Jun '08

Bugs item #1991224, was opened at 2008-06-11 19:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1991224&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [declare -std<path/lib>] crashes on pd 0.42.0-test1 Initial Comment: when loading a patch, that contains either a [declare -stdpath] or a [declare -stdlib], pd immediately crashes. testpatch: [declare -stdpath extra/zexy] i tried both, correct and incorrect pathes, also setting the flag -stdpath or -stdlib without any argument at all -> crash. on crash, pd gives me the following output: --------------------------------------------------- roman@yoyo:~$ pd -stderr -verbose declare-test.pd Pd version 0.42-0test1 compiled 19:33:41 Jun 10 2008 port 5402 TCL_LIBRARY="/usr/local/lib/pd/tcl/library" TK_LIBRARY="/usr/local/lib/pd/tk/library" "/usr/local/lib/pd/bin/pd-gui" 5402 Waiting for connection request... ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 2, output channels = 2 opened /dev/dsp for reading and writing setchan 2 error: OSS: SOUND_DSP_READ_CHANNELS failed /dev/dsp opened audio output on /dev/dsp; got 2 channels bytes per sample = 2 setting nfrags = 8, fragsize 1024 audiobuffer set to 50 msec OSS: requested audio buffer size 8820 limited to 8192 already opened it setchan 2 channels originally 1 for /dev/dsp opened audio input device /dev/dsp; got 2 channels bytes per sample = 2 OSS: issuing first ADC 'read' ... ...done. tried /home/roman/declare-test.pd and succeeded *** stack smashing detected ***: pd terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7df3138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7df30f0] pd[0x805bc23] ======= Memory map: ======== 08048000-0811f000 r-xp 00000000 08:06 174205 /usr/local/bin/pd 0811f000-08121000 rw-p 000d6000 08:06 174205 /usr/local/bin/pd 08121000-0824e000 rw-p 08121000 00:00 0 [heap] b7cf9000-b7d03000 r-xp 00000000 08:06 81024 /lib/libgcc_s.so.1 b7d03000-b7d04000 rw-p 0000a000 08:06 81024 /lib/libgcc_s.so.1 b7d04000-b7d06000 rw-p b7d04000 00:00 0 b7d06000-b7e4f000 r-xp 00000000 08:06 98493 /lib/tls/i686/cmov/libc-2.7.so b7e4f000-b7e50000 r--p 00149000 08:06 98493 /lib/tls/i686/cmov/libc-2.7.so b7e50000-b7e52000 rw-p 0014a000 08:06 98493 /lib/tls/i686/cmov/libc-2.7.so b7e52000-b7e55000 rw-p b7e52000 00:00 0 b7e55000-b7e69000 r-xp 00000000 08:06 98519 /lib/tls/i686/cmov/libpthread-2.7.so b7e69000-b7e6b000 rw-p 00013000 08:06 98519 /lib/tls/i686/cmov/libpthread-2.7.so b7e6b000-b7e6d000 rw-p b7e6b000 00:00 0 b7e6d000-b7e90000 r-xp 00000000 08:06 98501 /lib/tls/i686/cmov/libm-2.7.so b7e90000-b7e92000 rw-p 00023000 08:06 98501 /lib/tls/i686/cmov/libm-2.7.so b7e92000-b7e94000 r-xp 00000000 08:06 98499 /lib/tls/i686/cmov/libdl-2.7.so b7e94000-b7e96000 rw-p 00001000 08:06 98499 /lib/tls/i686/cmov/libdl-2.7.so b7e96000-b7ea5000 r-xp 00000000 08:06 342247 /usr/lib/libjack.so.0.0.28 b7ea5000-b7ea7000 rw-p 0000f000 08:06 342247 /usr/lib/libjack.so.0.0.28 b7ea7000-b7eb0000 rw-p b7ea7000 00:00 0 b7eb0000-b7eb7000 r-xp 00000000 08:06 98523 /lib/tls/i686/cmov/librt-2.7.so b7eb7000-b7eb9000 rw-p 00006000 08:06 98523 /lib/tls/i686/cmov/librt-2.7.so b7eb9000-b7f78000 r-xp 00000000 08:06 74264 /usr/lib/libasound.so.2.0.0 b7f78000-b7f7c000 rw-p 000be000 08:06 74264 /usr/lib/libasound.so.2.0.0 b7f8b000-b7f8d000 rw-p b7f8b000 00:00 0 b7f8d000-b7f8e000 r-xp b7f8d000 00:00 0 [vdso] b7f8e000-b7fa8000 r-xp 00000000 08:06 80979 /lib/ld-2.7.so b7fa8000-b7faa000 rw-p 00019000 08:06 80979 /lib/ld-2.7.so bff8d000-bffa2000 rw-p bffeb000 00:00 0 [stack] Pd: signal 6 pd_gui: pd process exited ------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1991224&group_…

1 0

compiling iemlibs on ubuntu hardy
by Roman Haefeli 11 Jun '08

11 Jun '08

hi all i finally switched over from dapper to hardy and compiled all the iemlibs fine (using the original makefiles), but they couldn't be loaded: /usr/local/lib/pd/extra/iemlib/iemlib1.pd_linux: undefined symbol: __stack_chk_fail_local iemlib1: can't load library i got the same error for iemlib2 and iem_mp3 after googling a bit around, i found some forum-posts saying, that this error comes from default settings for gcc, that were changed between ubuntu versions. they also said, that it could be circumvented/fixed (don't know really) by adding '-fno-stack-protector' to the CFLAGS. after applying that change to <pd-svn>/externals/iemlib/Make.include and a recompile, all libs could be loaded fine. to make a long story short: would it cause any harm to change the Make.include file in svn repo accordingly? roman ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

1 0

[ pure-data-Bugs-1945042 ] [avg~] and [tavg~] from zexy broken in pd-ext
by SourceForge.net 11 Jun '08

11 Jun '08

Bugs item #1945042, was opened at 2008-04-17 17:29 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1945042&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: pd-extended Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [avg~] and [tavg~] from zexy broken in pd-ext Initial Comment: my test-patch: [avg~] | [print] doesn't print anything at all, even if audio is turned on or a non-zero signal is sent (e.g. [1 ( - [sig~] ) the same goes for [tavg~] i tested with pd-extended-0.40.3-20080308 on ubuntu dapper. ---------------------- the same behaviour i get with a current checkout of zexy from pd-svn, when i use the pd-extended makefile and compile zexy like this: cd pd-svn/externals make zexy -------------------------- [avg~] and [tavg~] work perfectly, if i compile them with the original makefile: cd pd-svn/externals/zexy/src ./configure make the resulting zexy.pd_linux _doesn't have his bug --------------------- -> the problem seems to be related to how zexy is compiled and not to the source of avg~ or tavg~. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-06-11 14:39 Message: Logged In: YES user_id=564396 Originator: NO i cannot reproduce this using Pd-0.40.3-extended-20080611-debian-testing-i386.deb and should this be a "bug" rather than a "patch" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1945042&group_…

1 0

[ pure-data-Patches-1990686 ] load abstractions using sys_loader
by SourceForge.net 11 Jun '08

11 Jun '08

Patches item #1990686, was opened at 2008-06-11 11:52 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990686&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: wishlist >Status: Closed >Resolution: Invalid Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: load abstractions using sys_loader Initial Comment: in the current implementation "external" objects are loaded using a "sys_loader" mechanism, whereas "abstractions" are handled in a special way. the attached patch tries to remove this special handling by using the "sys_loader" mechanism for abstractions as well. WHY: there are several reasons for why i want this patch: - unification of object loading (why would we want to handle abstractions and "externals" separately?) - loading speed (currently when try to create an abstraction [foo], Pd will start searching all of its paths for foo.l_i386 and foo.pd_linux, then it will call all other loaders to try to open "foo" and finally it will search the all paths for "foo.pd"; if i use the abstraction multiple times, i will repeat all(!) of the above steps; when using the loader-mechanism this can be improved as we already know that a certain object is implemented as an abstraction; therefore there is no need to try to load the object via (e.g.) a dll-loader or the lua-loader. esp. when running with "-verbose", i have encountered a speedup from 37.941seconds to 14.350seconds when openeing a largish patch (without "-verbose" the speedup should be smaller though) - (external) hexloader likes to call sys_load_lib() recursively with mangled names; with this patch hexloader (and other advanced stuff) will be working with abstractions as well COMPATIBILITY ISSUES: currently i cannot think of any; the abstraction load is still called after all other loaders; abstractions are still read from file as they are instantiated NOTE: this patch requires patch-#1990599 to be applied beforehand http://sourceforge.net/tracker/index.php?func=detail&aid=1990599&group_id=5… ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-06-11 12:43 Message: Logged In: YES user_id=564396 Originator: YES actually it doesn't do everything promised; i will try to fix it an reopen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990686&group_…

1 0

[ pure-data-Patches-1990686 ] load abstractions using sys_loader
by SourceForge.net 11 Jun '08

11 Jun '08

Patches item #1990686, was opened at 2008-06-11 11:52 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=1990686&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: wishlist Status: Open Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: load abstractions using sys_loader Initial Comment: in the current implementation "external" objects are loaded using a "sys_loader" mechanism, whereas "abstractions" are handled in a special way. the attached patch tries to remove this special handling by using the "sys_loader" mechanism for abstractions as well. WHY: there are several reasons for why i want this patch: - unification of object loading (why would we want to handle abstractions and "externals" separately?) - loading speed (currently when try to create an abstraction [foo], Pd will start searching all of its paths for foo.l_i386 and foo.pd_linux, then it will call all other loaders to try to open "foo" and finally it will search the all paths for "foo.pd"; if i use the abstraction multiple times, i will repeat all(!) of the above steps; when using the loader-mechanism this can be improved as we already know that a certain object is implemented as an abstraction; therefore there is no need to try to load the object via (e.g.) a dll-loader or the lua-loader. esp. when running with "-verbose", i have encountered a speedup from 37.941seconds to 14.350seconds when openeing a largish patch (without "-verbose" the speedup should be smaller though) - (external) hexloader likes to call sys_load_lib() recursively with mangled names; with this patch hexloader (and other advanced stuff) will be working with abstractions as well COMPATIBILITY ISSUES: currently i cannot think of any; the abstraction load is still called after all other loaders; abstractions are still read from file as they are instantiated NOTE: this patch requires patch-#1990599 to be applied beforehand http://sourceforge.net/tracker/index.php?func=detail&aid=1990599&group_id=5… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990686&group_…

1 0

[ pure-data-Patches-1990599 ] allow recursive calls of new_anything()
by SourceForge.net 11 Jun '08

11 Jun '08

Patches item #1990599, was opened at 2008-06-11 10:36 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=1990599&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: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: allow recursive calls of new_anything() Initial Comment: currently there is a protection mechanism against recursively calling "new_anything()". unfortunately this mechanism is the main obstacle that prevents abstractions to be loaded via a "loader" mechanism (and instead requires special case handling) the attached patch will allow some recursive calling of new_anything() (but still has a protection against stack overflow, at a depth of MAXOBJDEPTH=1000) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990599&group_…

1 0

[ pure-data-Patches-1990592 ] prevent multiple registration of loaders
by SourceForge.net 11 Jun '08

11 Jun '08

Patches item #1990592, was opened at 2008-06-11 10:30 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=1990592&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: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: prevent multiple registration of loaders Initial Comment: if a single loader is registered multiple times with sys_register_loader(), it will be inserted multiple times in the loader-chain. thus it might be called several times when a new object is instantiated. i guess this could be considered a feature, but i was not able to think of any application that would need such a feature. otoh i stumbled across it, as a (rather naive) implementation of a new loader registered itself permanently, resulting in a very long list of identical loaders to be executed (yes, the bug was in my loader code, but still i think it rather weird that a loader can be registered several times) so here is a tiny patch that will prevent already registered loaders to be added to the list of loaders. --- s_loader.c (Revision 9979) +++ s_loader.c (Arbeitskopie) @@ -218,6 +218,9 @@ loader_queue_t *q = &loaders; while (1) { + /* prevent loaders from being registered multiple times */ + if (q->loader == loader) return; + if (q->next) q = q->next; else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990592&group_…

1 0

Problem building externals on VC++2008
by PSPunch 11 Jun '08

11 Jun '08

Hi, Using VC++2008 Express on WinXP-SP2, Referring to "How to write an External in Puredata" http://pdstatic.iem.at/externals-HOWTO/ In short, the code "helloworld" builds and runs fine on both pd-Vanilla0.39 and the latest nightly build of pd-extended. However, the second demonstration "counter" does not work as it lacks symbolic links to _s_float. Following is an "excerpt" of the output message since parts of the original message is in a foreign language. hworld.obj : error LNK2001: External symbol "_s_float" unresolved. fatal error LNK1120: 1 unresolved externals I've found previous posts going back to 2003 with similar issues of _s_**** not being resolved under VC++ so I am imagining this particular situation is somewhat an FAQ. The sad part is that I found no useful solution suggested. Does anyone have any idea of what is going on? -- David Shimamoto

1 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 2008