Pd-dev October 2006

pd-dev@lists.iem.at

13 participants
72 discussions

[ pure-data-Patches-1549377 ] fix crash on sending empty "obj" mesage to closed canvas
by SourceForge.net 10 Oct '06

10 Oct '06

Patches item #1549377, was opened at 2006-08-30 17:39 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1549377&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: 7 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: fix crash on sending empty "obj" mesage to closed canvas Initial Comment: as described in bug #1525832, pd crashes when you send a "msg" or "obj" message (without coordinates and arguments) to a canvas that is not visible (e.g. closed). this is due to the fact, that inthis case, pd automatically goes into edit mode, so you can type in the content of the object/message (it's like creating an empty object-box with Ctrl-1). this is a not so clever thing, when the canvas is closed. attached is a patch that fixes this, by checking whether the canvas is visible and refusing to continue otherwise ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 15:28 Message: Logged In: YES user_id=564396 raised priority, since a crasher should be fixed. added a patch to reliably reproduce the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1549377&group_…

1 0

[ pure-data-Bugs-1427520 ] Link broken in Help patch for netsend
by SourceForge.net 10 Oct '06

10 Oct '06

Bugs item #1427520, was opened at 2006-02-08 14:34 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1427520&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: abstractions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Piotr Majdak (piotrmajdak) >Assigned to: Miller Puckette (millerpuckette) Summary: Link broken in Help patch for netsend Initial Comment: In netsend-help.pd is a link given, which seems to be broken: ftp://fals.ch/pub/pdnets ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 15:21 Message: Logged In: YES user_id=564396 for intercommunication with max, i suggest to use OSC. nevertheless, the link is really broken (fals.ch does not exist anymore), and should therefore be removed from the help-patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1427520&group_…

1 0

[ pure-data-Bugs-1508138 ] program crash leads to system crash
by SourceForge.net 10 Oct '06

10 Oct '06

Bugs item #1508138, was opened at 2006-06-18 15:47 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1508138&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: v0.39.2 Status: Open Resolution: None Priority: 5 Submitted By: JoÃ£o Miguel Pais (jmmmp) Assigned to: Nobody/Anonymous (nobody) Summary: program crash leads to system crash Initial Comment: If pd crashes once (for whichever reason it may be), when the program is loaded again a system error occurs, and a blue screen appears. The error message of the blue screen is IRQL_NOT_LESS_OR_EQUAL *** STOP: 0X0000000A (0X00000004, 0X00000002, 0X00000000, 0X804E39A7) Therefore, if pd crashes, it is necessary to reboot the system in order to avoid a system crash (logging out doesn't help). Pd-ext 0.39-2 t3 XP Prof ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 15:13 Message: Logged In: YES user_id=564396 "I don't have a patch, because it was corrected already (I don't remember now)." does this mean that it works now? can we close this? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-19 08:49 Message: Logged In: NO then also try to test your RAM sanity, with software like memtest86.... it could be a bad bank of ram... ---------------------------------------------------------------------- Comment By: JoÃ£o Miguel Pais (jmmmp) Date: 2006-06-18 22:01 Message: Logged In: YES user_id=1523458 The problem has nothing to do with audio, as actually in most of the cases I didn't had audio on. I don't have a patch, because it was corrected already (I don't remember now). But the error that made pd crash the first time might had to do with a cpu overload (or whatever is it called) due to an infinite loop. Which kind of hardware info is necessary? I guess saying IBM Thinkpad R51 1,6Mhz 1GbRam doesn't help much. ---------------------------------------------------------------------- Comment By: Thomas Grill (xovo) Date: 2006-06-18 19:24 Message: Logged In: YES user_id=350252 Although the information given about the crash is close to nothing (for whichever reason that may be), it's almost certainly a driver bug, not a pure pd bug. You should include info about what you are doing (include patches, description etc.) and about your hardware. And you should try to find newer/ different drivers for your audio hardware and see if the problem persists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1508138&group_…

1 0

[ pure-data-Bugs-1563095 ] bug in iemlib's for++
by SourceForge.net 10 Oct '06

10 Oct '06

Bugs item #1563095, was opened at 2006-09-21 21:13 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1563095&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: v0.39.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: bug in iemlib's for++ Initial Comment: There is a bug with the iemlib for++ object in PD- extended: I discovered a workaround to load for++ for now: 1. try to make an object [for++] -> PD will say that there is no object like for++ 2. try to make an object [forpp] -> PD will say that there is no object like forpp 3. try again to make an object [for++] -> et viola , there is thefor++ I was looking for cheers, Nils ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-09-26 08:40 Message: Logged In: NO Not a fix, but another workaround: I've checked in a for++.pd abstraction, which is compatible with the IEMLIB-external. It's in the CVS at http://pure-data.cvs.sourceforge.net/pure-data/abstractions/purepd/ ciao -- fbar ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-09-22 16:01 Message: Logged In: YES user_id=27104 This is most likely because the class name is "for++", but the source filename is "forpp.c". I think + is a valid character for the filesystem, otherwise it could be renamed using the hex loader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1563095&group_…

1 0

[ pure-data-Bugs-1573656 ] $arg-expansion gives error with old patches
by SourceForge.net 10 Oct '06

10 Oct '06

Bugs item #1573656, was opened at 2006-10-09 13:06 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&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.40.1 Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: $arg-expansion gives error with old patches Initial Comment: with the advent of the new and better $arg-expansion (namely: expansion of $args _within_ an argument, like bla-$2-blu), old patches (<0.40) that used dollars within symbols are somewhat broken. example1: iemlib provides an object [parentdollarnull] with an alias [parent$0]; the latter gets expanded (e.g. to [parent1003]) and cannot be created. THIS IS NO BUG (imho) however, $0 is not only expanded on a logic level, but also on a visible level (i really see [parent1003]); this i believe IS a bug. example2 (more important!): in the olde times, if a symbol contained dollars within, it was saved (in the .pd file) like "bla-$2-blu". in pd=0.40.0, the same symbol gets saved as "bla-\$2-blu" (note the backslash). loading an old abstraction yields an error ("argument out of range"), even if enough arguments (in this case: 2) are supplied. the expansion works correctly though! imho, either the warning should be supressed or the old behaviour (no expansion) should be preserved. (it would be good if the pd-version at the time of saving would be stored in the .pd-fileformat in order to allow such things) this little script should replace all "$<n>" with a missing backslash at the beginning with "\$<n>" find . -name "*.pd" | while read f do sed -i -e 's|$[^\\]$\$|\1\\$|g' $f done note on the script: i haven't done excessive testing, but it seems to work; make backups before you apply it, since it will change all affected files without asking) note: it seems like old versions (tested with pd-0.39-2) seem to be able to correctly read files saved with pd-0.40-0 ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 15:00 Message: Logged In: YES user_id=564396 sorry if i was unclear here: dollar-expansion in class-names is a feature that i would _hate_ to miss. i think it is really important to do any thing more complex. (that is why i wrote in HUGE letters that i do not consider this a bug). the problem described is rather a bug in the iemlib (it shouldn't have used a name like [parent$0] in the first place.) however, i do think it a bug, that the classname [parent$0] is replaced by [parent1001] (literally!) the main bug report here was about pd-0.40 not being able to read older patches (created with pd-0.39) without an error-message. ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2006-10-09 18:45 Message: Logged In: YES user_id=801174 PureUnity uses dollar-expansion in class names, so an exception cannot be made for class names, especially because PureUnity has no other way to implement its feature set. I call this feature "abstraction templates" or "class templates": [f.swap], [~.swap], [#.swap] are like swap<float>, swap<signal>, swap<grid> would be in C++. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-09 13:11 Message: Logged In: YES user_id=564396 also confirmed with 0.40.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&group_…

1 0

corelibs, build system
by IOhannes m zmoelnig 10 Oct '06

10 Oct '06

corelibs is currently broken due to a renaming of pd/src/d_mayer_fft.c to pd/src/d_fft_mayer.c while i updated the corelibs/generate.sh script to handle this, it still does not really work with the autobuild-system. the reason for this is (imo) the very complicated stacking of Makefiles (externals/Makefile vs. externals/corelibs/Makefile) which makes it impossible for a make-noob like me, to generate the .c files in the makefile while calling make in /externals (it does work fine when i do just "make" in externals/corelibs. the reason is, that CORELIBS_OBJECTS is evaluated before the files are generated (which would result in NO objects, since there should be no .c files before generation) a simple solution would be, to call "make -c corelibs/ generate" and then "make -C corelibs/" from the externals/Makefile. obviously this does not work, since externals/corelibs/Makefile has no logic and instead uses externals/Makefile with the "corelibs" target (which would make my idea quite recursive). then again there is the horror of touching externals/Makefile at all: this huge file makes it quite hard/impossible to work on / fix several targets at the same time. e.g. yesterday i first worked on corelibs, then noticed that zexy won't build as it should, so i had to revert all the changes i had done to the Makefile (since it didn't yet work properly) so i could start fixing the zexy-build (which i understand better, and which i was pretty sure to be able to fix). so i ask this again: would it not be better to have the build-logic for each directory in a separate Makefile (which could be edited separately)? these Makefile could make use of a generic(!) Makefile which (e.g.) lives in externals/ this generic Makefile MUST NOT have any intelligence about the separate destination targets (e.g. no different logic for building "corelibs" or "hid"; just a generic "build" target); if such intelligence is needed, it should live in the projects subdirectory (externals/corelibs/Makefile) i would also like to know the exact reason for the pwd-magic (i just never ever needed such thing in any makefile i wrote, so i'm curious) mfg.asdr IOhannes

2 7

[ pure-data-Bugs-1573656 ] $arg-expansion gives error with old patches
by SourceForge.net 09 Oct '06

09 Oct '06

Bugs item #1573656, was opened at 2006-10-09 07:06 Message generated for change (Comment added) made by matju You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&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.40.1 Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: $arg-expansion gives error with old patches Initial Comment: with the advent of the new and better $arg-expansion (namely: expansion of $args _within_ an argument, like bla-$2-blu), old patches (<0.40) that used dollars within symbols are somewhat broken. example1: iemlib provides an object [parentdollarnull] with an alias [parent$0]; the latter gets expanded (e.g. to [parent1003]) and cannot be created. THIS IS NO BUG (imho) however, $0 is not only expanded on a logic level, but also on a visible level (i really see [parent1003]); this i believe IS a bug. example2 (more important!): in the olde times, if a symbol contained dollars within, it was saved (in the .pd file) like "bla-$2-blu". in pd=0.40.0, the same symbol gets saved as "bla-\$2-blu" (note the backslash). loading an old abstraction yields an error ("argument out of range"), even if enough arguments (in this case: 2) are supplied. the expansion works correctly though! imho, either the warning should be supressed or the old behaviour (no expansion) should be preserved. (it would be good if the pd-version at the time of saving would be stored in the .pd-fileformat in order to allow such things) this little script should replace all "$<n>" with a missing backslash at the beginning with "\$<n>" find . -name "*.pd" | while read f do sed -i -e 's|$[^\\]$\$|\1\\$|g' $f done note on the script: i haven't done excessive testing, but it seems to work; make backups before you apply it, since it will change all affected files without asking) note: it seems like old versions (tested with pd-0.39-2) seem to be able to correctly read files saved with pd-0.40-0 ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2006-10-09 12:45 Message: Logged In: YES user_id=801174 PureUnity uses dollar-expansion in class names, so an exception cannot be made for class names, especially because PureUnity has no other way to implement its feature set. I call this feature "abstraction templates" or "class templates": [f.swap], [~.swap], [#.swap] are like swap<float>, swap<signal>, swap<grid> would be in C++. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-09 07:11 Message: Logged In: YES user_id=564396 also confirmed with 0.40.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&group_…

1 0

[ pure-data-Patches-1564800 ] a few old MACOSX macros have crept back in
by SourceForge.net 09 Oct '06

09 Oct '06

Patches item #1564800, was opened at 2006-09-25 03:57 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1564800&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: a few old MACOSX macros have crept back in Initial Comment: A few of the old MACOSX manually defined macros have crept back into the source. Everywhere else, its __APPLE__ which is the preferred macro to use, plus it automatically defined. The attached patch replaces the offending macros. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-09 13:15 Message: Logged In: YES user_id=564396 seems to be fixed in 0.40.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1564800&group_…

1 0

[ pure-data-Bugs-1573656 ] $arg-expansion gives error with old patches
by SourceForge.net 09 Oct '06

09 Oct '06

1 0

[ pure-data-Bugs-1573656 ] $arg-expansion gives error with old patches
by SourceForge.net 09 Oct '06

09 Oct '06

Bugs item #1573656, was opened at 2006-10-09 13:06 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=1573656&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.40.0 Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: $arg-expansion gives error with old patches Initial Comment: with the advent of the new and better $arg-expansion (namely: expansion of $args _within_ an argument, like bla-$2-blu), old patches (<0.40) that used dollars within symbols are somewhat broken. example1: iemlib provides an object [parentdollarnull] with an alias [parent$0]; the latter gets expanded (e.g. to [parent1003]) and cannot be created. THIS IS NO BUG (imho) however, $0 is not only expanded on a logic level, but also on a visible level (i really see [parent1003]); this i believe IS a bug. example2 (more important!): in the olde times, if a symbol contained dollars within, it was saved (in the .pd file) like "bla-$2-blu". in pd=0.40.0, the same symbol gets saved as "bla-\$2-blu" (note the backslash). loading an old abstraction yields an error ("argument out of range"), even if enough arguments (in this case: 2) are supplied. the expansion works correctly though! imho, either the warning should be supressed or the old behaviour (no expansion) should be preserved. (it would be good if the pd-version at the time of saving would be stored in the .pd-fileformat in order to allow such things) this little script should replace all "$<n>" with a missing backslash at the beginning with "\$<n>" find . -name "*.pd" | while read f do sed -i -e 's|$[^\\]$\$|\1\\$|g' $f done note on the script: i haven't done excessive testing, but it seems to work; make backups before you apply it, since it will change all affected files without asking) note: it seems like old versions (tested with pd-0.39-2) seem to be able to correctly read files saved with pd-0.40-0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&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 October 2006