Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-18 19:33, Hans-Christoph Steiner wrote: You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. you could even do this as an abstraction. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KD08ACgkQkX2Xpv6ydvR7/QCeK0XevUIDMeNcTS/mSSCe8fFC zegAoM3qLm+Su2HtYnFw2LIkqcndcBcH =OOvS -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-18 21:34, Hans-Christoph Steiner wrote: Yes the depth should be settable, that should be possible to add, not a lot of work. it probably should be settable. however, i never encountered a real need for that, that's why it's not there. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KEAkACgkQkX2Xpv6ydvQCGQCgtdkYlbN8hdjHPDuSwDpTG6sb eQAAnRiB0v4p4LHjyKy1JTJiVTH02rax =gnjd -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-18 21:44, Jonathan Wilkes wrote: work. Which differentiates between list and bang? canvasargs I think. has that ever created a problem for you, or is your complaint purely academic? would it help you, if there was a [set( message that would do the same thing as the current [list(? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KEN4ACgkQkX2Xpv6ydvTnxACgyQKXE2lhTaENAoztKODAqt5o TGgAn2i8bG1XY42cn9J8cwd08nkkWDJ+ =XII6 -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-18 18:49, Mathieu Bouchard wrote: But if you want dynamic naming, there's [receives] with an s, which there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name) truct. I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) I don't remember Czaja's talk in particular, but the idea must have been in the air back then. Flext 0.4 (nov 2002) introduced Jitter-style attributes in Pd, and I added my own kind of attributes in GridFlow in 2005 by introducing parsing of the comma in objectboxes so that attributes setters always counted as ordinary messages. iirc, the xeq approach was more like having multiple objects connected via a filehandle like thing; so you could have an object that just opens the file, and another objects that would seek within that file. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KEicACgkQkX2Xpv6ydvQOjwCgyg+ZgxHote1xAeA8JLOD1bJp VZcAmQE0vIbt5xSAj7PiVmNKsTiXyTbR =HLdf -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-18 19:43, Miller Puckette wrote: I'm with Hans -- e.g., 'list' where there's a whole slew of functionalities masquerading as a single class (and sharing a help file), but in which you only need one object for each type of use, e.g., list nth. while i'm all for one objectclass per functionality, and for establishing a single idiom (at least, per objectclass family) - and thus think i'm with hans also, i still don't see any point in masquerading as a single class. what makes the name [list foo] any better than [listfoo]? objects with proper names - that don't involve mummmers - can still share the same help-patch (if needed). mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KPMgACgkQkX2Xpv6ydvSmQQCgxxs7OYZFM7jBAz7TU0/77LUN 6dIAn1qZsIDCZb4Z2bq4bMHS3ZNa5kzC =OXtX -END PGP SIGNATURE- 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] get method for Pd
Le 2011-11-21 à 09:56:00, IOhannes m zmoelnig a écrit : On 2011-11-18 18:49, Mathieu Bouchard wrote: But if you want dynamic naming, there's [receives] with an s, which there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name) Actually, it doesn't do the same. But it's harder to do, because [multireceive] doesn't have a help file at all, whereas [receives] has http://gridflow.ca/help/receives-help.html For the problem we were talking about, [multireceive] fits the problem more directly. However, [receives] is more geared towards local receivers, with automatic joining of a prefix (such as «$0-») from receive-symbols. The job that I do using [receives] (managing a lot of iemguis) would have taken many more objects if I had been trying to use [multireceive] instead. With [receives], pd feels a lot more like it supports local-symbols. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit : while i'm all for one objectclass per functionality, and for establishing a single idiom (at least, per objectclass family) - and thus think i'm with hans also, i still don't see any point in masquerading as a single class. what makes the name [list foo] any better than [listfoo]? It's a form of namespacing. Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas. objects with proper names - that don't involve mummmers - can still share the same help-patch (if needed). (What are you talking about ?) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-21 20:56, Mathieu Bouchard wrote: Le 2011-11-21 à 09:56:00, IOhannes m zmoelnig a écrit : On 2011-11-18 18:49, Mathieu Bouchard wrote: But if you want dynamic naming, there's [receives] with an s, which there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name) Actually, it doesn't do the same. But it's harder to do, because [multireceive] doesn't have a help file true. thanks for going through the trouble to understand it. at all, whereas [receives] has http://gridflow.ca/help/receives-help.html after having a look, i see that [receives] is not such a good name as i initially thought. gmsd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KsKUACgkQkX2Xpv6ydvR3EwCfRofXpJl5SeoO3r0vKhWCTQjx rCgAnjbarKFCMRhC5oqsYYuNGyuMdZuJ =ZRgC -END PGP SIGNATURE- 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] get method for Pd
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Cc: pd-list@iem.at Sent: Monday, November 21, 2011 3:02 PM Subject: Re: [PD] get method for Pd Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit : while i'm all for one objectclass per functionality, and for establishing a single idiom (at least, per objectclass family) - and thus think i'm with hans also, i still don't see any point in masquerading as a single class. what makes the name [list foo] any better than [listfoo]? Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers. Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch. It's a form of namespacing. Hyphens work, too, but two words against each other are less readable. -Jonathan Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas. objects with proper names - that don't involve mummmers - can still share the same help-patch (if needed). (What are you talking about ?) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] get method for Pd
Le 2011-11-21 à 12:35:00, Jonathan Wilkes a écrit : Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers. Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch. http://upload.wikimedia.org/wikipedia/commons/f/fe/Codex_Sinaiticus_Paralipomenon_9%2C27-10%2C11.JPG http://en.wikipedia.org/wiki/Scriptio_continua Hyphens work, too, but two words against each other are less readable. I really meant to compare «namespacing» with whichever form of single-symbol name compares more favourably, which is often not the one without a delimiter. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-21 à 21:12:00, IOhannes m zmoelnig a écrit : On 2011-11-21 20:56, Mathieu Bouchard wrote: at all, whereas [receives] has http://gridflow.ca/help/receives-help.html after having a look, i see that [receives] is not such a good name as i initially thought. Hahaha ! And don't care about explaining yourself, of course ! __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-21 21:35, Jonathan Wilkes wrote: what makes the name [list foo] any better than [listfoo]? Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers. Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch. i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world. for unknown reasons, it seems that [text file] seems to work for lots of people. It's a form of namespacing. and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator. i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens. Hyphens work, too, but two words against each other are less readable. i'm fine with hyphen, underscore, CamelCase. i just don't like space. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Kve8ACgkQkX2Xpv6ydvRP6ACgq0ROp6mYOhJV4ufpU+2UwVG+ DLgAn3wRvqLMLqY0MbAv9AOKUa9Hydmr =COwq -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-21 22:04, Mathieu Bouchard wrote: Le 2011-11-21 à 21:12:00, IOhannes m zmoelnig a écrit : On 2011-11-21 20:56, Mathieu Bouchard wrote: at all, whereas [receives] has http://gridflow.ca/help/receives-help.html after having a look, i see that [receives] is not such a good name as i initially thought. Hahaha ! And don't care about explaining yourself, of course ! it wasn't meant to be offensive (in case you read it like that). i think that [receives] is a great name for a multiple receives object. however, i think that the prefix functionality of [receives] (which is very present, being the 1st argument) is a bit confusing in this context. for me, the name [receives] would be great, if you could use it without having to the prefix (and no, i don't think that using [loadbang]-[foo bar( is a proper replacement, nor [recevies, foo bar]) fmgadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Kv1YACgkQkX2Xpv6ydvR+IQCfUykgR6wLrelxOldpc1Oe2BDU pU4An2GH4/vKES3+eB3SMO1GF9ydI75o =5tUe -END PGP SIGNATURE- 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] get method for Pd
On Monday, November 21, 2011 3:02 PM, Mathieu Bouchard ma...@artengine.ca wrote: Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit : while i'm all for one objectclass per functionality, and for establishing a single idiom (at least, per objectclass family) - and thus think i'm with hans also, i still don't see any point in masquerading as a single class. what makes the name [list foo] any better than [listfoo]? It's a form of namespacing. Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas. pdtk_canvas is the new namespace, and pdtk_canvas_popup is the legacy name. Remember, part of the mandate of the pd-gui rewrite was not changing the C code. Therefore not everything could be renamed. .hc objects with proper names - that don't involve mummmers - can still share the same help-patch (if needed). (What are you talking about ?) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] get method for Pd
Le 2011-11-21 à 22:09:00, IOhannes m zmoelnig a écrit : and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator. It's good if you want to implement the new functionality as one big class while pretending that it's many small classes to people who want that ;) i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens. Tcl has two different namespace mechanisms, the ::-separated one, called «namespaces» actually were introduced after the space-separated one, which is called «ensembles» nowadays. Space is also a token-separator in Tcl, and this makes the function name be the first argument of the call to the ensemble that is posing as a function. That's just like in Pd. I think Tcl has had that for about 20 years. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Mathieu Bouchard ma...@artengine.ca; pd-list@iem.at pd-list@iem.at Sent: Monday, November 21, 2011 4:09 PM Subject: Re: [PD] get method for Pd -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-21 21:35, Jonathan Wilkes wrote: what makes the name [list foo] any better than [listfoo]? Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers. Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch. i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world. English speakers don't live in the real world? -Jonathan for unknown reasons, it seems that [text file] seems to work for lots of people. It's a form of namespacing. and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator. i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens. Hyphens work, too, but two words against each other are less readable. i'm fine with hyphen, underscore, CamelCase. i just don't like space. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Kve8ACgkQkX2Xpv6ydvRP6ACgq0ROp6mYOhJV4ufpU+2UwVG+ DLgAn3wRvqLMLqY0MbAv9AOKUa9Hydmr =COwq -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-21 à 22:15:00, IOhannes m zmoelnig a écrit : however, i think that the prefix functionality of [receives] (which is very present, being the 1st argument) is a bit confusing in this context. for me, the name [receives] would be great, if you could use it without having to the prefix (and no, i don't think that using [loadbang]-[foo bar( is a proper replacement, nor [recevies, foo bar]) the working syntax is [receives, list foo bar], because it takes a list-message, not a anything. I'll let you explain what is a « proper replacement ». Oh yeah, another thing that I hadn't noticed at first. Actually, I had assumed that [multireceive] was doing something interesting. What I said about using it in place of [receives] is actually wrong : in my abstractions, I just can't use [multireceive] at all for managing gui objects, because it doesn't have an outlet for telling me which thing just got modified ! Actually, I have no idea why [multireceive] exists the way it is. I can hardly think of a use for it, when it doesn't allow to distinguish between receive-symbols. Look at the example at the top-left of receives-help.html : you can't do that with a (single) [multireceive] ! __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-21 23:05, Jonathan Wilkes wrote: i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world. English speakers don't live in the real world? english speakers usually don't encounter these compound words since they (the words) are not used in their (the people's) everyday life. thus i assumed that these compound words do not impose any problems for those people (unless they are communicating with germans that keep glueing words together) german speakers have to deal with these words on a day by day basis, and for them it usually does not make a lot of problems in their real world. fmgar IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7K0bEACgkQkX2Xpv6ydvQnvgCeOFPT5g9hoc+1t3/BLSEAlX8W 1xwAniHJG1ZeuKLND0VjBEMstncgSH4j =SrdD -END PGP SIGNATURE- 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] get method for Pd
Le 2011-11-21 à 23:33:00, IOhannes m zmoelnig a écrit : On 2011-11-21 23:05, Jonathan Wilkes wrote: English speakers don't live in the real world? english speakers usually don't encounter these compound words since they (the words) are not used in their (the people's) everyday life. « communication » comes from « communicate », which comes from « common ». Well, actually, it's more like it came from latin « commūnicātiōnem », which came from « commūnicāre », which came from « commūnis », but my point is about suffix aggregation. For « compound » and « component », however, it comes from com- (together) and -ponere (to put). This is actually copy-paste from several wiktionary pages (I don't know any latin !). thus i assumed that these compound words do not impose any problems for those people (unless they are communicating with germans that keep glueing words together) assumed = ad+sūmō+ed ; impose = in+ponere ; problem = pro+ballo (before several mutations) ; unless = un+less ; glueing = glue+ing ; together = to+gether (with various old spellings) ; german speakers have to deal with these words on a day by day basis, and for them it usually does not make a lot of problems in their real world. usual+ly -BEGIN PGP SIGNATURE- sign+ature __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 15:16:00, katja a écrit : On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: I made a patch awhile back that added a get method to pd And considering the set method, which is now implicit like in [; pd dsp 1(, it would be nice to have: [; pd samplerate samplerate( In the model I use for attributes (in GridFlow), the name of the attribute is always the same as the name of the set-method, and for getting, there is a single get-method that takes the attribute name in $1, defaulting to all. IIRC, everybody does it like that in Pd, and perhaps in MAX too, but I don't really remember. I mean I think that we all agree on this. (DS [set] is an exception to this model, in some way... but DS don't have inlets nor receivers accessible from pd, anyway, so, they wouldn't be able to fit the model) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 9:58 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 7:19 PM Subject: Re: [PD] get method for Pd So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts. How do they get from iemguts to core pd? I don't see a need to do that, so that's a question for someone else to answer. .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. .hc On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote: Hi all, i can't read in detail the whole thread, but just a remark: I think what you have in mind is close to the idea of patcher attributes in Max, where you'd have a [pattrhub] object in the abstraction and you can either ask it for built-in object attributes or [pattr] patcher variables. I implemented a similar idea already some years ago with the [absattr] object, which was extensively used in the vibrez project. It connect to the concept of flext-style attributes. It's here: https://svn.g.org/ext/trunk/absattr gr~~~ Bild 2.png Am 17.11.2011 um 19:42 schrieb Miller Puckette: This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). But there are other situation which seem to beg for the receive solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: [get linecount( | | [textfile -reference] | | |[textfile] V [15 (where 15 would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) cheers Miller On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 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 The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Thomas Grill g...@g.org Cc: pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 10:16 AM Subject: Re: [PD] get method for Pd This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c. -Jonathan .hc On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote: Hi all, i can't read in detail the whole thread, but just a remark: I think what you have in mind is close to the idea of patcher attributes in Max, where you'd have a [pattrhub] object in the abstraction and you can either ask it for built-in object attributes or [pattr] patcher variables. I implemented a similar idea already some years ago with the [absattr] object, which was extensively used in the vibrez project. It connect to the concept of flext-style attributes. It's here: https://svn.g.org/ext/trunk/absattr gr~~~ Bild 2.png Am 17.11.2011 um 19:42 schrieb Miller Puckette: This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). But there are other situation which seem to beg for the receive solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: [get linecount( | | [textfile -reference] | | | [textfile] V [15 (where 15 would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) cheers Miller On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info
Re: [PD] get method for Pd
Le 2011-11-17 à 10:42:00, Miller Puckette a écrit : This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. It doesn't have to be written as such in the patch. A send/receive pair can be bundled together as one object. It would solve a more general problem of making things more readable in pd which would reach beyond just [samplerate~] or queries to canvases. A few convenient shortcuts are sometimes all it takes to make a big difference in readability. Trying to stick to a minimal set of basic constructs forces the user to do more work than what would be necessary. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). Pd has a cool and very important feature named « abstractions », and using $0, you can create a unique receiver name without even having to think about it. No need for dynamic naming. But if you want dynamic naming, there's [receives] with an s, which allows a single object to receive from many names at once and distinguish them while having always 2 outlets. You can use it with 1-element lists if you want. See this patch (screenshot) : http://gridflow.ca/help/receives-help.html BTW, [receives] was actually meant to manage large number of GUI objects matching attributes, method names, and a get-method, without making patches unreadable. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: You don't give any explanation of why you think it's migraine-inducing. I don't think that it's obvious why [get( and right-outlet could be more migraine-inducing than the average pd construct. I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) I don't remember Czaja's talk in particular, but the idea must have been in the air back then. Flext 0.4 (nov 2002) introduced Jitter-style attributes in Pd, and I added my own kind of attributes in GridFlow in 2005 by introducing parsing of the comma in objectboxes so that attributes setters always counted as ordinary messages. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 10:16:00, Hans-Christoph Steiner a écrit : This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. Is the goal to make pd easier to use for complex problems, or is the goal to create lots of tiny classes for the sake of ideology ? I don't mind small classes and I do have problems with certain huge classes being huge (in Max) and bundling lots of things that they could outsource, but [absattr-sub] doesn't look like one. Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit : The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;) try again. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. I think having individual objects that are bangable is the best approach. Why don't you like it? I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c. I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib. .hc Making boring techno music is really easy with modern tools, 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] get method for Pd
I'm with Hans -- e.g., 'list' where there's a whole slew of functionalities masquerading as a single class (and sharing a help file), but in which you only need one object for each type of use, e.g., list nth. cheers M On Fri, Nov 18, 2011 at 01:23:12PM -0500, Mathieu Bouchard wrote: Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit : The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;) try again. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] get method for Pd
On Nov 18, 2011, at 1:23 PM, Mathieu Bouchard wrote: Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit : The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;) try again. I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 14:40:00, Jonathan Wilkes a écrit : efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). BTW, the one nowadays in listabs is the simplest of the fast [list-drip] implementations. The faster ones are more complex, but they're all based on the one bundled in listabs. None of them are nearly as fast as [foreach] though. The gap widened in GridFlow 9.13 and 9.14, when the C++-wrapper used by GridFlow became much more efficient. A plain C version of [foreach] might still be a tiny bit faster, but I don't know. Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. It's always better to be in big trouble than in any trouble bigger than it. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit : I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this. Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces. try again. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 1:01 PM, Mathieu Bouchard wrote: Le 2011-11-18 à 10:16:00, Hans-Christoph Steiner a écrit : This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. Is the goal to make pd easier to use for complex problems, or is the goal to create lots of tiny classes for the sake of ideology ? I don't mind small classes and I do have problems with certain huge classes being huge (in Max) and bundling lots of things that they could outsource, but [absattr-sub] doesn't look like one. Obviously, there are objects that are too simple just as there are objects that are too complex. One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc.. So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list. Its easy when its divided in the right way. Take canvas visibility. If this is its own [canvasvisible] object, then [bang( means get the value and [float 1( means set the value. Then on the output we receive a float representing the visibility. Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax. I am fine with expr since I can also use [*] [+] [-] [/], etc. .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 2:06 PM, Mathieu Bouchard wrote: Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit : I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this. Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces. Why on earth would you do that? That would be a worthless exercise. The point is to have overview content, quick reference content, and learning content. These are all separate things. .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Hans-Christoph Steiner h...@at.or.at Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 2:06 PM Subject: Re: [PD] get method for Pd Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit : I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this. Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces. try again. Please use telepathy to let me know the places where I have the same material in the object help and pasted it to all_about_*. I will then try to remove it from the object help and just make a reference to the all_about_* with pddp/pddplink so that the info is only in one place. However I should warn you that I will travel to the past to make the revisions in a cruel attempt to make it look like you didn't actually read any of the all_about_* patches in the first place. -Jonathan __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] get method for Pd On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. I think having individual objects that are bangable is the best approach. Why don't you like it? Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain. I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between list and bang to trigger different behavior, and the level for [sendcanvas] isn't settable. -Jonathan * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c. I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib. .hc Making boring techno music is really easy with modern tools, 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] get method for Pd
On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] get method for Pd On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. I think having individual objects that are bangable is the best approach. Why don't you like it? Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain. I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches. I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between list and bang to trigger different behavior, and the level for [sendcanvas] isn't settable. Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang? That can make sense depending on the context. .hc -Jonathan * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c. I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts
Re: [PD] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 3:34 PM Subject: Re: [PD] get method for Pd On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] get method for Pd On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. I think having individual objects that are bangable is the best approach. Why don't you like it? Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain. I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches. I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between list and bang to trigger different behavior, and the level for [sendcanvas] isn't settable. Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang? canvasargs I think. That can make sense depending on the context. Name another object in the history of Pd that (purposefully) does that. -Jonathan .hc -Jonathan * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those
Re: [PD] get method for Pd
Le 2011-11-18 à 14:20:00, Hans-Christoph Steiner a écrit : Obviously, there are objects that are too simple just as there are objects that are too complex. ok. One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc.. What's not a built-in atom type in there ? [textfile], [comport] and [hid] only use built-in atom types. If you mean messages that are not anythings, then you have to know that bangs and lists are not atoms, they're messages (but list elements are atoms, selectors are symbols, etc). But I don't know why you consider this to be valuable, nor why you didn't talk about it in the last ten years or so, nor why nobody else ever did. So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list. You made up the previous principle so that you could promote a design that wouldn't otherwise have an advantage of its own. Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax. I am fine with expr since I can also use [*] [+] [-] [/], etc. That is not an answer to my question. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 3:50 PM, Mathieu Bouchard wrote: Le 2011-11-18 à 14:20:00, Hans-Christoph Steiner a écrit : Obviously, there are objects that are too simple just as there are objects that are too complex. ok. One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc.. What's not a built-in atom type in there ? [textfile], [comport] and [hid] only use built-in atom types. If you mean messages that are not anythings, then you have to know that bangs and lists are not atoms, they're messages (but list elements are atoms, selectors are symbols, etc). But I don't know why you consider this to be valuable, nor why you didn't talk about it in the last ten years or so, nor why nobody else ever did. I don't really see a point in continuing this conversation when you consider whatever I write is all just whitewashing to further my secret agenda. I really have no secret agenda, and I'm just trying to communicate. So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list. You made up the previous principle so that you could promote a design that wouldn't otherwise have an advantage of its own. Why on earth would I do that? .hc Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax. I am fine with expr since I can also use [*] [+] [-] [/], etc. That is not an answer to my question. All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 12:44:00, Jonathan Wilkes a écrit : Name another object in the history of Pd that (purposefully) does that. http://gridflow.ca/help/gf/selector-help.html __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 22:24:00, Hans-Christoph Steiner a écrit : You think that ~2300 words is not particularly large for a help file? That's now long Tcl's info help is. I don't think any Pd help patch has anywhere close to 2300 words. wc -w #convolve-help.pd says 3086, but counting only the contents of the comments, it's 1596. To be fair, however, you have to count the code examples, and doc elements that aren't plain comments, so it's probably closer to 2000. http://gridflow.ca/help/%23convolve-help.html But that's because it contains a whole tutorial, too. Otherwise, the design of the thing is quite simple. I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 56 words and doesn't even come with a Ctrl+f feature. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@at.or.at; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; Thomas Grill g...@g.org; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 4:06 PM Subject: Re: [PD] get method for Pd Le 2011-11-18 à 12:44:00, Jonathan Wilkes a écrit : Name another object in the history of Pd that (purposefully) does that. http://gridflow.ca/help/gf/selector-help.html Dammit! I overplayed my hand. Ok, so you have an object to report the actual selector getting passed around in Pd, which obviously differentiates between between list and bang. So-- name two!* * doesn't include any externals like selector that suffer from pd-dev reverb, which is the phenomena of missing features in the core being reflected in multiple externals by different authors which all do essentially the same thing. -Jonathan __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Hans-Christoph Steiner h...@at.or.at Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 4:31 PM Subject: Re: [PD] get method for Pd Le 2011-11-17 à 22:24:00, Hans-Christoph Steiner a écrit : You think that ~2300 words is not particularly large for a help file? That's now long Tcl's info help is. I don't think any Pd help patch has anywhere close to 2300 words. wc -w #convolve-help.pd says 3086, but counting only the contents of the comments, it's 1596. To be fair, however, you have to count the code examples, and doc elements that aren't plain comments, so it's probably closer to 2000. http://gridflow.ca/help/%23convolve-help.html But that's because it contains a whole tutorial, too. Otherwise, the design of the thing is quite simple. I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 56 words and doesn't even come with a Ctrl+f feature. Did you make a bug report? -Jonathan __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 11:37:00, Jonathan Wilkes a écrit : Please use telepathy to let me know the places where I have the same material in the object help and pasted it to all_about_*. I'm not even talking about the existing ones. However I should warn you that I will travel to the past to make the revisions in a cruel attempt to make it look like you didn't actually read any of the all_about_* patches in the first place. I didn't even have to travel back to the past to make you look like you didn't read my mail. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 13:43:00, Jonathan Wilkes a écrit : From: Mathieu Bouchard ma...@artengine.ca I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 56 words and doesn't even come with a Ctrl+f feature. Did you make a bug report? No, because the book actually works. No-one complains about it. Well, except Charlie Brown. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 3:44 PM, Jonathan Wilkes wrote: On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote: On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive. The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all. What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s). For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features: * ability to return all data with a single bang/get/whatever message. One-object-per-datum like [version], [rtflag], [nogui], etc. isn't optimal. I think having individual objects that are bangable is the best approach. Why don't you like it? Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain. I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches. I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between list and bang to trigger different behavior, and the level for [sendcanvas] isn't settable. Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang? canvasargs I think. That can make sense depending on the context. Name another object in the history of Pd that (purposefully) does that. I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result. .hc -Jonathan .hc -Jonathan * clear syntax that can be extended to other areas of pd. I like the get $something syntax because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( * for canvases, the user must be able to make a distinction between this local canvas and all canvases that have this receive symbol. (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with pd-.) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c. I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag,
Re: [PD] get method for Pd
Le 2011-11-18 à 16:02:00, Hans-Christoph Steiner a écrit : I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result. Read it as « a bang or an empty list ». The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 18, 2011, at 4:55 PM, Mathieu Bouchard wrote: Le 2011-11-18 à 16:02:00, Hans-Christoph Steiner a écrit : I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result. Read it as « a bang or an empty list ». The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't. Hmm, I think it really the opposite, an empty list is cast as a bang. That's how its generally implemented anyway. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 13:42:00, Jonathan Wilkes a écrit : So-- name two!* Any grid-processing inlet does distinguish between float and list, though the object they're on might not always use the difference. But that's not the same as making a difference between bang and list, which is more rare. Let me think some more. ... Actually, in the help of [gf/selector], it says « unlike [route] ». Well, GridFlow has two [route]-like classes that don't behave like [route] : http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html So I just named two more. They're acknowledging the concept of [route] while working around certain problems that either needs a lot of repetitive solving or that just can't be worked around without externals. That way you have short AND clean ways of using [route]. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 16:57:00, Hans-Christoph Steiner a écrit : On Nov 18, 2011, at 4:55 PM, Mathieu Bouchard wrote: Read it as « a bang or an empty list ». The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't. Hmm, I think it really the opposite, an empty list is cast as a bang. That's how its generally implemented anyway. pd_defaultbang() casts bang to list when there is no bang-method. pd_defaultlist() casts list to bang wheh there is no list-method and the list has 0 arguments (otherwise it casts to something else or tries to auto-unpack) So, it's really both, but at least I didn't claim that there was only one converter. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@at.or.at; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; Thomas Grill g...@g.org; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 4:53 PM Subject: Re: [PD] get method for Pd Le 2011-11-18 à 13:42:00, Jonathan Wilkes a écrit : So-- name two!* Any grid-processing inlet does distinguish between float and list, though the object they're on might not always use the difference. But that's not the same as making a difference between bang and list, which is more rare. Let me think some more. ... Actually, in the help of [gf/selector], it says « unlike [route] ». Well, GridFlow has two [route]-like classes that don't behave like [route] : http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html So I just named two more. What are the contexts where you have used either of these to differentiate between a bang and an empty list? -Jonathan They're acknowledging the concept of [route] while working around certain problems that either needs a lot of repetitive solving or that just can't be worked around without externals. That way you have short AND clean ways of using [route]. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-18 à 14:22:00, Jonathan Wilkes a écrit : - Original Message - From: Mathieu Bouchard ma...@artengine.ca http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html So I just named two more. What are the contexts where you have used either of these to differentiate between a bang and an empty list? Oh. I haven't. The workarounds I'm talking about are actually about [route] potentially producing anythings when you either wanted the message as-is or just with the selector replaced by «list» ; and the problem in which «list 42» is undistinguishable from «list list 42», or something like that. The fact that it doesn't try to fudge the selector, was because anything-methods don't do this automatically and I wasn't concerned with that problem. BTW, GridFlow used to distinguish between bang and list in a lot more places, but that was a design mistake (and/or a lingering jMaxism ?) which got fixed as recently as 9.11. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts. https://github.com/pd-projects/info .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 7:19 PM Subject: Re: [PD] get method for Pd So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts. How do they get from iemguts to core pd? https://github.com/pd-projects/info .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 02:43, Jonathan Wilkes wrote: I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [...] wouldn't it be easier to use a syntax like [get rcvname attribute( ? rather than [get attribute rcvname( i think sending the rcvname first will make the syntax more easily extendible. e.g. it would allow for [tryset rcvname attribute values...( and the like. madf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ExsQACgkQkX2Xpv6ydvRm7gCcCY+tuCG95nwLHoOw7nm46zdl gEEAoI57wflBh6egv1Vh5WlQ3PVC3VGV =wHPp -END PGP SIGNATURE- 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] get method for Pd
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name [; pd get float-precision rcv-name( sends float-precision $ to rcv-name (expressed as 8*sizeof(t_float)) [; pd get pd-path rcv-name( sends pd-path path/to/pd to rcv-name Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, 2011-11-17 at 13:14 +0100, katja wrote: On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name [; pd get float-precision rcv-name( sends float-precision $ to rcv-name (expressed as 8*sizeof(t_float)) [; pd get pd-path rcv-name( sends pd-path path/to/pd to rcv-name To complement the last one (in the syntax proposed by IOhannes): [; pd get rcv-name start-path( Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
How about [; pd get self rcv-name( Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear. On Thu, 17 Nov 2011 13:14:58 +0100 katja katjavet...@gmail.com wrote: On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name [; pd get float-precision rcv-name( sends float-precision $ to rcv-name (expressed as 8*sizeof(t_float)) [; pd get pd-path rcv-name( sends pd-path path/to/pd to rcv-name Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Andy Farnell padawa...@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] get method for Pd How about [; pd get self rcv-name( Not sure I understand this one-- what comes out of [r rcv-name] here? -Jonathan Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear. On Thu, 17 Nov 2011 13:14:58 +0100 katja katjavet...@gmail.com wrote: On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name [; pd get float-precision rcv-name( sends float-precision $ to rcv-name (expressed as 8*sizeof(t_float)) [; pd get pd-path rcv-name( sends pd-path path/to/pd to rcv-name Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Andy Farnell padawa...@obiwannabe.co.uk ___ 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] get method for Pd
Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( Colet Patrice - Mail original - De: Jonathan Wilkes jancs...@yahoo.com À: pd-list pd-list@iem.at Envoyé: Jeudi 17 Novembre 2011 02:43:08 Objet: [PD] get method for Pd I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ 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] get method for Pd
I think that belongs in the canvas get method: [; pd-mpatch.pd get etc.( -Jonathan - Original Message - From: Patrice Colet colet.patr...@free.fr To: Jonathan Wilkes jancs...@yahoo.com; pd-list pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:53 AM Subject: Re: [PD] get method for Pd Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( Colet Patrice - Mail original - De: Jonathan Wilkes jancs...@yahoo.com À: pd-list pd-list@iem.at Envoyé: Jeudi 17 Novembre 2011 02:43:08 Objet: [PD] get method for Pd I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ 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] get method for Pd
On Thu, 2011-11-17 at 14:53 +0100, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( How would pd know which canvas you mean? Wouldn't it make more sense to ask the canvas itself instead of pd? pd-canvasname is already listening for stuff... Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFZoACgkQkX2Xpv6ydvTOHACdHAv1vJ6oFWZ8tH/24CmFifgw L8IAn1cWwbKAr/z/4SCnRH2om1hQlI/Y =oZ03 -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:07, Jonathan Wilkes wrote: I think that belongs in the canvas get method: [; pd-mpatch.pd get etc.( what would that return if you have multiple instances of the mpatch abstraction? fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFloACgkQkX2Xpv6ydvSEIgCg3BLPyZ5GRgOOhowZSFL9fmwA nF4AnAxpNcUgl/NcUc6YVdpLHMWPLree =2aOa -END PGP SIGNATURE- 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] get method for Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 13:14, katja wrote: On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name which tcl-version is reported for pd -nogui? or rather, how are non-existing attributes reported? simply by not sending anything to the rcvname? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFwYACgkQkX2Xpv6ydvRALQCaAr2Ip+QmxMjww82a9kCN2++y wTgAnRLHYs8RTGY/rpmUvylFsiav33RN =JfxQ -END PGP SIGNATURE- 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] get method for Pd
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: I made a patch awhile back that added a get method to pd And considering the set method, which is now implicit like in [; pd dsp 1(, it would be nice to have: [; pd samplerate samplerate( Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, 2011-11-17 at 15:12 +0100, IOhannes m zmoelnig wrote: On 2011-11-17 15:07, Jonathan Wilkes wrote: I think that belongs in the canvas get method: [; pd-mpatch.pd get etc.( what would that return if you have multiple instances of the mpatch abstraction? I think the most natural behavior would be that all instances would respond in an un-orderer manner. If you want to request many instances separately, you'd have to use something like [namecanvas]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 9:12 AM Subject: Re: [PD] get method for Pd -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:07, Jonathan Wilkes wrote: I think that belongs in the canvas get method: [; pd-mpatch.pd get etc.( what would that return if you have multiple instances of the mpatch abstraction? Try it: http://sourceforge.net/tracker/index.php?func=detailaid=3308027group_id=55736atid=478072 It returns a result for each instance of the abstraction-- thus the user has the ability to query the set of all abstraction instances, as well as individual results for a particular canvas (the latter either using your [sendcanvas] or my [send2canvas] wrapper around get parent in the demo). There are some things I need to revise in that patch, but it should give a good starting point. -Jonathan fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFloACgkQkX2Xpv6ydvSEIgCg3BLPyZ5GRgOOhowZSFL9fmwA nF4AnAxpNcUgl/NcUc6YVdpLHMWPLree =2aOa -END PGP SIGNATURE- ___ 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] get method for Pd
- Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 3:33 AM Subject: Re: [PD] get method for Pd -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 02:43, Jonathan Wilkes wrote: I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [...] wouldn't it be easier to use a syntax like [get rcvname attribute( ? rather than [get attribute rcvname( i think sending the rcvname first will make the syntax more easily extendible. e.g. it would allow for [tryset rcvname attribute values...( and the like. I really want to avoid that syntax because while it may be the most flexible for the current Pd implementation (e.g., one without a list atom) it's clearest to have get followed directly by the thing being gotten. Maybe I can sidestep the issue by suggesting just to send the result back to the pd symbol by forwarding it using an added state method that does nothing: [loadbang] | [; pd get dsp( [r pd] | [route state] | [route dsp] | [set $1( | [0( Added benefit is that you can also state a message to pd using the state method, and all pd receivers will be notified. -Jonathan madf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ExsQACgkQkX2Xpv6ydvRm7gCcCY+tuCG95nwLHoOw7nm46zdl gEEAoI57wflBh6egv1Vh5WlQ3PVC3VGV =wHPp -END PGP SIGNATURE- ___ 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] get method for Pd
Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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] get method for Pd
I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 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] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Miller Puckette m...@ucsd.edu Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:01 PM Subject: Re: [PD] get method for Pd I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : Miller said object, so I'm assuming he meant [info] (though I don't think anyone else agreed that it would be the right approach). Benefit: * [info] would have a help patch, so it would be easier to document, plus avoid the confusion of the pd receive symbol with the [pd] canvas Benefit of [; pd info( * easier to code, plus it fits nicely with the extend implicit set methods katja mentioned -- [; pd dsp 1( etc. (i.e., using the currently existing methods to set attributes) Maybe others have benefit/drawback ideas? [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. I agree these should be separated. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). But there are other situation which seem to beg for the receive solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: [get linecount( | | [textfile -reference] | | |[textfile] V [15 (where 15 would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) cheers Miller On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 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] get method for Pd
Le 2011-11-17 à 08:43:00, bra...@subnet.at a écrit : maybe PID, if possible, would be great There's [gf/getpid]. http://gridflow.ca/help/gf/getpid-help.html __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
That's a great point, just an [info] object makes a lot of sense. [dsp( | [info] | [route dsp] | [1( Then there could also be [pd-gui], but unfortunately not [pd]. But about the [textfile] example, it seems to be that the second outlet could be used for general meta information. This is used in lots of other objects and it works quite nicely (see [hid], [comport], etc.) I suppose that would break backwards compatibilty tho... .hc On Nov 17, 2011, at 1:42 PM, Miller Puckette wrote: This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). But there are other situation which seem to beg for the receive solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: [get linecount( | | [textfile -reference] | | |[textfile] V [15 (where 15 would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) cheers Miller On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 Access to computers should be unlimited and total. - the hacker ethic 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] get method for Pd
oh...thank you yours sincerely :-) der.brandt Zitat von Mathieu Bouchard ma...@artengine.ca: Le 2011-11-17 à 08:43:00, bra...@subnet.at a écrit : maybe PID, if possible, would be great There's [gf/getpid]. http://gridflow.ca/help/gf/getpid-help.html __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit : which tcl-version is reported for pd -nogui? or rather, how are non-existing attributes reported? symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Le 2011-11-17 à 15:10:00, Mathieu Bouchard a écrit : Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit : which tcl-version is reported for pd -nogui? or rather, how are non-existing attributes reported? symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation. or, of course, any anything message, e.g. you could use : [route unavailable] or [route unknown] to pick up the thing that plays an error-message-like role (though as a normal message). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Say you'd have a [global] object, with a getter and / or setter for things like dsp, samplerate, version etc. Obviously, some things are gettable but not settable, like version or path/to/pd, and some things are not even gettable in certain circumstances, like IOhannes pointed out. The object would then give an error message which you can catch. For local info you'd have another object, for example [this] for the window, (like MaxMsp has [thispatcher]). Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
Hm, how about this: [info symbol] where symbol is pd for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui, or no args for this canvas the only inlet takes: get attribute to output an attribute value(s) message get to get a sequence of all attribute value(s) messages symbol receive-symbol to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :) -Jonathan - Original Message - From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Cc: pd-list@iem.at Sent: Thursday, November 17, 2011 3:11 PM Subject: Re: [PD] get method for Pd Le 2011-11-17 à 15:10:00, Mathieu Bouchard a écrit : Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit : which tcl-version is reported for pd -nogui? or rather, how are non-existing attributes reported? symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation. or, of course, any anything message, e.g. you could use : [route unavailable] or [route unknown] to pick up the thing that plays an error-message-like role (though as a normal message). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] get method for Pd
- Original Message - From: katja katjavet...@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 3:33 PM Subject: Re: [PD] get method for Pd Say you'd have a [global] object, with a getter and / or setter for things like dsp, samplerate, version etc.Obviously, some things are gettable but not settable, like version or path/to/pd, and some things are not even gettable in certain circumstances, like IOhannes pointed out. The object would then give an error message which you can catch. For local info you'd have another object, for example [this] for the window, (like MaxMsp has [thispatcher]). I think [thispatcher] would be analogous to [sendcanvas], or, a pointer to the head of a glist, which you can get with [pointer] and use its send-window method to send messages to it. My canvas get method patch makes it possible to get a pointer to the parent of a canvas, so you can essentially write your own sendcanvas abstraction. -Jonathan Katja ___ 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] get method for Pd
Would the device names and numbers from the Audio and MIDI settings be considered gettable Pd attributes? If so, that would be awesome. .mmb On Wed, Nov 16, 2011 at 8:43 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Mike Moser-Booth mmoserbo...@gmail.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, Nov 17, 2011 at 9:51 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I think [thispatcher] would be analogous to [sendcanvas], or, a pointer to the head of a glist, which you can get with [pointer] and use its send-window method to send messages to it. My canvas get method patch makes it possible to get a pointer to the parent of a canvas, so you can essentially write your own sendcanvas abstraction. True there's many externals for info purposes, but your patch makes it work via a modification of pd core code. I tried your patch file and demo. What a cool demo it is! This makes my day. (And I've not even seen half of it, because pd crashes at the 'edit demo-abstraction', that's maybe because I patched pd version test5.) Good thing you bumped this topic. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Mike Moser-Booth mmoserbo...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Thursday, November 17, 2011 4:34 PM Subject: Re: [PD] get method for Pd Would the device names and numbers from the Audio and MIDI settings be considered gettable Pd attributes? They certainly are. However-- like canvas coords-- what's the best format to get them in? If you separate them out into individual attribute value messages they may be much easier to read and figure out, but a single attribute value(s) message is easier to unpack/change/repack. Then again, a single attribute value(s) message with lots of cryptic numeric values is difficult to read-- just think about all the questions to the list about what all the args for an iemgui mean, or donecanvasdialog, etc... -Jonathan If so, that would be awesome. .mmb On Wed, Nov 16, 2011 at 8:43 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Mike Moser-Booth mmoserbo...@gmail.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. -Jonathan So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to receive it (I'm not even sure that's possible without making a self-editing patch). But there are other situation which seem to beg for the receive solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has. although it's migraine-inducing, the neatest solution would be to allow info style objects to have a right-hand outlet that you connect to, say, the textfile object like so: [get linecount( | | [textfile -reference] | | | [textfile] V [15 (where 15 would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful xeq object (first Pd convention, Graz.) cheers Miller On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: I like info too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so : [;pd info( would dump all the info to: [receive pd] | [route info] Then you could also specify specific things to request: [; pd info dsp( would dump: [receive pd] | [route info] | [route dsp] As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui]. .hc On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: Unfortunately I already used the name get for something else but I agree this should be an object, maybe 'get-info or even just info. It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally. cheers Miller On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 15:09, IOhannes m zmoelnig wrote: On 2011-11-17 14:53, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( now we are getting close to why i think using get rcvname ... is better than get verb rcvname but of course jonathan and roman are right when they say that this is not something you would ask pd about. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -END PGP SIGNATURE- ___ 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 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] get method for Pd
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. It sounds to me that this is unifying too many things. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas. As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages. One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done. .hc I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. It sounds to me that this is unifying too many things. It will never be the case in Pd that something-- anything-- is too unified. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas. As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages. Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used. One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done. Is there a way to standardize a get method? I mean, if some externals took float messages, and others took float NUMBER PRECISION messages, and yet another took float32 NUMBER, I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery. -Jonathan .hc I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, Nov 17, 2011 at 05:21:29AM -0800, Jonathan Wilkes wrote: - Original Message - From: Andy Farnell padawa...@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] get method for Pd How about [; pd get self rcv-name( Not sure I understand this one-- what comes out of [r rcv-name] here? -Jonathan Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear. I think what Andy means here is the actual text of the patch itself as you would find by looking at the .pd file in a text editor. e.g. #N canvas 218 94 842 634 10; #X obj 63 84 t a a; #X obj 63 241 spigot; #X obj 102 149 bang; #X obj 102 168 1; #X obj 223 149 route bang; #X obj 183 150 bang; ... Making 'self' a settable property would open up all kinds of lovely madness! Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, Nov 17, 2011 at 12:45:57PM -0800, Jonathan Wilkes wrote: Hm, how about this: [info symbol] where symbol is pd for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui, or no args for this canvas the only inlet takes: get attribute to output an attribute value(s) message get to get a sequence of all attribute value(s) messages symbol receive-symbol to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :) I think DesireData had a facility for receiving error messages back into the patch. While we are thinking about this type of thing, what about [info errors] or [info console] which outputs everything that goes to console or all errors generated by Pd? Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
- Original Message - From: Chris McCormick ch...@mccormick.cx To: Jonathan Wilkes jancs...@yahoo.com Cc: Andy Farnell padawa...@obiwannabe.co.uk; pd-list@iem.at pd-list@iem.at Sent: Thursday, November 17, 2011 8:38 PM Subject: Re: [PD] get method for Pd On Thu, Nov 17, 2011 at 05:21:29AM -0800, Jonathan Wilkes wrote: - Original Message - From: Andy Farnell padawa...@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] get method for Pd How about [; pd get self rcv-name( Not sure I understand this one-- what comes out of [r rcv-name] here? -Jonathan Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear. I think what Andy means here is the actual text of the patch itself as you would find by looking at the .pd file in a text editor. e.g. #N canvas 218 94 842 634 10; #X obj 63 84 t a a; #X obj 63 241 spigot; #X obj 102 149 bang; #X obj 102 168 1; #X obj 223 149 route bang; #X obj 183 150 bang; ... Making 'self' a settable property would open up all kinds of lovely madness! You can already do this if you know the file name of the patch. With my canvas get method, a patch can retrieve its own filename. In either case you can also save the a revised patch using [textfile]. -Jonathan Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. It sounds to me that this is unifying too many things. It will never be the case in Pd that something-- anything-- is too unified. The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas. As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages. Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used. One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done. Is there a way to standardize a get method? I mean, if some externals took float messages, and others took float NUMBER PRECISION messages, and yet another took float32 NUMBER, I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery. The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Nov 17, 2011, at 8:43 PM, Chris McCormick wrote: On Thu, Nov 17, 2011 at 12:45:57PM -0800, Jonathan Wilkes wrote: Hm, how about this: [info symbol] where symbol is pd for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui, or no args for this canvas the only inlet takes: get attribute to output an attribute value(s) message get to get a sequence of all attribute value(s) messages symbol receive-symbol to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :) I think DesireData had a facility for receiving error messages back into the patch. While we are thinking about this type of thing, what about [info errors] or [info console] which outputs everything that goes to console or all errors generated by Pd? This should really just be a standalone object, something like [stdout] and [stderr] with an outlet. .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] get method for Pd
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 9:17 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. It sounds to me that this is unifying too many things. It will never be the case in Pd that something-- anything-- is too unified. The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually. Oh, you mean all mashed together in a big nondescript list? Here again it's too bad that lists don't nest in Pd-- that way you could just get one list of many key/values. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas. As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages. Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used. One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done. Is there a way to standardize a get method? I mean, if some externals took float messages, and others took float NUMBER PRECISION messages, and yet another took float32 NUMBER, I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery. The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. But all the messages would follow the same syntax. Take [info] in tcl-- it doesn't have a particularly large help file. -Jonathan .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list
Re: [PD] get method for Pd
On Nov 17, 2011, at 9:58 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 9:17 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] get method for Pd On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoel...@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] get method for Pd T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. It sounds to me that this is unifying too many things. It will never be the case in Pd that something-- anything-- is too unified. The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually. Oh, you mean all mashed together in a big nondescript list? Here again it's too bad that lists don't nest in Pd-- that way you could just get one list of many key/values. No matter what the format of the list itself, having to set all of the possibilities at once makes it very hard to work with. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas. As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages. Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used. One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done. Is there a way to standardize a get method? I mean, if some externals took float messages, and others took float NUMBER PRECISION messages, and yet another took float32 NUMBER, I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery. The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task. But all the messages would follow the same syntax. Take [info] in tcl-- it doesn't have a particularly large help file. You think that ~2300 words is not particularly large for a help file? That's now long Tcl's info help is. I don't think
[PD] get method for Pd
I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
hi jonathan maybe PID, if possible, would be great yours sincerely der.brandt Zitat von Jonathan Wilkes jancs...@yahoo.com: I made a patch awhile back that added a get method to pd: [; pd get version rcv-name( sends version $major $minor $bugfix to rcv-name [; pd get dsp rcv-name( sends dsp $status to rcv-name [; pd get * rcv-name( sends a sequence of all query-able attribute values to rcv-name leaving off rcv-name will send the output to the Pd console [; pd get( is synonymous with [; pd get *( I remembered the patch when trying to generate crash logs for about.pd in the other thread-- if Pd has a get method then about.pd doesn't need to rely on externals (well, aside from pddplink for the links). Are there Pd attributes other than version and dsp status that would be nice to make gettable? -Jonathan ___ 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
