Pd-dev July 2008

pd-dev@lists.iem.at

25 participants
100 discussions

[ pure-data-Bugs-1956973 ] problems with "jack fixes and enhancements" patch
by SourceForge.net 26 Jul '08

26 Jul '08

Bugs item #1956973, was opened at 2008-05-03 19:14 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1956973&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: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Dan Wilcox (danomatika) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: problems with "jack fixes and enhancements" patch Initial Comment: Ok, After upgrading to Ubuntu Hardy I tried pd with jack and everything seemingly was working. Today I sat down to do some music using my external usb sound card (Edirol UA-25) and lo and behold Pd goes nuts. All afternoon I have tracked down these issues using Pd-0.40.3-extended-20080408-debian-stable-i386.deb from the autobuilds. - the -jack startup flag does not work - if using the -jack startup flag, trying using the jack selection in Media does not work, you cannot make the jack connection to work - starting pd without the -jack startup flag allows you to select jack from Media and make the connection - trying to connect to jack (once again from the Media menu) if its controlling an EXTERNAL audio device immediately slows down X to about 5fps and causes Pulseaudio to stutter. Everything is fine on killing pd. As suggested by Hans, I tried a build before the recent jack bugfix patch (http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/…) and I am able to connect to the external card running jack ... but the startup flag does not work. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-26 12:24 Message: Logged In: YES user_id=27104 Originator: NO Sounds like its fixed, nice work IOhannes. Thanks for testing, Dan. ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-07-26 00:27 Message: Logged In: YES user_id=2032867 Originator: YES The Jack hiccups with the external soundcard are gone using the Pd-0.40.3-extended-20080725-ubuntu-hardy-i386.deb build. I can confirm the jack startup flag now works as well. Sweet. ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-05-15 13:43 Message: Logged In: YES user_id=2032867 Originator: YES OK, I have tested the 2 builds as suggested: - Pd-0.40.3-extended-20080414-debian-testing * jack connection works fine, both on internal laptop and usb soundcards * the "-jack" startup flag fails making the jack connection and once pd starts, it cannot be started via the media menu either (the little check boxes in the jack popup are not checked, and checking them has no effect). pd has to be restarted without the flag and jack chosen through the menu for jack to work. * a little pulseaudio stuttering when pd first starts (but not a big problem, probably my slow laptop) - Pd-0.40.3-extended-20080416-debian-testing-i386 * jack connection works on internal soundcard * jack connection on my usb soundcard does not work - choosing jack from the media menu causes either a segfault or a 5 fps X and heavily stuttering pulseaudio (running on the internal card) - once the popup appears things return to normal (the boxes are checked too), but performance goes crazy again once the popup is clicked - closing the pd window returns things to normal when the close pd dialog appears * jack startup flag still does not work as noted above * no pulseaudio stuttering on pd startup, just on pd exit ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-15 09:08 Message: Logged In: YES user_id=27104 Originator: NO danomatika, could you try testing a build from 2008-04-14 and 2008-04-16, right before and after the commit that we think is causing the problem? That would remove a lot of variables as to waht might be causing this problem. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-04 14:44 Message: Logged In: YES user_id=27104 Originator: NO This bug looks to be related to patch #1942258, which was included in Pd-extended 0.40.3 as of 2008-04-15 ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-05-04 14:44 Message: Logged In: YES user_id=2032867 Originator: YES After a little testing today the -jack flag works fine using the earlier the Pd-0.40.3-extended-20080210-debian-stable-i386.deb build. So it must be something in the bugfix that messes up using external cards ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1956973&group_…

1 0

[ pure-data-Bugs-2026128 ] symbol/float definition, implementation, and docs unclear
by SourceForge.net 26 Jul '08

26 Jul '08

Bugs item #2026128, was opened at 2008-07-23 17:02 Message generated for change (Settings changed) made by eighthave 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: symbol/float definition, implementation, and docs unclear 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-26 05:35 Message: Logged In: YES user_id=569446 Originator: NO If you want 1234 to be a number, then don't use [makefilename %d] to deliberatly turn it into a symbol! As soon as you've created a symbol out of 1234, it behaves like a symbol until you convert it back. Pd doesn't have a builtin object to turn symbols into numbers (e.g. "tonumber" in Lua) but that's a different bug. Regarding duck-typing, even in Python the following raises an error: >>> a = 1234 >>> a.__str__() '1234' >>> 5678 + a.__str__() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'str' as does 1 + "2". If you want to file a documentation bug, then please do so. If you want to remove the ability to create symbols with digits from Pd, then file a feature request. If you want A_SYMBOLs with only digits to be treated as floats everywhere (which is practically the same as removing the ability to create such symbols), then again file a feature request about this. But the bug report you've written (just read it again) does not describe any of this. I believe I've said all there is in this matter. I'm too tired now to continue to play bug-status ping-pong so this was my last response. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 17:19 Message: Logged In: YES user_id=27104 Originator: YES If this behavior is intended and desired, then it should be documented. I personally think that Pd should follow duck-typing style with this question, and that might be a problem bigger than this one place. Since you are a big fan of langauges that use duck-typing (Lua, Python), I am surprised that you think this is not a problem. I put all of the definitions that I could find of Pd's atoms here http://puredata.info/dev/PdDefinitions and this is what I found on this topic: Pd Manual 2.1.2: "Atoms are either numbers or symbols like +. " Pd Manual 2.6.1: "...atom (number/symbol)..." Pd Manual 2.1.2: "Anything that is not a valid number is considered a symbol." >From float-help.pd: "The float object stores a number" >From all the references I could find where Miller defines floats and symbols, it seems pretty clear that the intention was to have anything that we perceive as a number interpreted as a float. I agree with this and think that it should be consistently implemented throughout Pd. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-25 02:09 Message: Logged In: YES user_id=569446 Originator: NO I repeat: There is *no* mystery type, please don't invent things without reason. What is there is a symbol with numeric content after [makefilename]. It acts like any other symbol, nothing else, nothing undocumented. [list trim] removes the selector so you're left with the bare symbol. You can get it back with [symbol] or [list]. Without "symbol"-selector it rightfully doesn't match [route symbol] or [select 1234], only to its own selector, which is symbol("1234") that you can create again with [makefilename], as numeric-symbol.pd shows. Pd cannot save these symbols, but never promised to do so. I'm putting you're report into "Pending" now, it is vague and invalid. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 23:24 Message: Logged In: YES user_id=27104 Originator: YES This discussion is going quite far afield from the original issue. I can see no reason why there should be such a mystery type, given the current type system. So either it should be fixed or documented. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 02:20 Message: Logged In: YES user_id=569446 Originator: NO Oh, and logically the negation of "Anything that is not a valid number is considered a symbol." is not: "Everything that looks like a valid number is a float." Numeric symbols created with makefilename aren't valid numbers. Besides that, the sentence you quote is in chapter "2.1.2. object boxes" and only deals with how Pd reads the content of object boxes, not with the general type system of Pd. Pointers or gemstates wouild be example of "not a valid number"s which still aren't symbols. But pointers cannot be used in object boxes neither. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 02:09 Message: Logged In: YES user_id=569446 Originator: NO Then you should report that "inconsistency" and not something else. The behaviour you dislike has nothing to do with [list trim] nor with conversions nor mysteries. The only problem here is, that certain symbols cannot directly be represented in Pd's patch format. This includes symbols with a pure numeric content - which Pd reads as numbers in a patch file - but also many other symbols like those for whitespace characters (SPACE, TAB,...), the backslash etc. To use these, you have to create them with something like [makefilename], but after that, they get treated correctly by all builtin objects, especially [select] or [list]. See attached example. File Added: numeric-symbol.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 00:40 Message: Logged In: YES user_id=27104 Originator: YES This is a question of how should Pd behave, now how it currently does. If there is supposed to be such a thing as "a symbolic atom that is a number, but without a symbol selector", then it should be fully supported and documented. But this is the current definition of a symbolic atom (Pd manual 2.1.2): "Anything that is not a valid number is considered a symbol." By taking the converse of the above rule, "1234" looks like a valid number so it should be a float. That inconsistency is the bug that I am trying to highlight. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-23 19:38 Message: Logged In: YES user_id=569446 Originator: NO I hope even with all my spelling mistakes you can understand my previous post ... Is it possible to edit posts? ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-23 19: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-2026128 ] [list trim] outputs mystery type after conversion
by SourceForge.net 26 Jul '08

26 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-26 11:35 Message: Logged In: YES user_id=569446 Originator: NO If you want 1234 to be a number, then don't use [makefilename %d] to deliberatly turn it into a symbol! As soon as you've created a symbol out of 1234, it behaves like a symbol until you convert it back. Pd doesn't have a builtin object to turn symbols into numbers (e.g. "tonumber" in Lua) but that's a different bug. Regarding duck-typing, even in Python the following raises an error: >>> a = 1234 >>> a.__str__() '1234' >>> 5678 + a.__str__() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'str' as does 1 + "2". If you want to file a documentation bug, then please do so. If you want to remove the ability to create symbols with digits from Pd, then file a feature request. If you want A_SYMBOLs with only digits to be treated as floats everywhere (which is practically the same as removing the ability to create such symbols), then again file a feature request about this. But the bug report you've written (just read it again) does not describe any of this. I believe I've said all there is in this matter. I'm too tired now to continue to play bug-status ping-pong so this was my last response. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 23:19 Message: Logged In: YES user_id=27104 Originator: YES If this behavior is intended and desired, then it should be documented. I personally think that Pd should follow duck-typing style with this question, and that might be a problem bigger than this one place. Since you are a big fan of langauges that use duck-typing (Lua, Python), I am surprised that you think this is not a problem. I put all of the definitions that I could find of Pd's atoms here http://puredata.info/dev/PdDefinitions and this is what I found on this topic: Pd Manual 2.1.2: "Atoms are either numbers or symbols like +. " Pd Manual 2.6.1: "...atom (number/symbol)..." Pd Manual 2.1.2: "Anything that is not a valid number is considered a symbol." >From float-help.pd: "The float object stores a number" >From all the references I could find where Miller defines floats and symbols, it seems pretty clear that the intention was to have anything that we perceive as a number interpreted as a float. I agree with this and think that it should be consistently implemented throughout Pd. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-25 08:09 Message: Logged In: YES user_id=569446 Originator: NO I repeat: There is *no* mystery type, please don't invent things without reason. What is there is a symbol with numeric content after [makefilename]. It acts like any other symbol, nothing else, nothing undocumented. [list trim] removes the selector so you're left with the bare symbol. You can get it back with [symbol] or [list]. Without "symbol"-selector it rightfully doesn't match [route symbol] or [select 1234], only to its own selector, which is symbol("1234") that you can create again with [makefilename], as numeric-symbol.pd shows. Pd cannot save these symbols, but never promised to do so. I'm putting you're report into "Pending" now, it is vague and invalid. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 05:24 Message: Logged In: YES user_id=27104 Originator: YES This discussion is going quite far afield from the original issue. I can see no reason why there should be such a mystery type, given the current type system. So either it should be fixed or documented. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 08:20 Message: Logged In: YES user_id=569446 Originator: NO Oh, and logically the negation of "Anything that is not a valid number is considered a symbol." is not: "Everything that looks like a valid number is a float." Numeric symbols created with makefilename aren't valid numbers. Besides that, the sentence you quote is in chapter "2.1.2. object boxes" and only deals with how Pd reads the content of object boxes, not with the general type system of Pd. Pointers or gemstates wouild be example of "not a valid number"s which still aren't symbols. But pointers cannot be used in object boxes neither. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 08:09 Message: Logged In: YES user_id=569446 Originator: NO Then you should report that "inconsistency" and not something else. The behaviour you dislike has nothing to do with [list trim] nor with conversions nor mysteries. The only problem here is, that certain symbols cannot directly be represented in Pd's patch format. This includes symbols with a pure numeric content - which Pd reads as numbers in a patch file - but also many other symbols like those for whitespace characters (SPACE, TAB,...), the backslash etc. To use these, you have to create them with something like [makefilename], but after that, they get treated correctly by all builtin objects, especially [select] or [list]. See attached example. File Added: numeric-symbol.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 06:40 Message: Logged In: YES user_id=27104 Originator: YES This is a question of how should Pd behave, now how it currently does. If there is supposed to be such a thing as "a symbolic atom that is a number, but without a symbol selector", then it should be fully supported and documented. But this is the current definition of a symbolic atom (Pd manual 2.1.2): "Anything that is not a valid number is considered a symbol." By taking the converse of the above rule, "1234" looks like a valid number so it should be a float. That inconsistency is the bug that I am trying to highlight. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 01:38 Message: Logged In: YES user_id=569446 Originator: NO I hope even with all my spelling mistakes you can understand my previous post ... Is it possible to edit posts? ---------------------------------------------------------------------- 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-1956973 ] problems with "jack fixes and enhancements" patch
by SourceForge.net 26 Jul '08

26 Jul '08

Bugs item #1956973, was opened at 2008-05-03 18:14 Message generated for change (Comment added) made by danomatika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1956973&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: 7 Private: No Submitted By: Dan Wilcox (danomatika) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: problems with "jack fixes and enhancements" patch Initial Comment: Ok, After upgrading to Ubuntu Hardy I tried pd with jack and everything seemingly was working. Today I sat down to do some music using my external usb sound card (Edirol UA-25) and lo and behold Pd goes nuts. All afternoon I have tracked down these issues using Pd-0.40.3-extended-20080408-debian-stable-i386.deb from the autobuilds. - the -jack startup flag does not work - if using the -jack startup flag, trying using the jack selection in Media does not work, you cannot make the jack connection to work - starting pd without the -jack startup flag allows you to select jack from Media and make the connection - trying to connect to jack (once again from the Media menu) if its controlling an EXTERNAL audio device immediately slows down X to about 5fps and causes Pulseaudio to stutter. Everything is fine on killing pd. As suggested by Hans, I tried a build before the recent jack bugfix patch (http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/…) and I am able to connect to the external card running jack ... but the startup flag does not work. ---------------------------------------------------------------------- >Comment By: Dan Wilcox (danomatika) Date: 2008-07-25 23:27 Message: Logged In: YES user_id=2032867 Originator: YES The Jack hiccups with the external soundcard are gone using the Pd-0.40.3-extended-20080725-ubuntu-hardy-i386.deb build. I can confirm the jack startup flag now works as well. Sweet. ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-05-15 12:43 Message: Logged In: YES user_id=2032867 Originator: YES OK, I have tested the 2 builds as suggested: - Pd-0.40.3-extended-20080414-debian-testing * jack connection works fine, both on internal laptop and usb soundcards * the "-jack" startup flag fails making the jack connection and once pd starts, it cannot be started via the media menu either (the little check boxes in the jack popup are not checked, and checking them has no effect). pd has to be restarted without the flag and jack chosen through the menu for jack to work. * a little pulseaudio stuttering when pd first starts (but not a big problem, probably my slow laptop) - Pd-0.40.3-extended-20080416-debian-testing-i386 * jack connection works on internal soundcard * jack connection on my usb soundcard does not work - choosing jack from the media menu causes either a segfault or a 5 fps X and heavily stuttering pulseaudio (running on the internal card) - once the popup appears things return to normal (the boxes are checked too), but performance goes crazy again once the popup is clicked - closing the pd window returns things to normal when the close pd dialog appears * jack startup flag still does not work as noted above * no pulseaudio stuttering on pd startup, just on pd exit ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-15 08:08 Message: Logged In: YES user_id=27104 Originator: NO danomatika, could you try testing a build from 2008-04-14 and 2008-04-16, right before and after the commit that we think is causing the problem? That would remove a lot of variables as to waht might be causing this problem. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-04 13:44 Message: Logged In: YES user_id=27104 Originator: NO This bug looks to be related to patch #1942258, which was included in Pd-extended 0.40.3 as of 2008-04-15 ---------------------------------------------------------------------- Comment By: Dan Wilcox (danomatika) Date: 2008-05-04 13:44 Message: Logged In: YES user_id=2032867 Originator: YES After a little testing today the -jack flag works fine using the earlier the Pd-0.40.3-extended-20080210-debian-stable-i386.deb build. So it must be something in the bugfix that messes up using external cards ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1956973&group_…

1 0

[ pure-data-Bugs-1964787 ] Pd-ext 0.40.3 alsamidi startup flag broken in Ubuntu Hardy
by SourceForge.net 26 Jul '08

26 Jul '08

Bugs item #1964787, was opened at 2008-05-15 14:09 Message generated for change (Comment added) made by danomatika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&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: Dan Wilcox (danomatika) Assigned to: Nobody/Anonymous (nobody) Summary: Pd-ext 0.40.3 alsamidi startup flag broken in Ubuntu Hardy Initial Comment: In any of the autobuilds of 0.40.3, the "-alsamidi" startup flag selects the checkbox for Alsamidi in the media menu, but the actual midi I/O ports are not created aka aconnect -io does not show them. Upon selecting Alsamidi in the media menu, the proper connections appear. ---------------------------------------------------------------------- >Comment By: Dan Wilcox (danomatika) Date: 2008-07-25 23:22 Message: Logged In: YES user_id=2032867 Originator: YES Still a problem for me as I need pd to open its midi ports automatically. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-18 13:50 Message: Logged In: YES user_id=27104 Originator: NO have you tried this on Pd-vanilla 0.41? I wonder if there is different behavior there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&group_…

1 0

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

25 Jul '08

Bugs item #2026128, was opened at 2008-07-23 17:02 Message generated for change (Comment added) made by eighthave 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: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 17:19 Message: Logged In: YES user_id=27104 Originator: YES If this behavior is intended and desired, then it should be documented. I personally think that Pd should follow duck-typing style with this question, and that might be a problem bigger than this one place. Since you are a big fan of langauges that use duck-typing (Lua, Python), I am surprised that you think this is not a problem. I put all of the definitions that I could find of Pd's atoms here http://puredata.info/dev/PdDefinitions and this is what I found on this topic: Pd Manual 2.1.2: "Atoms are either numbers or symbols like +. " Pd Manual 2.6.1: "...atom (number/symbol)..." Pd Manual 2.1.2: "Anything that is not a valid number is considered a symbol." >From float-help.pd: "The float object stores a number" >From all the references I could find where Miller defines floats and symbols, it seems pretty clear that the intention was to have anything that we perceive as a number interpreted as a float. I agree with this and think that it should be consistently implemented throughout Pd. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-25 02:09 Message: Logged In: YES user_id=569446 Originator: NO I repeat: There is *no* mystery type, please don't invent things without reason. What is there is a symbol with numeric content after [makefilename]. It acts like any other symbol, nothing else, nothing undocumented. [list trim] removes the selector so you're left with the bare symbol. You can get it back with [symbol] or [list]. Without "symbol"-selector it rightfully doesn't match [route symbol] or [select 1234], only to its own selector, which is symbol("1234") that you can create again with [makefilename], as numeric-symbol.pd shows. Pd cannot save these symbols, but never promised to do so. I'm putting you're report into "Pending" now, it is vague and invalid. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 23:24 Message: Logged In: YES user_id=27104 Originator: YES This discussion is going quite far afield from the original issue. I can see no reason why there should be such a mystery type, given the current type system. So either it should be fixed or documented. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 02:20 Message: Logged In: YES user_id=569446 Originator: NO Oh, and logically the negation of "Anything that is not a valid number is considered a symbol." is not: "Everything that looks like a valid number is a float." Numeric symbols created with makefilename aren't valid numbers. Besides that, the sentence you quote is in chapter "2.1.2. object boxes" and only deals with how Pd reads the content of object boxes, not with the general type system of Pd. Pointers or gemstates wouild be example of "not a valid number"s which still aren't symbols. But pointers cannot be used in object boxes neither. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 02:09 Message: Logged In: YES user_id=569446 Originator: NO Then you should report that "inconsistency" and not something else. The behaviour you dislike has nothing to do with [list trim] nor with conversions nor mysteries. The only problem here is, that certain symbols cannot directly be represented in Pd's patch format. This includes symbols with a pure numeric content - which Pd reads as numbers in a patch file - but also many other symbols like those for whitespace characters (SPACE, TAB,...), the backslash etc. To use these, you have to create them with something like [makefilename], but after that, they get treated correctly by all builtin objects, especially [select] or [list]. See attached example. File Added: numeric-symbol.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 00:40 Message: Logged In: YES user_id=27104 Originator: YES This is a question of how should Pd behave, now how it currently does. If there is supposed to be such a thing as "a symbolic atom that is a number, but without a symbol selector", then it should be fully supported and documented. But this is the current definition of a symbolic atom (Pd manual 2.1.2): "Anything that is not a valid number is considered a symbol." By taking the converse of the above rule, "1234" looks like a valid number so it should be a float. That inconsistency is the bug that I am trying to highlight. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-23 19:38 Message: Logged In: YES user_id=569446 Originator: NO I hope even with all my spelling mistakes you can understand my previous post ... Is it possible to edit posts? ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-23 19: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-1996275 ] floats show as 6 digits, but implemented at higher precision
by SourceForge.net 25 Jul '08

25 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-25 10:09 Message: Logged In: YES user_id=27104 Originator: YES I updated float-precision-misrepresentation.pd to make it clear that the width of the object box is not causing the rounding. File Added: float-precision-misrepresentation.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 10:07 Message: Logged In: YES user_id=27104 Originator: YES So this doesn't just happen on saving, but also on loading. I attached long_floats.pd which I edited with emacs to have 9 digit floats. They get rounded to 6 digits upon load. Also, just typing a number with more than 6 digits into an object box rounds it once the object is created. So my guess is that this problem is caused by conversion to binbufs rather than saving the file as was previously mentioned. File Added: long_floats.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 23:37 Message: Logged In: YES user_id=27104 Originator: YES "floats show as 6 digits, but implemented at higher precision" outlines the inconsistency, which is the bug in question. Feel free to rewrite the title if you think you can make a clearer description. (But please don't do it out of spite, like switching the bug to Invalid.) This is the key to this problem: [float 0.100000001490116119384765625] gets rounded to 6 digits. I don't know the exact source of the problem. If you do, please tell us. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 11:21 Message: Logged In: YES user_id=564396 Originator: NO my patch 10percent.pd illustrated exactly the problem you initially reported and which is still described in the summary line. i don't know what bug you want to report exactly, but what you say in the subject ("floats show as 6 digits, but implemented at higher precision") is imho invalid as a bug-report (and thus a waste of time; we agree here). so i closed it (but of course i will now leave it open) if you want a binary patch-format with full precision, you should file a feature request (preferrably a new one). if you think that the text patch-format should is buggy as it discards precision, you should say so in the bug-report. your analogy to C's printf is invalid insofar, as you can do the same with Pd, either as shown in my 10percent.pd patch or by using [makefilename]'s formatting. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 11:05 Message: Logged In: YES user_id=27104 Originator: YES Why would you close the bug if you agree that there is a problem? "The only valid issue i can see is, that precision gets lost when saving and re-loading a patch". As for the 10percent.pd patch, that is just wasting our time, since that is demonstrating the manual control of display precision, not the bug that we are talking about. No other programming language that I use has this problem. With C, you have the power to control the precision that is displayed with printf(), for example. And if you set a variable in C, the editor doesn't automatically round it off to 6 digits when you save it. float myNumber = 0.100000001490116119384765625; versus: [float 0.100000001490116119384765625] ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 04:26 Message: Logged In: YES user_id=564396 Originator: NO imho, this bug-report "floats show as 6 digits, but implemented at higher precision" is invalid. first of all, i don't see how loat-precision-misrepresentation.pd is any more helpful than my patch. it only illustrates that Pd is working correctly (0.999999+9e-7 is 0.9999999 which IS smaller than 1 and therefore correctly outputs the value to the left outlet of [moses]). the rest is just a matter of representation (see attached 10percent.pd patch) you are surely aware that "all that is gold does not glitter" and a visual representation is not necessary the thing per se. showing a 32bit floating point value is always problematic: either you sacrifice precision (in the display!) or you sacrifice readability. this get's worse by the fact that floating point numbers do a bad job in representing numbers whose nominators are not power-of-2. e.g. "0.1" really cannot be expressed with a floating point number; the closest you can get is about "0.100000001490116119384765625". this is the reason why Pd does not try to display the _exact_ value of a number but rather accepts a little rounding: i guess you would file a bug-report if the result of 1/10 would show up as "0.100000001490116119384765625" see http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conver… for more information on this dilemma. a less sophisticated way would be to display the floating-point numbers as 4byte binaries (display "0x3DCCCCCD" instead of "0.1") it needs some time to get used to it, but once you are there... another way to make Pd represent all numbers exactly, is to limit Pd's valid numbers, e.g. to just integers. the only valid issue i can see is, that precision gets lost when saving and re-loading a patch; the obvious fix for this is to use a binary format. you could file a feature-request for such a thing if you really need it. File Added: 10percent.pd ---------------------------------------------------------------------- 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-1996275 ] floats show as 6 digits, but implemented at higher precision
by SourceForge.net 25 Jul '08

25 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-25 10:07 Message: Logged In: YES user_id=27104 Originator: YES So this doesn't just happen on saving, but also on loading. I attached long_floats.pd which I edited with emacs to have 9 digit floats. They get rounded to 6 digits upon load. Also, just typing a number with more than 6 digits into an object box rounds it once the object is created. So my guess is that this problem is caused by conversion to binbufs rather than saving the file as was previously mentioned. File Added: long_floats.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 23:37 Message: Logged In: YES user_id=27104 Originator: YES "floats show as 6 digits, but implemented at higher precision" outlines the inconsistency, which is the bug in question. Feel free to rewrite the title if you think you can make a clearer description. (But please don't do it out of spite, like switching the bug to Invalid.) This is the key to this problem: [float 0.100000001490116119384765625] gets rounded to 6 digits. I don't know the exact source of the problem. If you do, please tell us. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 11:21 Message: Logged In: YES user_id=564396 Originator: NO my patch 10percent.pd illustrated exactly the problem you initially reported and which is still described in the summary line. i don't know what bug you want to report exactly, but what you say in the subject ("floats show as 6 digits, but implemented at higher precision") is imho invalid as a bug-report (and thus a waste of time; we agree here). so i closed it (but of course i will now leave it open) if you want a binary patch-format with full precision, you should file a feature request (preferrably a new one). if you think that the text patch-format should is buggy as it discards precision, you should say so in the bug-report. your analogy to C's printf is invalid insofar, as you can do the same with Pd, either as shown in my 10percent.pd patch or by using [makefilename]'s formatting. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 11:05 Message: Logged In: YES user_id=27104 Originator: YES Why would you close the bug if you agree that there is a problem? "The only valid issue i can see is, that precision gets lost when saving and re-loading a patch". As for the 10percent.pd patch, that is just wasting our time, since that is demonstrating the manual control of display precision, not the bug that we are talking about. No other programming language that I use has this problem. With C, you have the power to control the precision that is displayed with printf(), for example. And if you set a variable in C, the editor doesn't automatically round it off to 6 digits when you save it. float myNumber = 0.100000001490116119384765625; versus: [float 0.100000001490116119384765625] ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-24 04:26 Message: Logged In: YES user_id=564396 Originator: NO imho, this bug-report "floats show as 6 digits, but implemented at higher precision" is invalid. first of all, i don't see how loat-precision-misrepresentation.pd is any more helpful than my patch. it only illustrates that Pd is working correctly (0.999999+9e-7 is 0.9999999 which IS smaller than 1 and therefore correctly outputs the value to the left outlet of [moses]). the rest is just a matter of representation (see attached 10percent.pd patch) you are surely aware that "all that is gold does not glitter" and a visual representation is not necessary the thing per se. showing a 32bit floating point value is always problematic: either you sacrifice precision (in the display!) or you sacrifice readability. this get's worse by the fact that floating point numbers do a bad job in representing numbers whose nominators are not power-of-2. e.g. "0.1" really cannot be expressed with a floating point number; the closest you can get is about "0.100000001490116119384765625". this is the reason why Pd does not try to display the _exact_ value of a number but rather accepts a little rounding: i guess you would file a bug-report if the result of 1/10 would show up as "0.100000001490116119384765625" see http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conver… for more information on this dilemma. a less sophisticated way would be to display the floating-point numbers as 4byte binaries (display "0x3DCCCCCD" instead of "0.1") it needs some time to get used to it, but once you are there... another way to make Pd represent all numbers exactly, is to limit Pd's valid numbers, e.g. to just integers. the only valid issue i can see is, that precision gets lost when saving and re-loading a patch; the obvious fix for this is to use a binary format. you could file a feature-request for such a thing if you really need it. File Added: 10percent.pd ---------------------------------------------------------------------- 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-2027531 ] Help/Search input field not accessible.
by SourceForge.net 25 Jul '08

25 Jul '08

Bugs item #2027531, was opened at 2008-07-25 07:09 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=2027531&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: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Help/Search input field not accessible. Initial Comment: Pd-0.40-extended-rc4 from at.ot.at on osx 10.5.3 i386 Help/Search input field cursor blinking but can not write search query. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2027531&group_…

1 0

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

25 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: Pending 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-25 08:09 Message: Logged In: YES user_id=569446 Originator: NO I repeat: There is *no* mystery type, please don't invent things without reason. What is there is a symbol with numeric content after [makefilename]. It acts like any other symbol, nothing else, nothing undocumented. [list trim] removes the selector so you're left with the bare symbol. You can get it back with [symbol] or [list]. Without "symbol"-selector it rightfully doesn't match [route symbol] or [select 1234], only to its own selector, which is symbol("1234") that you can create again with [makefilename], as numeric-symbol.pd shows. Pd cannot save these symbols, but never promised to do so. I'm putting you're report into "Pending" now, it is vague and invalid. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-25 05:24 Message: Logged In: YES user_id=27104 Originator: YES This discussion is going quite far afield from the original issue. I can see no reason why there should be such a mystery type, given the current type system. So either it should be fixed or documented. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 08:20 Message: Logged In: YES user_id=569446 Originator: NO Oh, and logically the negation of "Anything that is not a valid number is considered a symbol." is not: "Everything that looks like a valid number is a float." Numeric symbols created with makefilename aren't valid numbers. Besides that, the sentence you quote is in chapter "2.1.2. object boxes" and only deals with how Pd reads the content of object boxes, not with the general type system of Pd. Pointers or gemstates wouild be example of "not a valid number"s which still aren't symbols. But pointers cannot be used in object boxes neither. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 08:09 Message: Logged In: YES user_id=569446 Originator: NO Then you should report that "inconsistency" and not something else. The behaviour you dislike has nothing to do with [list trim] nor with conversions nor mysteries. The only problem here is, that certain symbols cannot directly be represented in Pd's patch format. This includes symbols with a pure numeric content - which Pd reads as numbers in a patch file - but also many other symbols like those for whitespace characters (SPACE, TAB,...), the backslash etc. To use these, you have to create them with something like [makefilename], but after that, they get treated correctly by all builtin objects, especially [select] or [list]. See attached example. File Added: numeric-symbol.pd ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-24 06:40 Message: Logged In: YES user_id=27104 Originator: YES This is a question of how should Pd behave, now how it currently does. If there is supposed to be such a thing as "a symbolic atom that is a number, but without a symbol selector", then it should be fully supported and documented. But this is the current definition of a symbolic atom (Pd manual 2.1.2): "Anything that is not a valid number is considered a symbol." By taking the converse of the above rule, "1234" looks like a valid number so it should be a float. That inconsistency is the bug that I am trying to highlight. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-24 01:38 Message: Logged In: YES user_id=569446 Originator: NO I hope even with all my spelling mistakes you can understand my previous post ... Is it possible to edit posts? ---------------------------------------------------------------------- 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

← 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