Pd-dev March 2010

pd-dev@lists.iem.at

21 participants
81 discussions

verbose(), sys_verbose, and recommended practice
by Hans-Christoph Steiner 05 Mar '10

05 Mar '10

Hey Martin, I think this would be a good question for pd-dev, hope you don't mind that I forwarded it there: On Mar 4, 2010, at 2:10 PM, <martin.peach(a)sympatico.ca> <martin.peach(a)sympatico.ca > wrote: > > Hi Hans, > > Thanks for pointing this out. I guess the new recommended practice > is to use > if (sys_verbose) post() > for non-essential messages, and pd_error() for problems? > If so I guess I should make my externals consistent with that. > > Martin > > ---------------------------------------- >> From: hans(a)at.or.at >> To: martin.peach(a)sympatico.ca >> Subject: verbose mode >> Date: Thu, 4 Mar 2010 11:49:01 -0500 >> >> >> Hey Martin, >> >> I just saw this check-in. Do you know about the sys_verbose in >> s_stuff.h and verbose() in m_pd.h? Its the global built-in stuff for >> verbosity. IOhannes has been trying to make it more useful, but it is >> somewhat useful now. >> >> .hc >> >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 02 Mar 2010 17:44:37 +0000 >>> From: mrpeach(a)users.sourceforge.net >>> Subject: [PD-cvs] SF.net SVN: pure-data:[13193] >>> trunk/externals/mrpeach/net >>> To: pd-cvs(a)iem.at >>> Message-ID: >>> Content-Type: text/plain; charset=UTF-8 >>> >>> Revision: 13193 >>> http://pure-data.svn.sourceforge.net/pure-data/?rev=13193&view=rev >>> Author: mrpeach >>> Date: 2010-03-02 17:44:36 +0000 (Tue, 02 Mar 2010) >>> >>> Log Message: >>> ----------- >>> Added a verbosity method to stop [tcpclient] printing in the main >>> window every time it connects/disconnects. >>> Updated the help patch to match. >>> >>> Modified Paths: >>> -------------- >>> trunk/externals/mrpeach/net/tcpclient-help.pd >>> trunk/externals/mrpeach/net/tcpclient.c >>> >>> >>> This was sent by the SourceForge.net collaborative development >>> platform, the world's largest Open Source development site. >> >> >> >> ---------------------------------------------------------------------------- >> >> News is what people want to keep hidden and everything else is >> publicity. - Bill Moyers >> >> > ---------------------------------------------------------------------------- There is no way to peace, peace is the way. -A.J. Muste

2 1

Re: [PD-dev] seeking advice on Pd gui overhaul
by Jeff Mann 03 Mar '10

03 Mar '10

I have an interest in using Pd on smaller embedded platforms, such as ARM-based ones. Especially with the higher-end ARM chips with floating point units these days, I think Pd could have some interesting applications on the new tablets and various other ARM-based devices coming down the pipes - or already out there. Personally I work a lot with sensors, actuators, and control systems for interactive installations, and being able to run on multiple small, inexpensive processors without requiring a PC, is a big advantage that Pd has over Max, for example. You can see with the PDa project, that it seems the gui is one of the biggest barriers to getting it to work on many different platforms. So, if anyone's considering writing a non-tcl/tk gui, I'd like to give a nudge towards Qt rather than juce. While juce can apparently work with the iPhone, no-one has used it on any other non-intel system as far as I can tell. On the other hand, we have Qt/Embedded, which is very mature and is the standard in the area of PDAs and all kinds of mobile and embedded platforms. It doesn't even necessarily need X11, as it provides its own small-footprint windowing system. Having said that, I understand that the first step would really need to be a cleaner interface between pd-core and pd-gui. From what I've read, there's a lot of drawing stuff going on inside pd-core that really expects to be working with tcl/tk. It doesn't seem to make sense to go ahead with a non-tcl/tk gui before this is sorted out. So, if people have programming energy to contribute, maybe that's a good starting point. Another advantage to that is to reduce the load and improve the ability to run pd-core on small "headless" processors, communicating with pd-gui over a network. I don't know if any of this is particularly relevant or useful to anyone else, since my use-case is perhaps not so common. But I thought I'd just throw it into the ring for consideration. Thanks! <Jeff

2 1

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2957058, was opened at 2010-02-23 01:11 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pointer to [route symbol]-[print] crashes pd Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- >Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 16:58 Message: Oops, I didn't realize that when lists get distributed the atoms are interpreted, just like the [list] object classes. E.g., I though the following would output an error but it works fine: [list one two( | [select symbol] You know, since [route list] has different behaviors depending on whether the first element is a float or symbol, the same could be done for [route pointer]-- strip the selector off of anythings, pass gpointer messages through unchanged. That way there is at least some consistency, in the sense that the selector is always being matched. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-03-01 13:41 Message: Hi Jonathan, that's not really what I meant. You can use pointers in a list-message of course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on. Even [pipe] works with pointers and lists of pointers now. But when you strip a lone pointer from it's selector then the pointer itself could become the selector like: "list set 2"->[route list] becomes "set 2" and this will call the "set"-method of the next object. If this is a message box it will be set to "2". But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>", so now it would try to use some "<pt>" method, which is probably undefined. BTW: I guess that's what leads to the crash here. I think selectors must be symbols. So to make use of the pointless pointer (pun intended :) one probably has to attach a selector again with [list] or [pointer] or something. Anyway I guess we're now talking about the usefulness of route's implementation, which is debatable and led to the development of several nicer variants in GridFlow. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 12:48 Message: Hi Frank, Is it really useless? If you send a gpointer through the following, it works: [rewind $1( | [pointer] That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.) ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 07:16 Message: I meant to write: useless just like a "gem_state" stripped of its *selector*. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 07:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-28 22:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 11:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 00:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 03:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2957058, was opened at 2010-02-23 06:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pointer to [route symbol]-[print] crashes pd Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-03-01 18:41 Message: Hi Jonathan, that's not really what I meant. You can use pointers in a list-message of course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on. Even [pipe] works with pointers and lists of pointers now. But when you strip a lone pointer from it's selector then the pointer itself could become the selector like: "list set 2"->[route list] becomes "set 2" and this will call the "set"-method of the next object. If this is a message box it will be set to "2". But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>", so now it would try to use some "<pt>" method, which is probably undefined. BTW: I guess that's what leads to the crash here. I think selectors must be symbols. So to make use of the pointless pointer (pun intended :) one probably has to attach a selector again with [list] or [pointer] or something. Anyway I guess we're now talking about the usefulness of route's implementation, which is debatable and led to the development of several nicer variants in GridFlow. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 17:48 Message: Hi Frank, Is it really useless? If you send a gpointer through the following, it works: [rewind $1( | [pointer] That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.) ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 12:16 Message: I meant to write: useless just like a "gem_state" stripped of its *selector*. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 12:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 03:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 16:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 05:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 08:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2957058, was opened at 2010-02-23 01:11 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pointer to [route symbol]-[print] crashes pd Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- >Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 12:48 Message: Hi Frank, Is it really useless? If you send a gpointer through the following, it works: [rewind $1( | [pointer] That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.) ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 07:16 Message: I meant to write: useless just like a "gem_state" stripped of its *selector*. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 07:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-28 22:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 11:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 00:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 03:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2957058, was opened at 2010-02-23 07:11 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pointer to [route symbol]-[print] crashes pd Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2010-03-01 13:16 Message: I meant to write: useless just like a "gem_state" stripped of its *selector*. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 13:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 04:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 17:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 06:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 09:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2957058, was opened at 2010-02-23 07:11 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pointer to [route symbol]-[print] crashes pd Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2010-03-01 13:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 04:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 17:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 06:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 09:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2960967 ] pddplink weirdness with dynamic patching
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2960967, was opened at 2010-02-28 21:42 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pddplink weirdness with dynamic patching Initial Comment: In the attached patch, clicking the pddplink object will send the value from the vsl to the nonlocal receive. It only happens on the first click. It doesn't matter which order the vsl and pddplink are created in. Under normal, manual patching the bug doesn't occur. ---------------------------------------------------------------------- >Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-28 22:13 Message: Oh, I forgot to add: on winxp, Pd version 0.42.5-extended-20100217. And as far as I can tell the problem only occurs when linking to a pd patch that has the .pd extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…

1 0

[ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
by SourceForge.net 01 Mar '10

01 Mar '10

1 0

[ pure-data-Bugs-2960967 ] pddplink weirdness with dynamic patching
by SourceForge.net 01 Mar '10

01 Mar '10

Bugs item #2960967, was opened at 2010-02-28 21:42 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: pddplink weirdness with dynamic patching Initial Comment: In the attached patch, clicking the pddplink object will send the value from the vsl to the nonlocal receive. It only happens on the first click. It doesn't matter which order the vsl and pddplink are created in. Under normal, manual patching the bug doesn't occur. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev March 2010