Re: [PD] Finding $0 and dealing with it in messages
On Wed, 25 Nov 2009, Roman Haefeli wrote: To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? It is always at the inlet. You will not figure this out by using [print] or [route], which are both designed to hide the inconsistency under the carpet. They both contain the combination of if-statements required to mask the problem. Basically each of those classes contains a replica of much of pd_defaultlist, only in a way that doesn't look like copy+paste. [prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be). We don't know if it is a bug, but it doesn't seem logical in a common sense of the word 'logical'. «logical» thus means «something that follows from a set of rules (instead of just being a rule of its own)» instead of the other possible definitions of «something that follows the rules instead of not following them» and «something that was found using the rules instead of being found by other means»... (I didn't look at dictionary for this, I thought about what are the uses of the word that I do encounter in practice.) But because the whole set of rules hasn't been defined or agreed upon, we don't know whether anything is logical or not, because logic always starts from a set of basic rules (which can't be deduced from any other rules... at least not literally). Actually, we can know, as this is written in Pd's source code (and Dd's source code). It's just that the source has to be read... (well, if someone can find Martin Peach's internals doc, I can't find it atm, so I can't tell whether it documents this or not). _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Sun, 12/6/09, Frank Barknecht f...@footils.org wrote: From: Frank Barknecht f...@footils.org Subject: Re: [PD] Finding $0 and dealing with it in messages To: pd-list@iem.at Date: Sunday, December 6, 2009, 12:04 PM Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote: --- On Sat, 12/5/09, Frank Barknecht f...@footils.org wrote: Hey, all I said is that *I* am not the right person to do that. If that's all you had said, I doubt anyone would have replied with anything other than ok. And now I'm curious: why can't you create all the objects in that patch? If some of those objects don't create in pd-ext on win/macos/ linux, at the very least the patch should be changed so that they are removed (or replaced with ascii art). But if it's that you just prefer using pd-vanilla and don't want to download/install pd-ext, why not just say that? Some history: I was involved in early PDDP discussions (around 2005) as well, so PDDP isn't new to me. I dropped out of PDDP for various reasons after a while. Besides the endless discussion about template layout etc. another reason for my retreat was, that the help system started to require certain externals (pddp_link). I believe, a general purpose help file template should not require objects not available in all major Pd distributions. Help files should be accessible to everyone. I wasn't alone with this view, see: http://puredata.info/dev/pddp/2005-11-22-pddp_meeting.txt for example. Some other PDDP contributors didn't have a problem with that. I can accept that, but obviously I had to stop contributing at that point. Some other early participants also dropped out, some for similar reasons IIRC. While I'm surely guilty of some anti-Pd-extended puritanism, my retreat from PDDP didn't have anything to do with it. It has a different story. (I'm sorry for saying pd-extended docs in my previous mail, it should have been PDDP docs.) Thanks, that clarifies some things. So if [pddp_link] is removed, and external objects are given as comments in ascii art, would you have any other issues with pddp? (I don't see template layout as a problem because I've been revising all the reference files to conform to one standard, and I can't imagine someone objecting to using them because they don't like the colors or whatever. But the template looks pretty much like the one for [float] in pd-ext.) [pddp-link] is currently used for pdpedia links, and links to tutorials and other pddp docs. Currently [pddp-link] throws an ugly error msg in windows, although after you close the error message window the link works. I've been spot checking the links from help files to pdpedia, and of 200 help patches roughly 0% of the pdpedia links add anything to what's already in the help patch. If I remove those links then it's just a matter of converting all the More info links to comments and voila, no more [pddp-link]. At some point, it would be nice to have either [pddp-link] in all distributions, or have the ability to links within pd comments (actually that would be much more useful in my opinion). -Jonathan Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote: I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :) The PDDP docs predate pd-extended. The PDDP could easily be distributed or used by anyone. That patch is related to PDDP. But yes, Pd-extended does include the PDDP docs. What's the point of writing all this email about the topic if it doesn't actually end up in something useful? Few people read the archives... I don't understand this anti-Pd-extended puritanism. Does distributing docs or code in Pd-extended somehow taint it with evil? I think the PDDP docs are mostly really good. Most of that work was done by Dave Sabine. Why wouldn't we use it and keep it up to date? Hey, all I said is that *I* am not the right person to do that. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Sat, 12/5/09, Frank Barknecht f...@footils.org wrote: From: Frank Barknecht f...@footils.org Subject: Re: [PD] Finding $0 and dealing with it in messages To: pd-list@iem.at Date: Saturday, December 5, 2009, 1:09 PM Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote: I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :) The PDDP docs predate pd-extended. The PDDP could easily be distributed or used by anyone. That patch is related to PDDP. But yes, Pd-extended does include the PDDP docs. What's the point of writing all this email about the topic if it doesn't actually end up in something useful? Few people read the archives... I don't understand this anti-Pd-extended puritanism. Does distributing docs or code in Pd-extended somehow taint it with evil? I think the PDDP docs are mostly really good. Most of that work was done by Dave Sabine. Why wouldn't we use it and keep it up to date? Hey, all I said is that *I* am not the right person to do that. If that's all you had said, I doubt anyone would have replied with anything other than ok. And now I'm curious: why can't you create all the objects in that patch? If some of those objects don't create in pd-ext on win/macos/ linux, at the very least the patch should be changed so that they are removed (or replaced with ascii art). But if it's that you just prefer using pd-vanilla and don't want to download/install pd-ext, why not just say that? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Thu, 3 Dec 2009, Jonathan Wilkes wrote: Where does the conversion from, say, list 12 to float 12 happen in pd? Is it left to each object to convert one-element lists to a symbol/float/pointer? pd_defaultlist looks at the content of the list. if the size is 0 and there is a nondefault bangmethod, it is called. if the size is 1 and there is a matching floatmethod, symbolmethod or pointermethod, it is called. otherwise, it will be auto-unpacked and distributed to inlets, unless the object is a «nonpatchable» (that is, it's a DS). [list 12( | [$0 1 2 3 4( [list( | [$0 one two three( The message class defines a method 'list', and because of that, a 'list' selector would naturally stay 'list'. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Sat, 28 Nov 2009, Frank Barknecht wrote: I encountered this in the SICP as well which is from 1984, so probably knows its Smalltalk as well, although the index only mentions Smalltalk once in a footnote. Here's the intro to selectors: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_idx_1290 This is not the same meaning of selector. We have to be careful about that. In mainstream OO vocabulary, this would be called «reader», «getter», or «accessor» (or half of an accessor), although in your example, they define these as plain functions because there is no OO in Scheme. In Scheme, the concept of selector we are talking about does not exist. In CommonLISP, it would be called «the symbol of a generic-function» because when CommonLISP integrated the notion of OO it turned it quite inside-out. I don't know about other OOP frameworks for LISP and Scheme but you can assume that there are as many as there are for Tcl. In those systems you may find a more ordinary concept of selector. Or not. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Wed, 25 Nov 2009, Roman Haefeli wrote: However, it doesn't, which makes you have to learn every single case separately. Smartness doesn't help here, only diligence. Unfortunately, when it comes to Pd data types, smartness doesn't apply. So we're left with documenting all_(the special cases)_about_data_types(.pd). The only way to cover everything is to read all of the source code of pd. Every exception that is really an exception will have its own piece of code. Consistent cases that have their own piece of code just slow you down in reading that source code. This is why I took a lot of steps to separate difference and repetition in the pd source code, by using various means such as overloading, macros, meta-macros, abstracting out more functions, and formatting code so that it looks like a table. Eventually, stripping out all the redundantly repetitive mechanics that you can deduce from whatever else, you are left staring at the pure intent behind it all. I didn't reach that point and seldom it is reached by anyone, but the closer you get, the more transparent it becomes. If there are things two say about some the of the (special or not) cases, wouldn't it be a good idea to simply add them? Generally i think, that having such a patch isn't a bad idea, since it helps one not to have to find all the cases by experience. Black-box reverse-engineering is the best when you have no other option. Otherwise, do peek under the hood and the source code will tell you everything you want to know. It's probably shorter to learn enough C/C++ and then read pd or dd, than to figure out by yourself all imaginable ways to poke pd's components so that every detail of their behaviour comes out! _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Wed, 25 Nov 2009, Jonathan Wilkes wrote: Currently, is there any way to get the selector of a message? The [symbol]/[route] method mentioned earlier in this thread doesn't work for [list( because [route] will convert it to a bang. In the message [list( the selector is list, right? Yes, but it is cast by the pd kernel whenever the list-method is not defined, because then, they inherit the default list-method (pd_defaultlist), which turns every empty list to a bang. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Fri, 12/4/09, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Finding $0 and dealing with it in messages To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Friday, December 4, 2009, 1:51 AM On Wed, 25 Nov 2009, Jonathan Wilkes wrote: Currently, is there any way to get the selector of a message? The [symbol]/[route] method mentioned earlier in this thread doesn't work for [list( because [route] will convert it to a bang. In the message [list( the selector is list, right? Yes, but it is cast by the pd kernel whenever the list-method is not defined, because then, they inherit the default list-method (pd_defaultlist), which turns every empty list to a bang. Where does the conversion from, say, list 12 to float 12 happen in pd? Is it left to each object to convert one-element lists to a symbol/float/pointer? And getting back to the thread subject: if $0 in msg boxes was changed so that it expands to the selector of the incoming message, what would the following do: [list 12( | [$0 1 2 3 4( [list( | [$0 one two three( -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...) Add something about [list trim]. :) all_about_data_types is older than than the list object. I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :) The PDDP docs predate pd-extended. The PDDP could easily be distributed or used by anyone. That patch is related to PDDP. But yes, Pd-extended does include the PDDP docs. What's the point of writing all this email about the topic if it doesn't actually end up in something useful? Few people read the archives... I don't understand this anti-Pd-extended puritanism. Does distributing docs or code in Pd-extended somehow taint it with evil? I think the PDDP docs are mostly really good. Most of that work was done by Dave Sabine. Why wouldn't we use it and keep it up to date? .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Thu, 3 Dec 2009, Hans-Christoph Steiner wrote: I don't understand this anti-Pd-extended puritanism. You don't need to understand it, you just need to avoid it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...) Add something about [list trim]. :) all_about_data_types is older than than the list object. I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, jurgen hat gesagt: // jurgen wrote: Didn't see an article about messages... please try to point to the article. It's here: http://puredata.info/dev/PdMessages Or search for messages. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Wed, 25 Nov 2009, Frank Barknecht wrote: Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). [route] is quite disappointing. I already made [route2] which doesn't modify any message, and I'm gonna make [route3] which outputs list $1...$n on any non-last outlet in a consistent manner (and without the weird quirks that happen when you try using [route] for that purpose). To one who believes that abstractions and externals should have a Pd API that is as similar to each other, [route3] should be obvious: it would correspond more closely to class_addmethod. all_about_data_types.pd doesn't even use the word selector anywhere. The pd 0.42 source code has the word selector once. This word was introduced there in 0.39. On pd-list, there have been occasional uses of the word 'selector' quite early. There's one early mention of 'selector' (by none other than Miller) as early as 1998, but that seems to be an outlier. After that you have to skip to 2001. Some stats now. Number of occurrences of selector per year (including file selector, and someone who said selector to mean receiver, etc): num ratio 19981 3 19990 0 20002 3 2001 2310 2002 28 5 2003 51 7 2004 70 8 2005 78 8 2006 45539 2007 19515 2008 74 8 2009 24433 (where the ratio is 1000 times the number of occurrences divided by the total number of emails) AFAIK, selector is vocabulary that comes from Smalltalk and its derivatives, or any general OOP theory book that considers Smalltalk to be a reference. I encountered this in the SICP as well which is from 1984, so probably knows its Smalltalk as well, although the index only mentions Smalltalk once in a footnote. Here's the intro to selectors: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_idx_1290 Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 25, 2009, at 1:50 AM, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: I wonder, what makes one any smarter. It doesn't make you any smarter, when knowing about all the underlying mechanisms and special cases of Pd, it only makes you know more. However, it *would* you make smarter, if you would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that you would naturally assume, that [route] would strip off any selector. However, it doesn't, which makes you have to learn every single case separately. Of course you have to learn every single object behaviour separately! There's no way around it. [prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be). But to be able to understand what makes them different, you have to understand at least a little bit about the anatomy of Pd's messages and ideally even how messages with different selectors call different methods of a Pd object. Explaing this makes you smarter. And then being smarter can help with the tedious task of memorizing object behaviours (or knowing when to look them up). Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...) Add something about [list trim]. :) all_about_data_types is older than than the list object. .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Sun, 22 Nov 2009, Jonathan Wilkes wrote: It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? because it doesn't. Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Other than this, are there instances where [symbol] doesn't work correctly with lists? If you send list stuff or list zzz to [symbol] you don't get list, you get stuff or zzz. In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element. What's the correct selector of a 1-element list? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Wed, 25 Nov 2009, Frank Barknecht wrote: Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). [route] is quite disappointing. I already made [route2] which doesn't modify any message, and I'm gonna make [route3] which outputs list $1...$n on any non-last outlet in a consistent manner (and without the weird quirks that happen when you try using [route] for that purpose). To one who believes that abstractions and externals should have a Pd API that is as similar to each other, [route3] should be obvious: it would correspond more closely to class_addmethod. all_about_data_types.pd doesn't even use the word selector anywhere. The pd 0.42 source code has the word selector once. This word was introduced there in 0.39. On pd-list, there have been occasional uses of the word 'selector' quite early. There's one early mention of 'selector' (by none other than Miller) as early as 1998, but that seems to be an outlier. After that you have to skip to 2001. Some stats now. Number of occurrences of selector per year (including file selector, and someone who said selector to mean receiver, etc): num ratio 19981 3 19990 0 20002 3 2001 2310 2002 28 5 2003 51 7 2004 70 8 2005 78 8 2006 45539 2007 19515 2008 74 8 2009 24433 (where the ratio is 1000 times the number of occurrences divided by the total number of emails) AFAIK, selector is vocabulary that comes from Smalltalk and its derivatives, or any general OOP theory book that considers Smalltalk to be a reference. This word is quite absent from the C++ vocabulary, for example. Even though I started using C++ in 1992, it took me until 1997 to read the word selector somewhere, probably a text on Objective-C. Starting in 2000 or so, though, I was seeing selector everywhere as was the norm for the Ruby language. I used it routinely on pd-list. Instead it talks about casting but doesn't explain what that means (in the patch it means adding a symbol-selector to a meta-message). It has several vague sentences in it like: Many objects cast the data they receive when they output it or Some objects do not cast the data. This doesn't make me any smarter. trigger-help.pd is even funnier. It talks about conversions in which nearly every conversion results in all values of one type (0, 1, 2, 3, ...) end up being converted to the same value of the other type (symbol float), thus destroying the entire contents of the message (except the existence thereof). All in all, I don't think, the patch tells you All About Data Types. But maybe it just has a misleading name. It's a marketing thing. It's like when you enter a Steve's Music Store and they tell you if we don't have it, you don't need it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Fri, 11/27/09, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Finding $0 and dealing with it in messages To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduzie...@yahoo.de, Phil Stone pkst...@ucdavis.edu, pd-list@iem.at Date: Friday, November 27, 2009, 6:23 PM On Sun, 22 Nov 2009, Jonathan Wilkes wrote: It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? because it doesn't. Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Other than this, are there instances where [symbol] doesn't work correctly with lists? If you send list stuff or list zzz to [symbol] you don't get list, you get stuff or zzz. But how does having [route bang symbol list] instead of just [route bang symbol] help you here? [route] will call list stuff a symbol, not a list. In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element. What's the correct selector of a 1-element list? Hm, I'm so used to seeing one element lists automatically converted to floats or bangs (or pointers) by just about every object I use that I would assume [symbol] ought to say symbol float for [list 12( and symbol symbol for [list foo( . But then if the selector is supposed to be list, what should the selector be for [list( ? -Jonathan _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Fri, 27 Nov 2009, Mathieu Bouchard wrote: Some stats now. Number of occurrences of selector per year (including file selector, and someone who said selector to mean receiver, etc): Btw those stats were only for pd-list and not pd-dev nor any other mailing-list. I only realised later that I hadn't said which mailing-list(s) I was talking about. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(-[symbol] = 'symbol list', whereas [list 45(-[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this. Personally I consider this a kind of inconsistency bug. To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in. Or said in another way: You can select what behaviour you want an object to show by prefixing your messages with a certain selector - this is where the word selector comes from. For example a [delay] object has these behaviour methods on the first inlet: a) send a bang after the time of its stored delay time b) set the stored delay time to x and send a bang after that time c) cancel any scheduled bangs You select behaviour a) by sending a bang message, you select b) by messages with selector float and c) with selector stop. On the C-code side, this is handled with messages like delay_bang(), delay_float(), delay_stop() that get called according to the selector. If you write an abstraction, you can mimick the same things with [route float bang stop]. You've all done this already. What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave strange or inconsistent. But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not. Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations. I hope you're a bit smarter now, but probably you still cannot make predictions. :) Thinking of the the [symbol] vs. [symbol\ and the [route] example (you mention below), one is just left with trying out the different cases and remember them. Or thinking about making a bug report/feature wish. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hi Frank Thanks a lot for giving me such detailed insight. Am 26.11.09 09:24 schrieb Frank Barknecht unter f...@footils.org: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(-[symbol] = 'symbol list', whereas [list 45(-[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this. Personally I consider this a kind of inconsistency bug. Ok. To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in. ... What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave strange or inconsistent. Ok, i see. If i understand right, this would also make it possible to deliberately create a message 'list 23' at the outlet, which is probably converted to a 'float 23' by the next object's outlet (_if_ this next object's inlet knows what to do with the selector 'list'). Unfortunately, knowing this doesn't make me understand what happens here - for instance: [list 23( | [print] which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages? Is there a way to know what goes through a connection wire? Also interesting cases to consider: [list velo( - 'symbol velo' [float 12 34( - '12' But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not. I see. Let me pick an example, which to me is not quite clear, which of the involved object classes should be considered buggy: [foo 56( | [route foo] | [*~ ] This raises an error: inlet: expected 'signal' but got 'list' Is it [route]'s fault not to spit out a message with 'float' selector, since obviously the message contains only a single element? Or is [*~ ] supposed to accept single-element-lists as well and raise only an error, when the single-element-list contains a symbol, but not a float? Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations. I hope you're a bit smarter now, but probably you still cannot make predictions. :) Hmm.. i guess, you're right... roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo Roman, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Am 26.11.09 09:24 schrieb Frank Barknecht unter f...@footils.org: To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in. ... What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave strange or inconsistent. Ok, i see. If i understand right, this would also make it possible to deliberately create a message 'list 23' at the outlet, which is probably converted to a 'float 23' by the next object's outlet (_if_ this next object's inlet knows what to do with the selector 'list'). Ok, here you mention a different thing, which is the automatic conversion of special messages, i.e. list 23 is just a float 23 which is the same as 23, or list being the same as bang. I must admit, that I don't really know where and how this is happening in Pd. As you wrote, sometimes this conversion isn't working. A good example is the right (or non-leftmost) inlet of the signal math objects: If they are created so that normally both signals and floats can be sent into them, they only like real floats, that is messages with selector float or numbers. They won't accept messages coming out ot a [t a] either: [0\ | [t a a] | | [*~ ] This gives error: inlet: expected 'signal' but got 'list' on the right inlet. But if you disconnect the right inlet, the same anything-float is accepted on the first inlet. Maybe IOhannes can explain the background? IIRC he wrote a patch that fixes this so that [t a] works for non-leftmost signal inlets as well. Unfortunately, knowing this doesn't make me understand what happens here - for instance: [list 23( | [print] which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages? Apart from the fact that [print] is a very bad helper in this case, I don't know where and how list 23 is made to be 23, see above. :( Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 26.11.09 12:13 schrieb Frank Barknecht unter f...@footils.org: Unfortunately, knowing this doesn't make me understand what happens here - for instance: [list 23( | [print] which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages? Apart from the fact that [print] is a very bad helper in this case, I don't know where and how list 23 is made to be 23, see above. :( I found another interesting example: [float velo( Clicking on this message box raises the following error: error: Bad arguments for message 'float' to object 'messresponder' Obviously, the message box already does some parsing and tries to generate a 'coherent' pd message, which fails in this case. btw: funny milleresque name: 'messresponder' :-) roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 25, 2009, at 12:48 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Regarding all_about_data_types.pd: Personally I wouldn't trust this patch. Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;) To me the fundamental flaw of the data types patch is that it tries to infer information about Pd's data types from the behaviour of selected objects, but doesn't explain the underlying mechanisms. Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol- selectors). IMO an explanation of the mechanisms is imporant to understand, where or why objects behave strange. all_about_data_types.pd doesn't even use the word selector anywhere. Instead it talks about casting but doesn't explain what that means (in the patch it means adding a symbol-selector to a meta-message). It has several vague sentences in it like: Many objects cast the data they receive when they output it or Some objects do not cast the data. This doesn't make me any smarter. All in all, I don't think, the patch tells you All About Data Types. But maybe it just has a misleading name. It should be all about data types, but it doesn't doesn't cover everything. Please add to it, its in SVN in doc/pddp. Those patches are there to be improved! .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Regarding all_about_data_types.pd: Personally I wouldn't trust this patch. Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;) To me the fundamental flaw of the data types patch is that it tries to infer information about Pd's data types from the behaviour of selected objects, but doesn't explain the underlying mechanisms. Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). IMO an explanation of the mechanisms is imporant to understand, where or why objects behave strange. all_about_data_types.pd doesn't even use the word selector anywhere. Instead it talks about casting but doesn't explain what that means (in the patch it means adding a symbol-selector to a meta-message). It has several vague sentences in it like: Many objects cast the data they receive when they output it or Some objects do not cast the data. This doesn't make me any smarter. All in all, I don't think, the patch tells you All About Data Types. But maybe it just has a misleading name. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 25.11.09 09:48 schrieb Frank Barknecht unter f...@footils.org: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Regarding all_about_data_types.pd: Personally I wouldn't trust this patch. Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;) To me the fundamental flaw of the data types patch is that it tries to infer information about Pd's data types from the behaviour of selected objects, but doesn't explain the underlying mechanisms. Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). IMO an explanation of the mechanisms is imporant to understand, where or why objects behave strange. all_about_data_types.pd doesn't even use the word selector anywhere. Instead it talks about casting but doesn't explain what that means (in the patch it means adding a symbol-selector to a meta-message). It has several vague sentences in it like: Many objects cast the data they receive when they output it or Some objects do not cast the data. This doesn't make me any smarter. I wonder, what makes one any smarter. It doesn't make you any smarter, when knowing about all the underlying mechanisms and special cases of Pd, it only makes you know more. However, it *would* you make smarter, if you would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that you would naturally assume, that [route] would strip off any selector. However, it doesn't, which makes you have to learn every single case separately. Smartness doesn't help here, only diligence. Unfortunately, when it comes to Pd data types, smartness doesn't apply. So we're left with documenting all_(the special cases)_about_data_types(.pd). If there are things two say about some the of the (special or not) cases, wouldn't it be a good idea to simply add them? Generally i think, that having such a patch isn't a bad idea, since it helps one not to have to find all the cases by experience. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: I wonder, what makes one any smarter. It doesn't make you any smarter, when knowing about all the underlying mechanisms and special cases of Pd, it only makes you know more. However, it *would* you make smarter, if you would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that you would naturally assume, that [route] would strip off any selector. However, it doesn't, which makes you have to learn every single case separately. Of course you have to learn every single object behaviour separately! There's no way around it. [prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be). But to be able to understand what makes them different, you have to understand at least a little bit about the anatomy of Pd's messages and ideally even how messages with different selectors call different methods of a Pd object. Explaing this makes you smarter. And then being smarter can help with the tedious task of memorizing object behaviours (or knowing when to look them up). Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Currently, is there any way to get the selector of a message? The [symbol]/[route] method mentioned earlier in this thread doesn't work for [list( because [route] will convert it to a bang. In the message [list( the selector is list, right? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 25.11.09 10:50 schrieb Frank Barknecht unter f...@footils.org: Of course you have to learn every single object behaviour separately! There's no way around it. Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(-[symbol] = 'symbol list', whereas [list 45(-[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this. To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations. Thinking of the the [symbol] vs. [symbol\ and the [route] example (you mention below), one is just left with trying out the different cases and remember them. [prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be). We don't know if it is a bug, but it doesn't seem logical in a common sense of the word 'logical'. ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Finding $0 and dealing with it in messages To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduzie...@yahoo.de, Phil Stone pkst...@ucdavis.edu, pd-list@iem.at Date: Monday, November 16, 2009, 8:59 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote: --- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? because it doesn't. Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Other than this, are there instances where [symbol] doesn't work correctly with lists? As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content. You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list]. In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element. -Jonathan _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote: Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Here (Pd version 0.42.4) [symbol], the object box, outputs symbol list. However [symbol\, the graphical atom, shows float. Probably some artifact of automatic converson going on behind our backs. A third possibility would be to bail out with an error No message for list/float. I would prefer this behaviour. It's consistent with the behaviour of [float] receiving a list abc message. Regarding all_about_data_types.pd: Personally I wouldn't trust this patch. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 24, 2009, at 10:01 AM, Frank Barknecht wrote: Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote: Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Here (Pd version 0.42.4) [symbol], the object box, outputs symbol list. However [symbol\, the graphical atom, shows float. Probably some artifact of automatic converson going on behind our backs. A third possibility would be to bail out with an error No message for list/float. I would prefer this behaviour. It's consistent with the behaviour of [float] receiving a list abc message. Regarding all_about_data_types.pd: Personally I wouldn't trust this patch. Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;) .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 22, 2009, at 1:34 PM, Jonathan Wilkes wrote: --- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Finding $0 and dealing with it in messages To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduzie...@yahoo.de, Phil Stone pkst...@ucdavis.edu , pd-list@iem.at Date: Monday, November 16, 2009, 8:59 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote: --- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? because it doesn't. Well, if you send the message list 7 to [symbol] it will output symbol list, when, according to all_about_data_types.pd, it ought to output symbol float. Other than this, are there instances where [symbol] doesn't work correctly with lists? I think there are. Anytime I find something like that, I make an example patch and add it to SVN. I encourage others to add to this collection since they are quite helpful in thinking about how we can fix things to make them work easier: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/doc/additional/messageoddness .hc As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content. You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list]. In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element. -Jonathan _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Mon, 16 Nov 2009, IOhannes m zmölnig wrote: Mathieu Bouchard wrote: wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case. you can get the unparsed arguments during runtime (though after creation time) just fine. this is what every save-routine does (unless somebody decides to really save 1053 instead of $0) Yes, I thought of that, but just try it, you'll see: it'll complain about missing $1, $2, etc. as you try making such messageboxes, because the $-substitution does happen anyway even if you ignore it. Even though it technically would work, no-one would want to put up with those error messages. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Fri, 11/13/09, Roman Haefeli reduzie...@yahoo.de wrote: From: Roman Haefeli reduzie...@yahoo.de Subject: Re: [PD] Finding $0 and dealing with it in messages To: Roman Haefeli reduzie...@yahoo.de, Phil Stone pkst...@ucdavis.edu, Mathieu Bouchard ma...@artengine.ca Cc: pd-list@iem.at Date: Friday, November 13, 2009, 11:21 AM This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already. The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? It would certainly end the discussions about the special (somehow undefined) state it has now. You can already use [symbol] to get the selector of an incoming message. I can't think of many patches where I would utilize $0 to get the selector, but I can think of lots of abstractions where treating $0 in msg boxes the same as in object boxes would have been very convenient. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Mon, 16 Nov 2009, Jonathan Wilkes wrote: You can already use [symbol] to get the selector of an incoming message. It doesn't work for those selectors: bang symbol list To handle these cases, you need to also have [route bang symbol list], three messageboxes that say «symbol bang» «symbol symbol» and «symbol list», and three [b] to protect those messageboxes from whatever comes out of [route]. then the else-case of [route] goes to [symbol]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
--- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Finding $0 and dealing with it in messages To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduzie...@yahoo.de, Phil Stone pkst...@ucdavis.edu, pd-list@iem.at Date: Monday, November 16, 2009, 8:23 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote: You can already use [symbol] to get the selector of an incoming message. It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? To handle these cases, you need to also have [route bang symbol list], three messageboxes that say «symbol bang» «symbol symbol» and «symbol list», and three [b] to protect those messageboxes from whatever comes out of [route]. then the else-case of [route] goes to [symbol]. As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content. -Jonathan _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Mon, 16 Nov 2009, Jonathan Wilkes wrote: --- On Mon, 11/16/09, Mathieu Bouchard ma...@artengine.ca wrote: It doesn't work for those selectors: bang symbol list Why do you say it doesn't work for list? because it doesn't. As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content. You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
2009/11/14 IOhannes m zmölnig zmoel...@iem.at: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: http://sourceforge.net/tracker/?func=detailaid=1543850group_id=55736atid=478072 i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what bl...@-blu really means. as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) I think this never got included because it didn't play nice with the new dollar arg expansion code. i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines. Haha, I have no idea if I ever publicized this or not, but I believe I got this applying to 0.42+ back in April... Haven't tested this since then but if it applies I'll add it to the tracker. Best Luke but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detailaid=1405137group_id=55736atid=478072), so i guess i might even have build on that code. So this patch at this point serves as a starting point for developing this. it implements about 66% of your suggestion. As for what bl...@-blu means, it doesn't matter as long as $$, $@, and $# are clearly defined. now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do. in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be there) now i did implement this and it turned out that i was wondering on what bl...@-blu should be explanded to. my experience showed me that it does matter. i can think of 2 expansions and both make sense and both don't. iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list. By bash rules, that would give you bla-my list of words-blu. this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard bla-my list of words-blu to be a list of 5 arguments and bash-code that sees it as a single argument. this is exactly the question i asked; probably this was not so clear) gfmasd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr/El8ACgkQkX2Xpv6ydvRZdwCgsbV3Eh85Nyw8cwqgFdeorNnx UkMAoKTGZ0NOEzu/nKyZ+gJ//8vnqx7M =S6J0 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list dollargcargv-pd-0.42-4.patch Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hans-Christoph Steiner wrote: this is exactly the question i asked; probably this was not so clear) I think omitting something here because you don't think its useful is not a good idea. Instead, I think $@ should always expand unless that causes problems somewhere. That's the spirit of flexibility that makes Pd good. i think you totally misunderstand me. $@ is implemented, this is not the problem. the question i was asking is, what this will produce: [1 2 3( | [mymsg bl...@-blu( i see 2 possibilities, and both seem weird. they seem weirder when comparing them to single $@, like in [mymsg $@ $@( fmgasdr IOhannes it really seems to me like this is something i have spent little thought on and you have spent no thought on and now we try to discuss it. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 14, 2009, at 3:26 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: http://sourceforge.net/tracker/?func=detailaid=1543850group_id=55736atid=478072 i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what bl...@-blu really means. as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) I think this never got included because it didn't play nice with the new dollar arg expansion code. i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines. but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detailaid=1405137group_id=55736atid=478072 ), so i guess i might even have build on that code. So this patch at this point serves as a starting point for developing this. it implements about 66% of your suggestion. As for what bl...@-blu means, it doesn't matter as long as $$, $@, and $# are clearly defined. now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do. in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be there) now i did implement this and it turned out that i was wondering on what bl...@-blu should be explanded to. my experience showed me that it does matter. i can think of 2 expansions and both make sense and both don't. iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list. By bash rules, that would give you bla-my list of words-blu. this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard bla-my list of words-blu to be a list of 5 arguments and bash-code that sees it as a single argument. this is exactly the question i asked; probably this was not so clear) I think omitting something here because you don't think its useful is not a good idea. Instead, I think $@ should always expand unless that causes problems somewhere. That's the spirit of flexibility that makes Pd good. .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Thanks. I would like to work out the bugs if anyone could find this useful... I am too trusting with [print] so there were some things with floats that were actually phantom symbols (this kind of thing is really useful for learning lessons about the weird datatype pitfalls in Pd). Here's an update. I really wish there were some kind of [s2l] in vanilla. One COULD use something like # 2 instead of #2 and make it vanilla, but that seems kind of clunky. MB On Sat, Nov 14, 2009 at 6:18 PM, Hans-Christoph Steiner h...@at.or.at wrote: Yeah, its great that you made this. I think people are too used to thinking that some things are set in stone, like message boxes and arguments. But you really can make your own. And you did it in Pd event, bonus points there :-D .hc On Nov 14, 2009, at 5:45 PM, Matt Barber wrote: There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object. On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrof...@gmail.com wrote: Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 kill your television #N canvas 583 22 531 551 10; #N canvas 270 121 532 403 \$0-getargs 0; #X obj 37 40 inlet; #N canvas 31 427 359 254 \$0-construct_Iohannes_arg_test 0; #X obj 71 19 inlet; #X msg 218 155 vis 1; #X obj 71 172 outlet; #N canvas 497 46 421 150 \$0-connect 0; #X obj 25 25 inlet; #X obj 25 109 outlet; #X msg 25 47 connect 0 0 1 0 \, connect 1 0 8 0 \, connect 1 1 2 0 \, connect 2 0 3 0 \, connect 3 0 4 1 \, connect 8 0 4 0 \, connect 4 0 7 0 \, connect 4 1 5 0 \, connect 5 0 9 0 \, connect 9 0 6 0; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 71 114 pd \$0-connect; #X obj 90 90 s \$0-construct_out; #X obj 89 139 r \$0-construct_out; #X obj 71 41 t b b f; #N canvas 557 172 523 728 \$0-step_1 0; #X obj 122 135 list trim; #X obj 79 380 list trim; #X obj 93 309 list trim; #X obj 108 206 f; #X obj 231 20 inlet; #X obj 205 405 outlet; #X msg 108 227 obj 10 40 t b b \, msg 200 57 \$1 \, obj 200 87 makefilename $%d- \, obj 10 104 select s \, obj 55 134 b; #X obj 50 20 inlet; #X obj 93 332 s \$0-step_1_out; #X obj 79 403 s \$0-step_1_out; #X obj 122 157 s \$0-step_1_out; #X obj 108 262 s \$0-step_1_out; #X obj 137 89 s \$0-step_1_out; #X obj 205 381 r \$0-step_1_out; #X obj 122 114 list append obj 10 10 r \$0-getcreationargs_in; #X obj 79 357 list append obj 10 224 s \$0-getcreationargs_noarg; #X obj 93 288 list append obj 55 194 s \$0-getcreationargs_thisarg ; #X obj 64 451 f; #X obj 64 473 makefilename $%d-; #X obj 64 515 list trim; #X obj 64 535 s \$0-step_1_out; #X obj 64 495 list prepend obj 10 70 symbol; #X obj 50 581 f; #X obj 50 606 makefilename $%d; #X obj 50 628 list prepend obj 55 164 list append; #X obj 51 648 list trim; #X obj 51 669 s \$0-step_1_out; #X obj 50 43 t b b b b b b b; #X msg 137 67 clear; #X obj 231 43 s \$0-arg-float; #X obj 65 560 r \$0-arg-float; #X obj 79 428 r \$0-arg-float; #X obj 123 183 r \$0-arg-float; #X connect 0 0 10 0; #X connect 1 0 9 0; #X connect 2 0 8 0; #X connect 3 0 6 0; #X connect 4 0 29 0; #X connect 6 0 11 0; #X connect 7 0 27 0; #X connect 13 0 5 0; #X connect 14 0 0 0; #X connect 15 0 1 0; #X connect 16 0 2 0; #X connect 17 0 18 0; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 21 0 19 0; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 27 0 22 0; #X connect 27 1 17 0; #X connect 27 2 15 0; #X connect 27 3 16 0; #X connect 27 4 3 0; #X connect 27 5 14 0; #X connect 27 6 28 0; #X connect 28 0 12 0; #X connect 30 0 22 1; #X connect 31 0 17 1; #X connect 32 0 3 1; #X restore 90 68 pd \$0-step_1; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 3 0 2 0; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 6 1 7 0; #X connect 6 2 7 1; #X connect 7 0 4 0; #X restore 76 164 pd
Re: [PD] Finding $0 and dealing with it in messages
Yeah, its great that you made this. I think people are too used to thinking that some things are set in stone, like message boxes and arguments. But you really can make your own. And you did it in Pd event, bonus points there :-D .hc On Nov 14, 2009, at 5:45 PM, Matt Barber wrote: There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object. On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrof...@gmail.com wrote: Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object. On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrof...@gmail.com wrote: Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: http://sourceforge.net/tracker/?func=detailaid=1543850group_id=55736atid=478072 i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what bl...@-blu really means. as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) I think this never got included because it didn't play nice with the new dollar arg expansion code. i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines. but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detailaid=1405137group_id=55736atid=478072), so i guess i might even have build on that code. So this patch at this point serves as a starting point for developing this. it implements about 66% of your suggestion. As for what bl...@-blu means, it doesn't matter as long as $$, $@, and $# are clearly defined. now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do. in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be there) now i did implement this and it turned out that i was wondering on what bl...@-blu should be explanded to. my experience showed me that it does matter. i can think of 2 expansions and both make sense and both don't. iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list. By bash rules, that would give you bla-my list of words-blu. this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard bla-my list of words-blu to be a list of 5 arguments and bash-code that sees it as a single argument. this is exactly the question i asked; probably this was not so clear) gfmasd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr/El8ACgkQkX2Xpv6ydvRZdwCgsbV3Eh85Nyw8cwqgFdeorNnx UkMAoKTGZ0NOEzu/nKyZ+gJ//8vnqx7M =S6J0 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 14, 2009, at 12:17 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IOhannes m zmölnig wrote: Hans-Christoph Steiner wrote: messages: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message objects: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message Now, all we need is someone to code it :) I am certainly willing to try i thought i had committed such a patch about 3 years ago to the sf patch tracker. http://sourceforge.net/tracker/?func=detailaid=1543850group_id=55736atid=478072 i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what bl...@-blu really means. as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) I think this never got included because it didn't play nice with the new dollar arg expansion code. So this patch at this point serves as a starting point for developing this. As for what bl...@-blu means, it doesn't matter as long as $$, $@, and $# are clearly defined. By bash rules, that would give you bla- my list of words-blu. .hc mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr+5jYACgkQkX2Xpv6ydvQYYQCgjd2KBA8CqWC5fUcGLUdOMn2J +AQAoPN6GqUvAu6NmWKgOx5PU0cWdx59 =F53w -END PGP SIGNATURE- Information wants to be free.-Stewart Brand ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IOhannes m zmölnig wrote: Hans-Christoph Steiner wrote: messages: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message objects: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message Now, all we need is someone to code it :) I am certainly willing to try i thought i had committed such a patch about 3 years ago to the sf patch tracker. http://sourceforge.net/tracker/?func=detailaid=1543850group_id=55736atid=478072 i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what bl...@-blu really means. as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr+5jYACgkQkX2Xpv6ydvQYYQCgjd2KBA8CqWC5fUcGLUdOMn2J +AQAoPN6GqUvAu6NmWKgOx5PU0cWdx59 =F53w -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: Here's my summary of the proposals mentioned here: I agree that $0 is totally arbitrary and is not inherintly bound to object boxes. I think this strongest proposed fix is to introduce $$ which works in both object and message boxes, its a nice parallel to Bourne Shell syntax. On that note, I think this should also come with Bourne Shell's $# for count of argument and $@ for a list of all arguments. I think $$, $#, and $@ should work in both message and object boxes. So: messages: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message objects: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message Now, all we need is someone to code it :) I am certainly willing to try i thought i had committed such a patch about 3 years ago to the sf patch tracker. mfasr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr+48oACgkQkX2Xpv6ydvR39wCfUmgeZNT2vphUCtdiqFqy7ElT BGgAnjlTXqVaJZjd4mxsvEY9L7W8Zy7p =t2HN -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Nov 14, 2009, at 11:35 AM, Mathieu Bouchard wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. Yeah, for clarification, there is nothing inherently unique in the implementation. Someone could make their own message box. I'd like to see that happen. .hc Making boring techno music is really easy with modern tools, he says, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 #N canvas 583 22 531 551 10; #N canvas 270 121 532 403 \$0-getargs 0; #X obj 37 40 inlet; #N canvas 31 427 359 254 \$0-construct_Iohannes_arg_test 0; #X obj 71 19 inlet; #X msg 218 155 vis 1; #X obj 71 172 outlet; #N canvas 497 46 421 150 \$0-connect 0; #X obj 25 25 inlet; #X obj 25 109 outlet; #X msg 25 47 connect 0 0 1 0 \, connect 1 0 8 0 \, connect 1 1 2 0 \, connect 2 0 3 0 \, connect 3 0 4 1 \, connect 8 0 4 0 \, connect 4 0 7 0 \, connect 4 1 5 0 \, connect 5 0 9 0 \, connect 9 0 6 0; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 71 114 pd \$0-connect; #X obj 90 90 s \$0-construct_out; #X obj 89 139 r \$0-construct_out; #X obj 71 41 t b b f; #N canvas 557 172 523 728 \$0-step_1 0; #X obj 122 135 list trim; #X obj 79 380 list trim; #X obj 93 309 list trim; #X obj 108 206 f; #X obj 231 20 inlet; #X obj 205 405 outlet; #X msg 108 227 obj 10 40 t b b \, msg 200 57 \$1 \, obj 200 87 makefilename $%d- \, obj 10 104 select s \, obj 55 134 b; #X obj 50 20 inlet; #X obj 93 332 s \$0-step_1_out; #X obj 79 403 s \$0-step_1_out; #X obj 122 157 s \$0-step_1_out; #X obj 108 262 s \$0-step_1_out; #X obj 137 89 s \$0-step_1_out; #X obj 205 381 r \$0-step_1_out; #X obj 122 114 list append obj 10 10 r \$0-getcreationargs_in; #X obj 79 357 list append obj 10 224 s \$0-getcreationargs_noarg; #X obj 93 288 list append obj 55 194 s \$0-getcreationargs_thisarg ; #X obj 64 451 f; #X obj 64 473 makefilename $%d-; #X obj 64 515 list trim; #X obj 64 535 s \$0-step_1_out; #X obj 64 495 list prepend obj 10 70 symbol; #X obj 50 581 f; #X obj 50 606 makefilename $%d; #X obj 50 628 list prepend obj 55 164 list append; #X obj 51 648 list trim; #X obj 51 669 s \$0-step_1_out; #X obj 50 43 t b b b b b b b; #X msg 137 67 clear; #X obj 231 43 s \$0-arg-float; #X obj 65 560 r \$0-arg-float; #X obj 79 428 r \$0-arg-float; #X obj 123 183 r \$0-arg-float; #X connect 0 0 10 0; #X connect 1 0 9 0; #X connect 2 0 8 0; #X connect 3 0 6 0; #X connect 4 0 29 0; #X connect 6 0 11 0; #X connect 7 0 27 0; #X connect 13 0 5 0; #X connect 14 0 0 0; #X connect 15 0 1 0; #X connect 16 0 2 0; #X connect 17 0 18 0; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 21 0 19 0; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 27 0 22 0; #X connect 27 1 17 0; #X connect 27 2 15 0; #X connect 27 3 16 0; #X connect 27 4 3 0; #X connect 27 5 14 0; #X connect 27 6 28 0; #X connect 28 0 12 0; #X connect 30 0 22 1; #X connect 31 0 17 1; #X connect 32 0 3 1; #X restore 90 68 pd \$0-step_1; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 3 0 2 0; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 6 1 7 0; #X connect 6 2 7 1; #X connect 7 0 4 0; #X restore 76 164 pd \$0-construct_Iohannes_arg_test; #X obj 135 315 r \$0-getcreationargs_thisarg; #X obj 323 315 r \$0-getcreationargs_noarg; #X obj 56 211 s \$0-getcreationargs_in; #X obj 37 89 max 0; #X obj 37 64 route float; #X obj 37 110 int; #X obj 37 315 spigot 1; #X obj 82 262 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 37 338 s pd-\$1; #X obj 135 338 outlet; #X obj 323 338 outlet; #X text 116 261 -- toggle on to see the result of the dynamic patching ; #X obj 82 290 == 0; #X text 147 55 Inlet: the argument number.; #X obj 37 134 t b b f; #X msg 37 237 clear \, editmode 0; #N canvas 0 22 450 300 \$0-helper 0; #X obj 10 10 r 1064-getcreationargs_in; #X obj 10 40 t b b; #X msg 200 57 17; #X obj 200 87 makefilename $%d-; #X obj 10 104 select s; #X obj 55 134 b; #X obj 55 194 s 1064-getcreationargs_thisarg; #X obj 10 224 s 1064-getcreationargs_noarg; #X obj 10 70 symbol \$17-; #X obj 55 164 list append \$17; #X connect 0 0 1 0; #X connect 1 0 8 0; #X connect 1 1 2 0; #X connect 2 0 3 0; #X connect 3 0 4 1; #X connect 4 0 7 0; #X connect 4 1 5 0; #X connect 5 0 9 0; #X connect 8 0 4 0; #X connect 9 0 6 0; #X restore 392 164 pd \$0-helper; #X obj 76 186 s pd-\$0-helper; #X text 147
Re: [PD] Finding $0 and dealing with it in messages
Geez, I got like 15 digests at once and kinda I lost it, I know nothing of $$, $@ but I like this expansion idea for what I got fom it. Anyway, let me get this quote here and... IOhannes: as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) come back to my former inquiry, I am sorry if you told me this already and i lost it. But then; - Do you think $0 could easily be available in messages? How come? - Is it a general consensuous that it aint't worth bothering about? Why? Cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
IOhannes m zmölnig wrote: Hans-Christoph Steiner wrote: iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list. i guess this is the main source of misunderstanding. with dollsym i really mean what Pd internally understands as A_DOLLSYM, that is a symbol constructed with a dollar+number and something else, e.g. $1_bla or /foo/$2/bla but not an A_DOLLARG, which is a a dollar+number, e.g. $1. A_DOLLSYM will always expand to symbol, whereas A_DOLLARG will expand to an atom of the type of the referenced listelement. e.g. [10 20 30( | [$2( will give you the float 20. whereas [10 20 30( | [/$1( will give you the symbol '/20' now in the current implementation we have: [10 20 30( | [$@ $@( which gives you a 6 element list 10 20 30 10 20 30. but what is this supposed to give me? [10 20 30( | [$@/$@( either its a 5 element list 10 20 30/10 20 30 (with 4 floats and a symbol inbetween) or it is a single symbol '10 20 30/10 20 30'. i don't like the former very much, because it generates both symbols and other atoms in a hard to predict matter, and is kind of out of sync with pd's ordinary behaviour. i don't like the latter very much, because it suddenly allows easy creation of symbols with spaces, and i think Pd is not really ready for that. symbols with spaces is not something one cannot live without. (we all have learned to do this by now). even if we can live with a symbol-with-spaces approach, this wouldn't allow for just symbol with spaces (the thing [l2s] does), opening another can of worms. therefore my conclusion was that it was better *for now* to only support A_DOLLARG $@ but not in A_DOLLSYM. i don't even know whether i have implemented this conclusion or whether i just went with one of the 2 options. read the code. fgmadsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Alexandre Porres wrote: IOhannes: as for $$ being available in messages: i don't think this can easily be done the way things are right know. and really, i don't think it is that important :-) come back to my former inquiry, I am sorry if you told me this already and i lost it. But then; - Do you think $0 could easily be available in messages? How come? i say i don't think this can easily be done. this i mean, not the opposite. i come to the conclusion because i read the code (that was years ago, i might be mistaken so please forgive me if its plain wrong): you need a context to evaluate $0 correctly. a message does not have this canvas-context. (this might really be total nonsense; but this is what i seem to remember) i _think_ that it makes sense to see it as such: objects are citizens of a canvas, messages are something entirely different. they are information passed between the citizens. they are not 2nd class citizens, they belong to another realm! once you got that, everything is simple :-) - Is it a general consensuous that it aint't worth bothering about? Why? i don't think its general consensus. it's what _i_ think. i don't need $0 in message-boxes so often. i need to construct messages containing $0 for dynamic patching every now and then. but usually the messages i construct are more complex anyhow, so i don't use message-boxes to construct the values but [pack]. e.g. [pack 0 $0] | [obj 100 $1 fluffy $2( | [s pd-$0-patch] in this case, the penalty of not being able to write $0 in message boxes is minimal. keep in mind that this example is somewhat simplistic as well. usually the messages created contain a lot more arguments (4) , making the penalty even smaller. fgmadsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Sun, 15 Nov 2009, IOhannes m zmoelnig wrote: with dollsym i really mean what Pd internally understands as A_DOLLSYM, that is a symbol constructed with a dollar+number and something else, e.g. $1_bla or /foo/$2/bla but not an A_DOLLARG, which is a a dollar+number, e.g. $1. It's really a Dollar and not a Doll Arg. Though you could ask why is it a Doll Sym and not a Dollar Symbol... And why Dollar when the $ character is $ because it looks like the S in Substitute... Anyway, in m_pd.h, A_DOLLAR exists and A_DOLLARG doesn't. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Sat, 14 Nov 2009, Hans-Christoph Steiner wrote: On Nov 14, 2009, at 11:35 AM, Mathieu Bouchard wrote: User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. Yeah, for clarification, there is nothing inherently unique in the implementation. I don't mean that it's just a user-wise thing and thus not an implementation thing. I mean that it's a user-wise thing therefore you don't have the choice to imitate it using a special implementation, if you are going to imitate it faithfully. The $-substitution isn't run on messageboxes when they get instantiated. That's the difference I'm talking about. This is also the difference that the new messagebox wouldn't imitate, so the new-style messageboxes wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathieu Bouchard wrote: Anyway, in m_pd.h, A_DOLLAR exists and A_DOLLARG doesn't. ah yes thanks for fixing. mfgws.g IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBAv4ACgkQkX2Xpv6ydvT1RwCg6bM7/tzkfnd946nm1alI8svB o8QAn00P8Kwy9raYY7JNQO4HTkiBLWR8 =0cmX -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathieu Bouchard wrote: wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case. you can get the unparsed arguments during runtime (though after creation time) just fine. this is what every save-routine does (unless somebody decides to really save 1053 instead of $0) masdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBBWYACgkQkX2Xpv6ydvQbeQCeLfh0hNvNZB9+KIZkWO6CtMx/ wGYAnAtJZ+x/ZcmFn9bLXfeMZhPV3SJd =NbBA -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 13.11.09 01:31 schrieb Phil Stone unter pkst...@ucdavis.edu: Mathieu Bouchard wrote: On Fri, 13 Nov 2009, Frank Barknecht wrote: Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different. $3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero it's a special case no matter what. Right. Which neatly brings the question back around to why can't $0 be used in message boxes? I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.* Since 1024-foo (where 1024 represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message? It probably belongs in the some things will never change in Pd category; therefore we must resign ourselves to this discussion re-appearing on a regular basis. $0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. I wouldn't want to have to pay attention to n in $n in order to determine its behaviour. And i also don't support a change that would introduce an inconsistency like that. Why don't people fight with the same effort to make $1 in message boxes be replaced by the first argument of the patch? Personally, i find it 'unecological' to just not use $0 at all in message boxes. I am haven't checked, but i think this idea must have been brought up already: Let's make $0 in message boxes be replaced by the selector of the incoming messages. Currently, it is quite cumbersome to type check a pd message and it requires a lot of patching. Using $0 to get the '0th' element of the incoming message would be consistent with the way $-variables are currently used in message boxes and it would be tremendously useful. Just to illustrate the proposed use of $0: the incoming message: the respective $0 'hallo velo''hallo' 'list mein fahrrad' 'list' 'symbol bike' 'symbol' '12 twentyfour' 'list' '12''float' 'bang' 'bang' 'bla' 'bla' If this could be implemented, any future discussion about why $0 in message boxes is not replaced by the canvas identifier would be lapsed. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already. The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? It would certainly end the discussions about the special (somehow undefined) state it has now. roman [1]: http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html Am 13.11.09 10:52 schrieb Roman Haefeli unter reduzie...@yahoo.de: Am 13.11.09 01:31 schrieb Phil Stone unter pkst...@ucdavis.edu: Mathieu Bouchard wrote: On Fri, 13 Nov 2009, Frank Barknecht wrote: Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different. $3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero it's a special case no matter what. Right. Which neatly brings the question back around to why can't $0 be used in message boxes? I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.* Since 1024-foo (where 1024 represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message? It probably belongs in the some things will never change in Pd category; therefore we must resign ourselves to this discussion re-appearing on a regular basis. $0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. I wouldn't want to have to pay attention to n in $n in order to determine its behaviour. And i also don't support a change that would introduce an inconsistency like that. Why don't people fight with the same effort to make $1 in message boxes be replaced by the first argument of the patch? Personally, i find it 'unecological' to just not use $0 at all in message boxes. I am haven't checked, but i think this idea must have been brought up already: Let's make $0 in message boxes be replaced by the selector of the incoming messages. Currently, it is quite cumbersome to type check a pd message and it requires a lot of patching. Using $0 to get the '0th' element of the incoming message would be consistent with the way $-variables are currently used in message boxes and it would be tremendously useful. Just to illustrate the proposed use of $0: the incoming message: the respective $0 'hallo velo''hallo' 'list mein fahrrad' 'list' 'symbol bike' 'symbol' '12 twentyfour' 'list' '12''float' 'bang' 'bang' 'bla' 'bla' If this could be implemented, any future discussion about why $0 in message boxes is not replaced by the canvas identifier would be lapsed. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already. Hi Roman, I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, and it's annoying to more experienced programmers. I want to address the point you brought up in the first message: $0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument repeated over and over as justification for its prohibition in message boxes? I just don't understand this. If only (as many have said) $0 had been written as #0 or something else completely un-encumbered with ideas about what $ must mean in Pd. The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or pure, given the unique role that $0 has in *all* cases. When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months! Best, Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Phil Stone wrote: I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, i agree and it's annoying to more experienced programmers. but i can't follow here .-) But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument actually i do. obviously it would break everything, so i won't say that loud. repeated over and over as justification for its prohibition in message boxes? I just don't understand this. If only (as many have said) $0 had been written as #0 or something else completely un-encumbered with ideas about what $ must mean in Pd. but why 0? what is #1 to mean then? i always favoured a more bash-like syntax, e.g. $$ (which is the PID of a process; i think this maps nicely to what $0 currently is) The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? because i want to get the selector of an object-box as well (it's name). Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or pure, given the unique role that $0 has in *all* cases. as explained lengthily months ago, i still don't think that messages should have any notion of the surrounding patch. When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months! don't know whether we should. most likely, we will. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
IOhannes m zmoelnig wrote: Phil Stone wrote: I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, i agree and it's annoying to more experienced programmers. but i can't follow here .-) Well, I'm annoyed. :-) But I think I'll get over it. But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument actually i do. obviously it would break everything, so i won't say that loud. snip as explained lengthily months ago, i still don't think that messages should have any notion of the surrounding patch. I'd be interested in reading that, though I haven't been able to find the post yet. Do you have a reference? Currently, the only time I've needed to get $0 into a message is for dynamic patching. Since this practice is an unloved bastard child of Pd, it's unlikely I'll get anywhere advocating for making it easier. Nevertheless, the less-readable patches (as if dynamic patches aren't obscure enough!) that result from the contortions needed to get $0 into the message annoy me, and tempt me to write bad, name-clash-ripe dynamic objects. Best, Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
While definitely understanding your irritation, the only point of your writing i was able to find is that it would make it 'easier'. I definitely cannot support the idea of making one special case (that arises a lot, i admit) easier, while disregarding completely the concepts and consistency. Luckily, i don't have make this decision. However, i still think $0 in message boxes should expand to the selector of the incoming message. roman On Fri, 2009-11-13 at 08:54 -0800, Phil Stone wrote: Roman Haefeli wrote: This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already. Hi Roman, I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, and it's annoying to more experienced programmers. I want to address the point you brought up in the first message: $0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2 in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument repeated over and over as justification for its prohibition in message boxes? I just don't understand this. If only (as many have said) $0 had been written as #0 or something else completely un-encumbered with ideas about what $ must mean in Pd. The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or pure, given the unique role that $0 has in *all* cases. When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months! Best, Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Fri, 2009-11-13 at 18:08 +0100, IOhannes m zmoelnig wrote: The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? because i want to get the selector of an object-box as well (it's name). What the hell is the selector of an object box? Not addressed to you directly, IOhannes: What is so difficult about thinking the canvas identifier as an implicitly given argument to a patch? If seen as that, it is not special at all as it is used in objects. While currently it still has a special status, how it is (not) used in message boxes. I see, that i am not adding to this discussion anymore. Sorry for that. Nevertheless, i'll fight against any change, that'll add inconsistencies. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: While definitely understanding your irritation, the only point of your writing i was able to find is that it would make it 'easier'. No, it's that the idea of $0 = special case is only used when talking about message boxes; $0 is also a special case in object boxes, yet it is accepted there. Thus, I find this argument inconsistent. I am quite willing to bear the continued burden of coaxing $0 into messages for dynamic patching (I simply have no choice). I would just like to see the reasoning against $0 in message boxes be less specious, and therefore less confusing to the overall issue. I definitely cannot support the idea of making one special case (that arises a lot, i admit) easier, while disregarding completely the concepts and consistency. As I said, it's the very *inconsistency* of this argument that bothers me. Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Well I don't know about implementation, but conceptually, I don't see $0 (in object boxes) as something that much different than $1..$n: you can think of $0 as just one more creation argument of the containing patch (a numeric value), only that it is assigned automatically and guaranteed to be unique. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting A for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrof...@gmail.com wrote: Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Alexandre Porres wrote: hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting A for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. A frequent pd design pattern is to have a subpatch that wants to, for example, tell its own subpatch about a unique array name or receive or receive~ object. The way this is commonly done is to make $0 of the subpatch the first argument to the subpatch's subpatch. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. Matt On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres por...@gmail.com wrote: hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting A for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrof...@gmail.com wrote: Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Fri, 13 Nov 2009, Roman Haefeli wrote: On Fri, 2009-11-13 at 18:08 +0100, IOhannes m zmoelnig wrote: The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing? because i want to get the selector of an object-box as well (it's name). What the hell is the selector of an object box? when an objectbox is created, its contents («binbuf») are $-evaluated as when a messagebox receives a message (but commas and semicolons are left untouched), and then the whole contents are sent to pd_objectmaker as a message. therefore [moses 42] has receiver=pd_objectmaker, selector=moses, $1=42. The selector is the creator's name, which is usually the same as the class' name, but not always (because aliases are possible). The difference is mostly only visible in the default names of helpfiles. I often say that the classname is the selector, even though it's not technically true, because it's almost true (a damn lot more than calling it the objectname, anyway). _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Oh, cool, yeah, that is a nice design, I see it now. but anyways, I still see $0 as locality and the rest as inheritance, as you are just still making a child inherit (by $1) a parent's local $0 ID. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. now that wasn't clear for me, but if we keep on it I suggest we might need to change the thread name maybe. I hope this thread would stick to the point that the find feature could do a better job by finding $0, and that $0 could be used in messages since it is useless the way it is. thanks alex On Fri, Nov 13, 2009 at 6:27 PM, Matt Barber brbrof...@gmail.com wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. Matt On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres por...@gmail.com wrote: hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting A for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrof...@gmail.com wrote: Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com : But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all,
Re: [PD] Finding $0 and dealing with it in messages
Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be on auto-repeat here. Phil http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe There's no guarantee of locality whatsoever in using $0 either. If you create a [send $0-xxx] and the identifier of the containing (instance of an) abstraction happens to be 1032, and then in some other patch or abstraction you have a literal [receive 1032-xxx], the locality will be lost. Using $0 as a prefix to the name of local sends and receives preserves locality only provided that you never use literal numbers as a prefix in the name of sends or receives. So $0 is not so different from other creation arguments (i.e. $1...); the difference is that it is assigned automatically by the system and that it is done in such a way that no two instances of any abstraction will have the same value of $0. Using it for creating local names is just one way of using it, just as you can use explicit creation arguments for the same purpose (by taking the responsibility of ensuring uniqueness), although it is probably its main intended use. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different. Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic. roman On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote: Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. .hc On Nov 13, 2009, at 6:50 PM, Roman Haefeli wrote: Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different. Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic. roman On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote: Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Here's my summary of the proposals mentioned here: I agree that $0 is totally arbitrary and is not inherintly bound to object boxes. I think this strongest proposed fix is to introduce $$ which works in both object and message boxes, its a nice parallel to Bourne Shell syntax. On that note, I think this should also come with Bourne Shell's $# for count of argument and $@ for a list of all arguments. I think $$, $#, and $@ should work in both message and object boxes. So: messages: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message objects: - $$ provides unique ID number - $# provides argument count from incoming message - $@ provides the list of arguments from incoming message Now, all we need is someone to code it :) I am certainly willing to try such a patch in the Pd-extended test builds. And if it is proven to work without causing problems, then it could be included in final release, and hopefully work its way into Pd-vanilla as well. I guess the place to start is someone putting together a proposal wiki page so we can document all the details. Here's the place for it: http://puredata.info/dev .hc Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Roman Haefeli wrote: Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different. Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic. roman Actually, all it would take to convert all old patches to this new form is one line of perl with a well-constructed regular expression. I agree, still, that it is probably not going to happen. Phil On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote: Matt Barber wrote: I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. Good points, all. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Alexandre Porres a écrit : Oh wow, no wonder I didn't know :) Ok, great, I will just wait for the official release :) pd 0.42 is in the air for about 1 year, pd 0.42-5 was officially release 6 month ago. http://crca.ucsd.edu/~msp/software.html Cyrille Anyway, It still bothers me not being able to deal with $0 on messages, what you guys think? is there a good reason for it to be this way? Or is it something that could be easily updated on a further version? Thanks Alex On Wed, Nov 11, 2009 at 9:32 PM, Max abonneme...@revolwear.com mailto:abonneme...@revolwear.com wrote: Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hey, sure, I meant the Pd-Extended version... :) On Thu, Nov 12, 2009 at 7:49 AM, cyrille henry c...@chnry.net wrote: Alexandre Porres a écrit : Oh wow, no wonder I didn't know :) Ok, great, I will just wait for the official release :) pd 0.42 is in the air for about 1 year, pd 0.42-5 was officially release 6 month ago. http://crca.ucsd.edu/~msp/software.html Cyrille Anyway, It still bothers me not being able to deal with $0 on messages, what you guys think? is there a good reason for it to be this way? Or is it something that could be easily updated on a further version? Thanks Alex On Wed, Nov 11, 2009 at 9:32 PM, Max abonneme...@revolwear.com mailto: abonneme...@revolwear.com wrote: Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
2009/11/12 Alexandre Porres por...@gmail.com Hey, sure, I meant the Pd-Extended version... :) http://autobuild.puredata.info/auto-build/latest/ the latest is always here. abraço glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
If you're interested, there was a huge thread about this in February, starting about here: http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html It continues, too -- it will look like the thread dies out, but if you look later in that month there will be many more posts with the same subject. Matt yep, sure, it works, but, anyway, I just think it would be easier for some operations if we could use $0 in messages, that's all... Thanks Cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
hmm, great, thanks, that is what I wondered, if anyone had bothered to bring this up. Anyway, from the thread: you are violating the 3rd rule of $-expansion: there is no $0 in message-boxes. I can deal around with it... but I just wonder if this third rule could be easily revised/changed. I don't see much of a problem, and it would make some stuff easier. So, here is my plead in favor of this case, I support the cause... But if you say that it would be a pain in the ass, or argue that such rule must be mantained for some logic reason, I am cool. I've read something about: it would make $0 be even more complicated to understand But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Without an exception at all, it should be easier to get it, as I understand. And despite all that, as I see, $0 on messages is just not good for anything. So, completely useless... it is just like putting a Zero... Sorry for insisting anyway... Thanks a lot On Thu, Nov 12, 2009 at 11:25 AM, Matt Barber brbrof...@gmail.com wrote: If you're interested, there was a huge thread about this in February, starting about here: http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html It continues, too -- it will look like the thread dies out, but if you look later in that month there will be many more posts with the same subject. Matt yep, sure, it works, but, anyway, I just think it would be easier for some operations if we could use $0 in messages, that's all... Thanks Cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hallo, Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
On Fri, 13 Nov 2009, Frank Barknecht wrote: Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different. $3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero it's a special case no matter what. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Mathieu Bouchard wrote: On Fri, 13 Nov 2009, Frank Barknecht wrote: Alexandre Porres hat gesagt: // Alexandre Porres wrote: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different. That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different. $3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero it's a special case no matter what. Right. Which neatly brings the question back around to why can't $0 be used in message boxes? I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.* Since 1024-foo (where 1024 represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message? It probably belongs in the some things will never change in Pd category; therefore we must resign ourselves to this discussion re-appearing on a regular basis. Phil Stone http://www.pkstonemusic.com/pubmusic.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Finding $0 and dealing with it in messages
Hi folks, what's up? Hope you're all well. I find it somewhat annoying that $0 doesn't work on messages, is it really impossible? Now, the worst part is that if you need to go to the find menu and search for $0-something it does not find it!!! Is there any way around it? I even tried sending a message to pd properly but it insists on saying things like 1002-something not found... Wouldn't it be nice if some core code changes were made so finding $0 and dealing with it in messages would work? I wouldn't know how to do it anyway... Does this bother other people who knows how to? :) Thanks a lot See ya ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Alexandre Porres a écrit : Hi folks, what's up? Hope you're all well. I find it somewhat annoying that $0 doesn't work on messages, is it really impossible? Now, the worst part is that if you need to go to the find menu and search for $0-something it does not find it!!! Is there any way around it? search for -something and unclick whole word toggle. it should work. c I even tried sending a message to pd properly but it insists on saying things like 1002-something not found... Wouldn't it be nice if some core code changes were made so finding $0 and dealing with it in messages would work? I wouldn't know how to do it anyway... Does this bother other people who knows how to? :) Thanks a lot See ya ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? Can't seem to find it on my Pd-extended for Mac OS. I will look harder though. thanks a bunch On Wed, Nov 11, 2009 at 8:01 PM, cyrille henry c...@chnry.net wrote: Alexandre Porres a écrit : Hi folks, what's up? Hope you're all well. I find it somewhat annoying that $0 doesn't work on messages, is it really impossible? Now, the worst part is that if you need to go to the find menu and search for $0-something it does not find it!!! Is there any way around it? search for -something and unclick whole word toggle. it should work. c I even tried sending a message to pd properly but it insists on saying things like 1002-something not found... Wouldn't it be nice if some core code changes were made so finding $0 and dealing with it in messages would work? I wouldn't know how to do it anyway... Does this bother other people who knows how to? :) Thanks a lot See ya ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
the 'whole word thing was introducted in 0.42.5 .hc On Nov 11, 2009, at 6:19 PM, Alexandre Porres wrote: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? Can't seem to find it on my Pd-extended for Mac OS. I will look harder though. thanks a bunch On Wed, Nov 11, 2009 at 8:01 PM, cyrille henry c...@chnry.net wrote: Alexandre Porres a écrit : Hi folks, what's up? Hope you're all well. I find it somewhat annoying that $0 doesn't work on messages, is it really impossible? Now, the worst part is that if you need to go to the find menu and search for $0-something it does not find it!!! Is there any way around it? search for -something and unclick whole word toggle. it should work. c I even tried sending a message to pd properly but it insists on saying things like 1002-something not found... Wouldn't it be nice if some core code changes were made so finding $0 and dealing with it in messages would work? I wouldn't know how to do it anyway... Does this bother other people who knows how to? :) Thanks a lot See ya ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
|bang/ | [f $0] | [makefilename %d-sample] | [set $1/ | |window_number-sample/ -- that's what you need. abraçz glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Oh wow, no wonder I didn't know :) Ok, great, I will just wait for the official release :) Anyway, It still bothers me not being able to deal with $0 on messages, what you guys think? is there a good reason for it to be this way? Or is it something that could be easily updated on a further version? Thanks Alex On Wed, Nov 11, 2009 at 9:32 PM, Max abonneme...@revolwear.com wrote: Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
thanks glerm, I had tried that, but it doesn't work on the find window... On Wed, Nov 11, 2009 at 9:38 PM, glerm soares organi...@gmail.com wrote: |bang/ | [f $0] | [makefilename %d-sample] | [set $1/ | |window_number-sample/ -- that's what you need. abraçz glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Have you tried: [bang( | [f $0] | [$1-message( .mmb Alexandre Porres wrote: Oh wow, no wonder I didn't know :) Ok, great, I will just wait for the official release :) Anyway, It still bothers me not being able to deal with "$0" on messages, what you guys think? is there a good reason for it to be this way? Or is it something that could be easily updated on a further version? Thanks Alex On Wed, Nov 11, 2009 at 9:32 PM, Max abonneme...@revolwear.com wrote: Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty "Whole Word" Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
yep, sure, it works, but, anyway, I just think it would be easier for some operations if we could use $0 in messages, that's all... Thanks Cheers Alex On Thu, Nov 12, 2009 at 3:00 AM, Mike Moser-Booth mmoserbo...@gmail.comwrote: Have you tried: [bang( | [f $0] | [$1-message( .mmb Alexandre Porres wrote: Oh wow, no wonder I didn't know :) Ok, great, I will just wait for the official release :) Anyway, It still bothers me not being able to deal with $0 on messages, what you guys think? is there a good reason for it to be this way? Or is it something that could be easily updated on a further version? Thanks Alex On Wed, Nov 11, 2009 at 9:32 PM, Max abonneme...@revolwear.com wrote: Am 12.11.2009 um 00:19 schrieb Alexandre Porres: Hmmm, it does look simpler than I thought :) Now, where can I find this pretty Whole Word Toggle? in the devel version http://autobuild.puredata.org/auto-build/latest/ -- ___pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
