Pd-dev July 2008

pd-dev@lists.iem.at

25 participants
100 discussions

[ pure-data-Bugs-2026128 ] [list trim] outputs mystery type after conversion
by SourceForge.net 24 Jul '08

24 Jul '08

Bugs item #2026128, was opened at 2008-07-23 23:02 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026128&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: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: [list trim] outputs mystery type after conversion Initial Comment: If you start with a symbolic atom in a symbol message, then run it thru a [list trim], you end up with a mystery type that is just a numeric atom, but does not work as a float message. see attached patch for an example ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2008-07-24 01:36 Message: Logged In: YES user_id=569446 Originator: NO Yeah, these "mystery types" can be confusing, but in reality they are just ordinary symbols with a pure numeric data part. Note that these numeric symbols are not numbers or floats! [list trim] removes the selector, so after that you have a "1234" string without selector (or with "symbol 1234" as selector, but minus the "symbol" part. You can covert this back to a Pd-symbol with a [symbol] or [list] object. However as you cannot represent numberic symbols in a saved Pd patch, you cannot use [select 1234] or [route 1234] to select or route them. However you can use [select -DUMMY-] and prime that with a numeric symbol created with [makefilename %d] construct to its left inlet to select numeric symbols. The same "trick" is used to select backslashes or other for example split a symbol at any other "unusual" symbol using [list2symbol]. Try 92---[makefilename %c] to split at backslashes, for example. Anyway, there's nothing mysterious about numeric symbols, they are just unusual in Pd. I think, we had similar confusions before in the bug tracker, but I didn't check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026128&group_…

1 0

[ pure-data-Bugs-2026159 ] Debian testing: change dependencies
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #2026159, was opened at 2008-07-23 23:36 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=2026159&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.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Mayer (elvettsemic) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Debian testing: change dependencies Initial Comment: As the Debian multimedia repositories (deb http://www.debian-multimedia.org lenny main) have switched from lame 3.97 to 3.98, the name of the library has changed as well from liblame0 to libmp3lame0. As the Debian packages of Pd-extended depend on that lib, pd-extended should do the switch as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026159&group_…

1 0

[ pure-data-Bugs-2026128 ] [list trim] outputs mystery type after conversion
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #2026128, was opened at 2008-07-23 17:02 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=2026128&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: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: [list trim] outputs mystery type after conversion Initial Comment: If you start with a symbolic atom in a symbol message, then run it thru a [list trim], you end up with a mystery type that is just a numeric atom, but does not work as a float message. see attached patch for an example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026128&group_…

1 0

[ pure-data-Bugs-1996275 ] floats show as 6 digits, but implemented at higher precision
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #1996275, was opened at 2008-06-17 12:38 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) >Summary: floats show as 6 digits, but implemented at higher precision Initial Comment: Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this: http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programmin… //compares if the float f1 is equal with f2 and returns 1 if true and 0 if false int compare_float(float f1, float f2) { float precision = 0.00001; if (((f1 - precision) < f2) && ((f1 + precision) > f2)) { return 1; } else { return 0; } } ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 16:56 Message: Logged In: YES user_id=27104 Originator: YES This is a more fundamental bug then. It is not just [print] that is limited to 6 digits. You can't represent more than six digits in anything that gets saved. Yet things in the C implementation are working at higher precision. That's a pretty serious disconnect between what's happening in the implementation and how it is represented in Pd. For example, anytime you have you any number with more than 6 digits in an object or message box, and you save the patch, it'll be automatically rounded to 6 digits. Also, consider the attached patch, it shows that using [moses] can be similarly misrepresented. I don't think that the pd_precision.pd patch represents this issue very well. Yes, this is a known issue, but this is just another illustration of where it's a problem. I have forgotten what is the source of this disconnect. File Added: float-precision-misrepresentation.pd ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 10:33 Message: Logged In: YES user_id=564396 Originator: NO attached is a patch that simulates what you experienced. btw, it is rather simple to quantize your numbers with an abstraction, if you don't need full precision. also it might be a nice feature to [change] to allow a certain fuzziness. i guess you could submit a feature-request for this instead of this bug-report. File Added: pd_precision.pd ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 10:23 Message: Logged In: YES user_id=564396 Originator: NO ah i see, but this is a misunderstanding on your side. Pd uses _full_ precision of floats. however it will only display (and save) a number with a limited precision. i don't think we should change [change] just because [print] is unable to show enough precision. if you use [tgl] instead of [print] you will notice that even more values look the same :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 10:08 Message: Logged In: YES user_id=27104 Originator: YES Since this comparison is happening in C space, it is done using the full precision of the float. But Pd only uses 6 digits of precision, so the comparison should match that, not what is happening in C space. Basically, I hooked up a [change]-[print] to some sensor data, and it was quite common to see the exact same number printed out one after the other. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 03:26 Message: Logged In: YES user_id=564396 Originator: NO do you have a practical example that exposes the bug? in theory you are of course right, but in practice i wonder how this can be applied to [change]. e.g. if i send "1" and the result of "2/2" to change, i might consider these two as different enough :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&group_…

1 0

[ pure-data-Bugs-2025905 ] wiisense crashes Pd-extended
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #2025905, was opened at 2008-07-23 12:16 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2025905&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.40.2 >Status: Closed Resolution: None >Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) >Assigned to: Nobody/Anonymous (nobody) Summary: wiisense crashes Pd-extended Initial Comment: When using WiiSense with Pd-extended on Windows, it crashs Pd-extended. When using Pd-0.41-4, it doesn't crash Pd. This was tested with: Windows XPSP2 Pd-extended 0.40.3-rc4 Pd-vanilla 0.41-4 Pd-vanilla 0.40-2 WiiSense 17 On Pd-vanilla, this is the error message: WiiSense build 17 by Prashant Vaibhav http://wiisense.googlecode.com/ Calibration data: 9.000000 8.000000 36.000000 8.000000 35.000000 8.000000 35.000000 9.000000 10.000000 WiiSense: Can't see any Wiimote error: WiiSense - Exception while processing method: Unknown exception On Pd-extended, it crashes leaving this: WiiSense build 17 by Prashant Vaibhav http://wiisense.googlecode.com/ Calibration data: 9.000000 8.000000 36.000000 8.000000 35.000000 8.000000 35.000000 9.000000 10.000000 WiiSense: Can't see any Wiimote ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 12:28 Message: Logged In: YES user_id=27104 Originator: YES Oops, it seems that the source to WiiSense is not available, so not a whole lot I can do about fixing this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2025905&group_…

1 0

[ pure-data-Bugs-2025905 ] wiisense crashes Pd-extended
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #2025905, was opened at 2008-07-23 12:16 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=2025905&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.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Hans-Christoph Steiner (eighthave) Summary: wiisense crashes Pd-extended Initial Comment: When using WiiSense with Pd-extended on Windows, it crashs Pd-extended. When using Pd-0.41-4, it doesn't crash Pd. This was tested with: Windows XPSP2 Pd-extended 0.40.3-rc4 Pd-vanilla 0.41-4 Pd-vanilla 0.40-2 WiiSense 17 On Pd-vanilla, this is the error message: WiiSense build 17 by Prashant Vaibhav http://wiisense.googlecode.com/ Calibration data: 9.000000 8.000000 36.000000 8.000000 35.000000 8.000000 35.000000 9.000000 10.000000 WiiSense: Can't see any Wiimote error: WiiSense - Exception while processing method: Unknown exception On Pd-extended, it crashes leaving this: WiiSense build 17 by Prashant Vaibhav http://wiisense.googlecode.com/ Calibration data: 9.000000 8.000000 36.000000 8.000000 35.000000 8.000000 35.000000 9.000000 10.000000 WiiSense: Can't see any Wiimote ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2025905&group_…

1 0

[ pure-data-Bugs-1996275 ] [change] lets some duplicates thru
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #1996275, was opened at 2008-06-17 18:38 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: [change] lets some duplicates thru Initial Comment: Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this: http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programmin… //compares if the float f1 is equal with f2 and returns 1 if true and 0 if false int compare_float(float f1, float f2) { float precision = 0.00001; if (((f1 - precision) < f2) && ((f1 + precision) > f2)) { return 1; } else { return 0; } } ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 16:33 Message: Logged In: YES user_id=564396 Originator: NO attached is a patch that simulates what you experienced. btw, it is rather simple to quantize your numbers with an abstraction, if you don't need full precision. also it might be a nice feature to [change] to allow a certain fuzziness. i guess you could submit a feature-request for this instead of this bug-report. File Added: pd_precision.pd ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 16:23 Message: Logged In: YES user_id=564396 Originator: NO ah i see, but this is a misunderstanding on your side. Pd uses _full_ precision of floats. however it will only display (and save) a number with a limited precision. i don't think we should change [change] just because [print] is unable to show enough precision. if you use [tgl] instead of [print] you will notice that even more values look the same :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 16:08 Message: Logged In: YES user_id=27104 Originator: YES Since this comparison is happening in C space, it is done using the full precision of the float. But Pd only uses 6 digits of precision, so the comparison should match that, not what is happening in C space. Basically, I hooked up a [change]-[print] to some sensor data, and it was quite common to see the exact same number printed out one after the other. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 09:26 Message: Logged In: YES user_id=564396 Originator: NO do you have a practical example that exposes the bug? in theory you are of course right, but in practice i wonder how this can be applied to [change]. e.g. if i send "1" and the result of "2/2" to change, i might consider these two as different enough :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&group_…

1 0

[ pure-data-Bugs-1996275 ] [change] lets some duplicates thru
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #1996275, was opened at 2008-06-17 18:38 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: [change] lets some duplicates thru Initial Comment: Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this: http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programmin… //compares if the float f1 is equal with f2 and returns 1 if true and 0 if false int compare_float(float f1, float f2) { float precision = 0.00001; if (((f1 - precision) < f2) && ((f1 + precision) > f2)) { return 1; } else { return 0; } } ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 16:23 Message: Logged In: YES user_id=564396 Originator: NO ah i see, but this is a misunderstanding on your side. Pd uses _full_ precision of floats. however it will only display (and save) a number with a limited precision. i don't think we should change [change] just because [print] is unable to show enough precision. if you use [tgl] instead of [print] you will notice that even more values look the same :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 16:08 Message: Logged In: YES user_id=27104 Originator: YES Since this comparison is happening in C space, it is done using the full precision of the float. But Pd only uses 6 digits of precision, so the comparison should match that, not what is happening in C space. Basically, I hooked up a [change]-[print] to some sensor data, and it was quite common to see the exact same number printed out one after the other. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 09:26 Message: Logged In: YES user_id=564396 Originator: NO do you have a practical example that exposes the bug? in theory you are of course right, but in practice i wonder how this can be applied to [change]. e.g. if i send "1" and the result of "2/2" to change, i might consider these two as different enough :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&group_…

1 0

[ pure-data-Bugs-2007191 ] [sssad] does not create on pd-extended
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #2007191, was opened at 2008-06-30 18:44 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2007191&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: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: hardoff (hardoff) Assigned to: Hans-Christoph Steiner (eighthave) Summary: [sssad] does not create on pd-extended Initial Comment: there is a similar bug report below, but here are further details: creating a [sssad] object in pd-extended causes the following error in the console: libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path ...about 1000 times, and then finally says: error: maximum object loading depth 1000 reached sssad ... couldn't create several people have suggested that there is a glitch in the libdir loader that won't allow for an abstraction to have the same name as its enclosing folder. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 10:17 Message: Logged In: YES user_id=27104 Originator: NO It turns out that this is a duplicate of #1965894 "libdir loader can't handle classname same as library name", so I am deleting this one. http://sourceforge.net/tracker/index.php?func=detail&aid=1965894&group_id=5… ---------------------------------------------------------------------- Comment By: boonier (boonier) Date: 2008-07-21 17:21 Message: Logged In: YES user_id=1915214 Originator: NO my apologies - i wasnt logged in... smills[at]rootsix.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2007191&group_…

1 0

[ pure-data-Bugs-1965894 ] libdir loader can't handle classname same as library name
by SourceForge.net 23 Jul '08

23 Jul '08

Bugs item #1965894, was opened at 2008-05-17 05:55 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&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: Open Resolution: None Priority: 5 Private: No Submitted By: eerne (eerne) >Assigned to: Hans-Christoph Steiner (eighthave) >Summary: libdir loader can't handle classname same as library name Initial Comment: with Pd-0.40.3-extended-20080516-macosx104-i386.dmg the sssad-help.pd file does not work out of the box. libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create sssad-example ... couldn't create ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 10:15 Message: Logged In: YES user_id=27104 Originator: NO The problem is somewhere in the relationship of the libdir loader and Pd's logic for checking if it has already loaded a binary library. If you load a libdir called "blah", you won't be able to load [blah/blah] or [blah]. ---------------------------------------------------------------------- Comment By: hardoff (hardoff) Date: 2008-06-30 18:43 Message: Logged In: YES user_id=1816568 Originator: NO creating a [sssad] object in pd-extended causes the following error in the console: libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path ...about 1000 times, and then finally says: error: maximum object loading depth 1000 reached sssad ... couldn't create several people have suggested that there is a glitch in the libdir loader that won't allow for an abstraction to have the same name as its enclosing folder. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-28 19:03 Message: Logged In: NO I named the private subdirectory "_sssad" just randomly, loosly inspired by Pyton's convention of using underscores for private stuff. I wasn't thinking of some libdir conflict at that time at all. As the sssad "library" consists of only one object I didn't consider namespacing for it at all. I haven't used libdirs so far, but I think, objects which have the same name as the libdir should be possible as well. --Frank (not logged in, but believe me it's me) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-28 11:58 Message: Logged In: YES user_id=27104 Originator: NO so the problem is that the libdir for sssad is currently called 'sssad'. Since the main object is also called 'sssad', there is a nameconflict. Frank must have found this himself, since he named the included folder '_sssad'. I am not really sure how to solve this, except include sssad in a different library. Any suggestions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 July 2008