Re: [PD] PD OOP?
On Mon, 20 Dec 2010, Andy Farnell wrote: In spite of a relativist position the idea of a correct interpretation of creativity is destroyed. It would make the most hardened cognitive scientist take a step back and question deeply all they think they know. Turns out there are as many kinds of creativity as there are minds. That's what makes it creativity. Creativity, imagination and intelligence are some of those words that nobody really agrees on. They are clouds of impressions of hardly definable phenomena. I tend to avoid using those words like one would avoid Pandora's can of worms. OTOH they're often hard to avoid. But the word « simplicity » might be even more complex to deal with. (?) Is it just my impression, that a real hardened cognitive scientist would have already questioned all they think they know (or what anyone else thinks they know) before even getting to that book ? Artificial Intelligence's trickiest task was always to define what they mean by « Intelligence » in their field's title ;) ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Mon, 20 Dec 2010, Chris McCormick wrote: Ah, sorry for the confusion. I meant it to say that sometimes constraining yourself, as with following the rules for writing haiku, can help creativity. For some artists, there is nothing scarier than a page with no words on it, or a canvas with no paint (or objects) on it. If you start with some rules about what you are allowed to put on the canvas, this can paradoxically enhance your creativity. It's about making choices. Before an artwork is started, that artwork could be anything. Somehow the artist has to start with something in particular (can't go in all directions at once !). Elements that help define the artwork may additive (you put a box that suggests another box...) or subtractive (you state a rule that filters out some possibilities, or you set some kind of goal). Well, that's how I see it... at this moment. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
I've read a few good things about creativity. There's this one beautiful book I have on my shelf here. It's called The creative process, edited by Brewster Ghislen. It's a paperback that was 99p in a charity shop, published by Mentor. These kind of treasures are rare as pigs eggs. Get it if you see one. It's a collection of essays by Albert Einstein, Vincent van Gogh, Yasuo Kuniyoshi, Fredrich Nietzsche, Cal Jung, Mary Wigman, AE Housman, WB Yeats, Henry James, Henry Moore, Thomas Wolfe, DH Lawrence, Steven Spender Paul Valery, Samuel Coleridge, Max Ernst, Julian Levi, Christian Zervos, Harold Shapero, Roger Sessions, Henry Poincare, Rudyard Kipling, JH Preston, Dorothy Canfield, Katherine Anne Porter, Morton Prince, Herbert Spencer, RW Gerard. All kinds of weird and wonderful things are thrust into the discussion, issues like family and formative experience, faith, habitat and sleep, diet, motivation, social and cultural relationships... Emotions like joy, frustration, anger, love, and, as they reflect deeper structures of Selfhood, Angst, Kirkegaardian despair, Destiny. In spite of a relativist position the idea of a correct interpretation of creativity is destroyed. It would make the most hardened cognitive scientist take a step back and question deeply all they think they know. Turns out there are as many kinds of creativity as there are minds. That's what makes it creativity. a. On Mon, 20 Dec 2010 08:42:53 -0500 (EST) Mathieu Bouchard ma...@artengine.ca wrote: On Mon, 20 Dec 2010, Chris McCormick wrote: Ah, sorry for the confusion. I meant it to say that sometimes constraining yourself, as with following the rules for writing haiku, can help creativity. For some artists, there is nothing scarier than a page with no words on it, or a canvas with no paint (or objects) on it. If you start with some rules about what you are allowed to put on the canvas, this can paradoxically enhance your creativity. It's about making choices. Before an artwork is started, that artwork could be anything. Somehow the artist has to start with something in particular (can't go in all directions at once !). Elements that help define the artwork may additive (you put a box that suggests another box...) or subtractive (you state a rule that filters out some possibilities, or you set some kind of goal). Well, that's how I see it... at this moment. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -- 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] PD OOP?
On Sat, Dec 18, 2010 at 09:27:14AM +, Andrew Faraday wrote: I understand the haiku analogy is about code being short, eloquent and saying what needs to be said in relatively few words. Ah, sorry for the confusion. I meant it to say that sometimes constraining yourself, as with following the rules for writing haiku, can help creativity. For some artists, there is nothing scarier than a page with no words on it, or a canvas with no paint (or objects) on it. If you start with some rules about what you are allowed to put on the canvas, this can paradoxically enhance your creativity. Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
I understand the haiku analogy is about code being short, eloquent and saying what needs to be said in relatively few words. To be honest, programming is much like actual language in that it relies on layers and layers of abstraction before it can actually be deciphered. If you consider a simple word like 'walk', this represents a number of actions, putting one foot in front of the other, responding to obstacles you come in to and the rather complex process of standing upright. You can attach other words to it and say things like 'walk quickly north' these are arguments, and again, require an understanding of other things before you can interpret them as an instruction. This is largely the case with PD libraries (and other libraries, for that matter). Even the basic package is very far removed from the binary your computer actually 'understands'. It goes through the process of interpreting a text file for you to see the patch, returning that to a text file, moving through the code that represents pd, operating system etc. until it's just binary. So you're using a heck of a lot of other people's work using pd vanilla. do you understand how your OS works? Would you rather have one you can build yourself? You'd know how it works, then. Also if we're talking programming philosophy, I may as well write a 'programming haiku' Walk towards the seaStop walking when you get thereIt's too cold for that Date: Fri, 17 Dec 2010 23:01:41 -0500 From: ma...@artengine.ca To: ch...@mccormick.cx CC: pd-list@iem.at Subject: Re: [PD] PD OOP? On Sat, 18 Dec 2010, Chris McCormick wrote: On Fri, Dec 17, 2010 at 12:10:24PM -0500, Mathieu Bouchard wrote: expressing yourself at an appropriate level of understanding, but The appropriate level of understanding is the level at which people hear the noise and want to party. Is there any more important level? Of course not. I'm talking about the manner of patching for making the noises the way you want and keep it manageable, etc. I don't know of a good way to quantify how much are you compensating? I don't know either... As for learn kludgy workarounds, I probably do that less in reality than I seem to do in your imagination. I don't know. This might sound terribly lazy and self serving to you, Oh, being lazy and self serving is not necessarily a bad thing ! It's like writing a haiku. Haikus don't get any work done. Haha! Wow. The statement is technically correct. ;) (And I'm not even convinced that they _say_ anything either !) Maybe the problem isn't with the haikus. Maybe it's not a problem. (I didn't say it is.) And if you cared about getting patches to remain as small as they can be, you'd care a lot more about externals than you do. At which point did I say I cared about getting patches to remain as small as they can be? It's the it's like writing a haiku analogy that confused me. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, 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] PD OOP?
On Thu, 16 Dec 2010, Chris McCormick wrote: On Wed, Dec 15, 2010 at 09:57:08PM -0800, Jonathan Wilkes wrote: In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. Yep. In my experience, the cost-benefit balance usually falls on the side of restricting myself to not using many externals, What's the cost of getting used to restricting yourself in such a manner ? The effect on your problem-solving habits with pd... you'd have reasons of using externals, such as concision, completeness, correctness, expressing yourself at an appropriate level of understanding, but instead, you'd rather learn kludgy workarounds by heart until you don't have to think about them anymore ?... (though you can compensate for some of it using abstractions, but how much are you compensating ?) Why don't the handheld-pd-without-libdl crowd pick a set of most useful externals and compile them as part of vanilla, statically ? I mean only things that would be portable anyway : there are lots of useful things you can do as externals for pd, that don't require any libraries whatsoever (apart from a minimal libc). What do you do to get [fiddle~] loaded, on a system on which you don't have the dynamic loading support running ? I guess I view it in a different way. Pd-msp is a constrained software environment. I choose to match my patching style to those constraints so that I don't have to do more annoying and time-consuming work. If you wanted to avoid annoying and time-consuming work, you'd use externals. It's like writing a haiku. Haikus don't get any work done. (And I'm not even convinced that they _say_ anything either !) And if you cared about getting patches to remain as small as they can be, you'd care a lot more about externals than you do. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, Andrew Faraday wrote: * Perhaps it's not really OOP, Ruby is definitely OOP, but what you want is not OOP, it's Ruby itself. * It looks like there's a lot of debate going around, it was, largely a passing notion that started it. However I realize PD can do (probably) anything I would be likely to do with it using this embedded OOP (sorry if that is the wrong definition), it really was just Hmmm, I wonder if ruby lines could be used in-line in Pd Pd has already much support for what is called OOP, but what you want is the written syntax of Ruby, which is also OOP (and somewhat more so), but most of all, what distinguishes Ruby's syntax is that it's very concise for a lot of jobs. Ruby's syntax is most characteristically the result of designers optimising for conciseness. (Contrast this with Java, designed for people who have the impression that more verbosity means more solidness and/or more understandability) Ruby also has a damn lot of good libraries, just like Python and Perl do. Once again, amazed by the response. Perhaps someone will make this happen at some point. Perhaps I should, although I'll probably have to learn some C first. I recommend not using libruby, because if you can make libruby not crash as a pd module, you're some kind of genius. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Sat, 18 Dec 2010, Chris McCormick wrote: On Fri, Dec 17, 2010 at 12:10:24PM -0500, Mathieu Bouchard wrote: expressing yourself at an appropriate level of understanding, but The appropriate level of understanding is the level at which people hear the noise and want to party. Is there any more important level? Of course not. I'm talking about the manner of patching for making the noises the way you want and keep it manageable, etc. I don't know of a good way to quantify how much are you compensating? I don't know either... As for learn kludgy workarounds, I probably do that less in reality than I seem to do in your imagination. I don't know. This might sound terribly lazy and self serving to you, Oh, being lazy and self serving is not necessarily a bad thing ! It's like writing a haiku. Haikus don't get any work done. Haha! Wow. The statement is technically correct. ;) (And I'm not even convinced that they _say_ anything either !) Maybe the problem isn't with the haikus. Maybe it's not a problem. (I didn't say it is.) And if you cared about getting patches to remain as small as they can be, you'd care a lot more about externals than you do. At which point did I say I cared about getting patches to remain as small as they can be? It's the it's like writing a haiku analogy that confused me. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
--- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 8:32 AM On Wed, Dec 15, 2010 at 09:57:08PM -0800, Jonathan Wilkes wrote: --- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 5:40 AM On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. Yep. In my experience, the cost-benefit balance usually falls on the side of restricting myself to not using many externals, or hacking functionality back into abstractions, rather than trying to port externals to multiple platforms. You are welcome to spend your own time however you like. In the cases where a Vanilla hack is not possible, you are either forced to use an external, or you arbitrarily restrict yourself and shrug off the fact that there is no rational way to get features into Vanilla even if (everyone - 1) finds them useful/necessary. I guess I view it in a different way. Pd-msp is a constrained software environment. I choose to match my patching style to those constraints so that I don't have to do more annoying and time-consuming work. It's like writing a haiku. If you can't change the world, change yourself. Ommm. I am not sure that (everyone - 1) is fair. It is certainly not accurate. It is in the case of [initbang]. Everybody except Miller agrees that it would be a welcome addition to Vanilla. At least everything I've read on this list has been positive about [initbang], and confirmed the need for it to solve at least one specific issue which is creating variable inlets in an abstraction (as well as having other benefits). But it's not there, and it won't be there, so that's one issue that cannot be overcome by avoiding externals. (Or rather, avoiding a Pd-extended internal.) -Jonathan Of course you are quite welcome to do whatever you like and patch however you like, and even pretend that there are no good reasons for others to avoid externals. I will continue to optimise for my own laziness. :) Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010-12-16 00:55, Andrew Faraday wrote: I'm amazed just how much conversation this has caused, and I've only had a chance to skim-read all the replies that it's gained today so here's a couple of answers. * Perhaps it's not really OOP, my idea was, like most web development services, to have an 'in line' embed of ruby (or another language, I can learn) within a pd object. thus allowing conditional logic and/or mathematical expressions to be contained within the arguments for that object. python, lua? i seem to remember, that claude has done haskell as well... fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0KEnAACgkQkX2Xpv6ydvRdngCdHmFqchLpIXwhnXDtxhJemTlu dz0AnibKR26CaVWqEU8wV5wCdW3Av6H+ =4iRV -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: 1. Everything is global 2. No control over abstraction (object) construction order and lifecycle 3. No introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) 4. No concept of this 5. No interfaces or abstract abstractions (to control inlet patterns) 6. Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) 7. and on and on In most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon bypass~-help.pd Description: Binary data bypass~.pd Description: Binary data mute~-help.pd Description: Binary data mute~.pd Description: Binary data defined-help.pd Description: Binary data defined.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
What exactly would this (#4) look like in Pd? -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) No concept of thisNo interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) and on and onIn most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -Inline Attachment Follows- ___ 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] PD OOP?
Many options have been proposed over the years, my favorite thus far is [thiscanvas] http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes jancs...@yahoo.com wrote: What exactly would this (#4) look like in Pd? -Jonathan --- On *Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com* wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: 1. Everything is global 2. No control over abstraction (object) construction order and lifecycle 3. No introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) 4. No concept of this 5. No interfaces or abstract abstractions (to control inlet patterns) 6. Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) 7. and on and on In most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -Inline Attachment Follows- ___ Pd-list@iem.at http://mc/compose?to=pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On 2010-12-15 13:51, brandon zeeb wrote: 1. Everything is global hmm, i'd say the content of a message is as local as can be. mfsdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Well there is [sendcanvas] in iemguts. I'm not sure how related it is, but I sent Miller an idea (and maybe to this list) about adding a glist field to [struct] and having a subpatch that is a kind of template for that field. You could then define that structure as the template for an array field in another struct so that, for example, glists could be created and deleted simply by using [setsize]. Basically, think of a Put menu array, and each element is not just a float but also an abstraction instance with the y-value as the amplitude for an oscillator. -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 3:04 PM Many options have been proposed over the years, my favorite thus far is [thiscanvas] http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes jancs...@yahoo.com wrote: What exactly would this (#4) look like in Pd? -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) No concept of thisNo interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) and on and onIn most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
The point here refers to the common use of $0. This isn't necessarily a bad thing (and is actually helpful in most cases), but can make certain things a little more difficult with regards to true OOP. On Wed, Dec 15, 2010 at 9:14 AM, IOhannes m zmoelnig zmoel...@iem.atwrote: On 2010-12-15 13:51, brandon zeeb wrote: 1. Everything is global hmm, i'd say the content of a message is as local as can be. mfsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, Jonathan Wilkes wrote: What exactly would this (#4) look like in Pd? 1. Everything is global 4. No concept of this The use of the $0- prefix for receive-symbols ([r]) and variables ([v]). It's a hack. I made a similar hack for making OOP in Tcl, but at least, Tcl allows me a simple, natural syntax for introducing my own procedure definition procedure, which allows me to implement macros so that _($this:stuff) is written @stuff. That was with Tcl 8.4 ; In Tcl 8.6 there's finally a built-in object system, but I don't really remember what it looks like (I looked at it a bit in 2007, back when it was planned for Tcl 8.5). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On 2010-12-15 15:38, brandon zeeb wrote: The point here refers to the common use of $0. This isn't necessarily a bad thing (and is actually helpful in most cases), but can make certain things a little more difficult with regards to true OOP. the point i was trying to make is: people usually argue that variables in Pd are global (even if you prefix them with $0), while they are really talking about _named_ variables and ignoring that Pd has a concept of passing data without naming variables at all that is entirely local. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, brandon zeeb wrote:
2. No control over abstraction (object) construction order and
lifecycle
What's that ?
3. No introspection (although not required, very helpful, and don't tell me
it's in some external, I don't care!)
Why do you don't care about externals that might do the job ???
IMHO, directing your criticism at pd-vanilla alone is extremely
unproductive. You have to accept the fact that doing real work in Pd may
require a lot of externals. It's sad, but it's like that. I wouldn't use
Pd if it didn't have externals.
5. No interfaces or abstract abstractions (to control inlet patterns)
Strictly speaking, interfaces, or completely abstract classes, need only
be made explicit in languages that have strict method-lookup. In languages
like Python/Ruby/Perl/Tcl/ObjC/etc., all the lookup is at run time, and
likewise for PureData. In those languages, there is usually no built-in
way to declare interfaces, because the method-lookup wouldn't use those
declarations anyway.
Strict method-lookup normally means that anything-methods don't exist,
and that means that complicated workarounds have to be provided instead of
solutions that depend on anything-methods and loose method-lookup.
I would like to know what you mean by inlet patterns here.
6. Unfriendly and inconsistent type system (it is cumbersome in real
use, although I get over this by using [list])
I once proposed alternate versions of [unpack], [select], etc., that had
no type restrictions. There was a discussion on it. See :
http://www.mail-archive.com/pd-list@iem.at/msg08636.html
http://www.mail-archive.com/pd-list@iem.at/msg08644.html
but also the rest of the thread...
7. and on and on In most Pd patches, I see people using a few lookup
tables again and again (ie: mtof). As this is a complete waste of
memory,
[mtof] does not use a lookup-table :
t_float mtof(t_float f) {
if (f = -1500) return 0;
if (f 1499) return mtof(1499);
return 8.17579891564 * exp(.0577622650 * f);
}
void mtof_float(t_object *x, t_float f) {
outlet_float(x-ob_outlet, mtof(f));
}
one can attempt the Flyweight pattern.
Please first give an example of a useful use of the FlyweightPattern.
[bypass~ some_process~ 330 1 3 9]
Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that there
are several quite different manners of doing that in Pd, no ? But I have
trouble reading definitions and tutorials of IoC. I probably have used a
bunch of different IoC techniques in Pd and other languages already.
I mean that even simple patches without any abstractions would use
implicitly IoC in some manner.
Where [bypass~] expects it's 1st argument to be an abstraction and the
next 10 to be arguments to that abstraction.
If you used externals, you could make the number of arguments to be
variable and unlimited. You could also make it lookup the abstraction in
the parent's folder, so that I can put some_process~.pd in the same folder
as the main patch, for example.
Every patch which uses [bypass]~ must have 1 signal inlet and 1 event
inlet. Unfortunately, this interface can't be programmatically
enforced.
It's enforced at run time. There's also nothing wrong to having more than
2 inlets in this case, as long as you wouldn't be using the extra inlets
in that case anyway (or can do without them).
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, Andrew Faraday wrote: You might want to have a look at Jamie Bullock's abstraction based solution(which also went out on this list). Which was quite eloquent, if a little limiting at first. It's a little way back from the dream of dropping lines of OO code into pd but it's the kind of thing, when I find a syntax I like for this, could be useful to streamline some of my patching. I think that you are confusing OO concepts with something else. Just because you use Ruby doesn't mean you use the OO features of it (in a way that really distinguishes it from non-OO). Base OO concepts are Ruby's classes, Ruby's modules, Pd's abstractions, Ruby's self, Pd's $0, etc. I use the words OO and OOP not implying some kind of wholly-written programme in imperative fashion. I think that this is most appropriate than saying OOP is necessarily built-upon the concepts of structured programming, because the latter ignores all the languages that don't fit with plain structured programming while inspiring themselves a lot from OOP ideas. If you care about language categorisation and comparison, you do use the word OOP in a more generic way. volume = .05, The .05 syntax is a syntax error since Ruby 1.7 (many years ago). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, IOhannes m zmoelnig wrote: On 2010-12-15 13:51, brandon zeeb wrote: 1. Everything is global hmm, i'd say the content of a message is as local as can be. A patchcord by itself is also pretty local. Think of it as some kind of function-pointer (or rather, inlet-pointer). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Mathieu Bouchard wrote:
On Wed, 15 Dec 2010, brandon zeeb wrote:
2. No control over abstraction (object) construction order and
lifecycle
What's that ?
3. No introspection (although not required, very helpful, and don't
tell me it's in some external, I don't care!)
Why do you don't care about externals that might do the job ???
IMHO, directing your criticism at pd-vanilla alone is extremely
unproductive. You have to accept the fact that doing real work in Pd
may require a lot of externals. It's sad, but it's like that. I
wouldn't use Pd if it didn't have externals.
I agree on this.. but why you say is it sad? It means Pd is modular like
any sane programming 'environment'... You couldn't do much in a
programming language using it vanilla no? (well apart from assembler
maybe)... IMHO
5. No interfaces or abstract abstractions (to control inlet patterns)
Strictly speaking, interfaces, or completely abstract classes, need
only be made explicit in languages that have strict method-lookup. In
languages like Python/Ruby/Perl/Tcl/ObjC/etc., all the lookup is at
run time, and likewise for PureData. In those languages, there is
usually no built-in way to declare interfaces, because the
method-lookup wouldn't use those declarations anyway.
Strict method-lookup normally means that anything-methods don't
exist, and that means that complicated workarounds have to be provided
instead of solutions that depend on anything-methods and loose
method-lookup.
I would like to know what you mean by inlet patterns here.
6. Unfriendly and inconsistent type system (it is cumbersome in real
use, although I get over this by using [list])
I once proposed alternate versions of [unpack], [select], etc., that
had no type restrictions. There was a discussion on it. See :
http://www.mail-archive.com/pd-list@iem.at/msg08636.html
http://www.mail-archive.com/pd-list@iem.at/msg08644.html
but also the rest of the thread...
7. and on and on In most Pd patches, I see people using a few lookup
tables again and again (ie: mtof). As this is a complete waste of
memory,
[mtof] does not use a lookup-table :
t_float mtof(t_float f) {
if (f = -1500) return 0;
if (f 1499) return mtof(1499);
return 8.17579891564 * exp(.0577622650 * f);
}
void mtof_float(t_object *x, t_float f) {
outlet_float(x-ob_outlet, mtof(f));
}
one can attempt the Flyweight pattern.
Please first give an example of a useful use of the FlyweightPattern.
[bypass~ some_process~ 330 1 3 9]
Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that
there are several quite different manners of doing that in Pd, no ?
But I have trouble reading definitions and tutorials of IoC. I
probably have used a bunch of different IoC techniques in Pd and other
languages already.
I mean that even simple patches without any abstractions would use
implicitly IoC in some manner.
Where [bypass~] expects it's 1st argument to be an abstraction and
the next 10 to be arguments to that abstraction.
If you used externals, you could make the number of arguments to be
variable and unlimited. You could also make it lookup the abstraction
in the parent's folder, so that I can put some_process~.pd in the same
folder as the main patch, for example.
Every patch which uses [bypass]~ must have 1 signal inlet and 1 event
inlet. Unfortunately, this interface can't be programmatically
enforced.
It's enforced at run time. There's also nothing wrong to having more
than 2 inlets in this case, as long as you wouldn't be using the extra
inlets in that case anyway (or can do without them).
In the end though.. does it really make sense to compare Pd (and
dataflow in general) to paradigms of 'written' languages?
I mean I do see a point in having something like Python easily usable
within Pd (see my recent questions about Py), but this is dataflow, I
guess if people (like me) love to use it it's because for doing this
type of stuff - I won't say audio or I'll get flamed by Mathieu :) -
it's more fun than doing it in more 'traditional' languages like
C(sound) and similar.
Lorenzo
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, 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] PD OOP?
On Wed, 15 Dec 2010, brandon zeeb wrote: Say you compute a raised cosine window and store it in a table, this table is used within one instance of a granular table reading voice abstraction, 1-n of these abstractions are created at run time for polyphony. Now you have N instances of this table. Some people cache mtof in a table, and thus that was my original point. Oh ok. I couldn't imagine that people would cache mtof in a table. You can send reply-to $0-callback to [s mtof] and see whether your [r $0-callback] gets a bang. If it does, it's because there's a [r mtof] that sees that and has a [t b s]=[s] to send you back a bang. This thing is in an instance of the mtof-cache abstraction somewhere. If you don't get the reply, then you dynamically open the mtof-cache as a toplevel patch (so that the cache doesn't disappear when you close the patch that created it) and you auto-hide it using vis 0-[s $0-canvas] [namecanvas $0-canvas]. Does that sound good ? In a given abstraction you do NOT have control of the order in which your abstractions are created in memory. Yes you do. It's the implicit object numbering. You can renumber an object by deleting and undeleting it. Any new object is created at the end of the order, such that when you save the patch, it will be reloadable in that order. That said, it's considered bad practice to rely on this. People who need to rely on this may use dynamic patching instead. This is almost similar to prototypal inheritance where the instantiated object controls the resource, not the prototype. Uh, what do you mean here ? It doesn't match my knowledge of prototype inheritance (the SELF language). IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. Please use to indicate text that you are quoting from me. Normally, email programmes have at least an option for this, when it's not the default, or plain mandatory. I care more about Pd as a language and as a means to learn. For my purposes, using externals is pointless, I beg your pardon ??? Pd with a lot of externals is a language too ! although I do appreciate all the hard work. do you, really ? I would like to know which inlets of a given abstraction are signals and which are events for the purpose of dynamic patching / autowiring. Bonus points if inlet metadata is available. You could open the patch using [textfile], single out all [inlet] and [outlet], and sort them by $1 (x-position). But it doesn't work for non-abstractions (e.g. if I put lop~ as an argument to an abstraction...) With a bit of introspection, one could determine the name of the inlet, inlets shouldn't be named using their $1, because [inlet~] uses $1 for a wholly different purpose. Please first give an example of a useful use of the FlyweightPattern. Any given abstraction that requires a large lookup table Actually, I only said that because I didn't realise that you were talking about a lookup-table made of [mtof] values, and not just [mtof]. That would be great. In my uses I don't really need a [unpack a a a], In the end I called it [unpack e e e], because a means any message, and if we're to completely share the same abbreviations for that and [t], a means a message of any length with any selector (header), whereas the e that I introduced stood for either f or s or p, but not b nor l nor a, because e stands for what you can get by saying $1 or $2 for example (one argument at a time). Basically, an abstraction (or object) is given what it needs to function by a 3rd party. Ok, then connections are given to the abstractions in a kind of attribute that we call an outlet : wouldn't that be a form of IoC ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Sorry, gmail is hacking up the comment log. Comments are inline.
On Wed, Dec 15, 2010 at 11:52 AM, Mathieu Bouchard ma...@artengine.cawrote:
On Wed, 15 Dec 2010, brandon zeeb wrote:
Say you compute a raised cosine window and store it in a table, this
table is used within one instance of a granular table reading voice
abstraction, 1-n of these abstractions are created at run time for
polyphony. Now you have N instances of this table. Some people cache mtof
in a table, and thus that was my original point.
Oh ok. I couldn't imagine that people would cache mtof in a table.
You can send reply-to $0-callback to [s mtof] and see whether your [r
$0-callback] gets a bang. If it does, it's because there's a [r mtof] that
sees that and has a [t b s]=[s] to send you back a bang. This thing is in an
instance of the mtof-cache abstraction somewhere. If you don't get the
reply, then you dynamically open the mtof-cache as a toplevel patch (so that
the cache doesn't disappear when you close the patch that created it) and
you auto-hide it using vis 0-[s $0-canvas] [namecanvas $0-canvas].
Does that sound good ?
That's not a bad idea! Essentially attempting to delegate the creation of
the table.
In a given abstraction you do NOT have control of the order in which your
abstractions are created in memory.
Yes you do. It's the implicit object numbering. You can renumber an object
by deleting and undeleting it. Any new object is created at the end of the
order, such that when you save the patch, it will be reloadable in that
order.
That said, it's considered bad practice to rely on this. People who need to
rely on this may use dynamic patching instead.
Perhaps, but not if you're creating the objects by hand. As you say, it is
a bad practice.
I care more about Pd as a language and as a means to learn. For my
purposes, using externals is pointless,
I beg your pardon ???
Pd with a lot of externals is a language too !
although I do appreciate all the hard work.
do you, really ?
Why are people getting offended here? I'm simply attempting to avoid
information overload, my background is primarily in software development,
not DSP. I use Pd to help learn these basics, and I will use pd-extended
when I've mastered the basics. With that in mind, what's the point in using
a pre-baked filter if I haven't created my own and don't yet fully
understand the theory behind it? This says more about me than it does you
:)
Basically, an abstraction (or object) is given what it needs to function by
a 3rd party.
Ok, then connections are given to the abstractions in a kind of attribute
that we call an outlet : wouldn't that be a form of IoC ?
Nope, that would be delegation. A simple example would be this. Assume you
have an abstraction which uses [metro] to synchronize a particular process.
Now, if you wanted to synchronize with mates on the net using [netro],* you
would have to create a second abstraction*! Using IoC / Strategy, you
create your abstraction and pass a symbol referencing the metronome you want
to use. In Java / Spring IoC psuedocode:
class DoFunThings {
private ICounter counter;
private ISomeFunThing funThing;
public void setCounter(ICounter newCounter) {
* counter = newCounter;*
}
public void setSomeFunThing(ISomeFunThing thing) {
funThing = thing;
}
public void doIt(Intlet inlet1, Inlet inlet2) {
* int val = counter.next();*
funThing(val);
}
}
/// now let's build it
ICounter netCounter = new NetCounter(127.0.0.1);
DoFunThings myAbstraction = new DoFunThings();
myAbstraction.setCounter(netCounter);
//... this is boring
myAbstraction.setCounter(new LocalMetronome(100));
Within Pd we can't achieve pure IoC since we can't construct abstractions by
themselves and pass them into other abstractions. Although, we can only
pass along the name of the abstraction with it's creation arguments. This
rides a blurry line between Strategy and IoC patterns. Is this making more
sense?
Cheers,
--
Brandon Zeeb
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, Lorenzo Sutton wrote: I agree on this.. but why you say is it sad? It means Pd is modular like any sane programming 'environment'... You couldn't do much in a programming language using it vanilla no? (well apart from assembler maybe)... IMHO It's sad because many of the most basic building blocks have to be provided outside of pd-vanilla, for things that are normally considered built-in in most any other language. We could ignore pd-vanilla but so many of us don't, and so, pd-vanilla's contents is still the common basis to all of us, instead of something more complete. In the end though.. does it really make sense to compare Pd (and dataflow in general) to paradigms of 'written' languages? I introduced the word dataflow in the pd community SO THAT we compare pd to other programming languages. The word is not in opposition to 'written', as there are also plenty of dataflow languages that are 'written', and there are also several wholly different kinds of dataflow languages, of which pd/max is only one family. But why wouldn't it really make sense to do this comparison ? You don't even say that, as far as I can understand what you say. I mean I do see a point in having something like Python easily usable within Pd (see my recent questions about Py), but this is dataflow, I guess if people (like me) love to use it it's because for doing this type of stuff [...] it's more fun than doing it in more 'traditional' languages like C(sound) and similar. And what does that change about anything ? I don't see where you are going with that. I won't say audio or I'll get flamed by Mathieu :) So, according to you, is it a flame, to point out that people do whatever else using pd ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
I'm amazed just how much conversation this has caused, and I've only had a chance to skim-read all the replies that it's gained today so here's a couple of answers. * Perhaps it's not really OOP, my idea was, like most web development services, to have an 'in line' embed of ruby (or another language, I can learn) within a pd object. thus allowing conditional logic and/or mathematical expressions to be contained within the arguments for that object. * I realize that in terms of the end-product, PD can do most, if not all, operations most languages can, with the benefit of real-time operation and what is, certainly for newbies, a more readable data flow. * It looks like there's a lot of debate going around, it was, largely a passing notion that started it. However I realize PD can do (probably) anything I would be likely to do with it using this embedded OOP (sorry if that is the wrong definition), it really was just Hmmm, I wonder if ruby lines could be used in-line in Pd Once again, amazed by the response. Perhaps someone will make this happen at some point. Perhaps I should, although I'll probably have to learn some C first. Andrew Date: Wed, 15 Dec 2010 14:47:24 -0500 From: ma...@artengine.ca To: lsut...@libero.it CC: pd-list@iem.at Subject: Re: [PD] PD OOP? On Wed, 15 Dec 2010, Lorenzo Sutton wrote: I agree on this.. but why you say is it sad? It means Pd is modular like any sane programming 'environment'... You couldn't do much in a programming language using it vanilla no? (well apart from assembler maybe)... IMHO It's sad because many of the most basic building blocks have to be provided outside of pd-vanilla, for things that are normally considered built-in in most any other language. We could ignore pd-vanilla but so many of us don't, and so, pd-vanilla's contents is still the common basis to all of us, instead of something more complete. In the end though.. does it really make sense to compare Pd (and dataflow in general) to paradigms of 'written' languages? I introduced the word dataflow in the pd community SO THAT we compare pd to other programming languages. The word is not in opposition to 'written', as there are also plenty of dataflow languages that are 'written', and there are also several wholly different kinds of dataflow languages, of which pd/max is only one family. But why wouldn't it really make sense to do this comparison ? You don't even say that, as far as I can understand what you say. I mean I do see a point in having something like Python easily usable within Pd (see my recent questions about Py), but this is dataflow, I guess if people (like me) love to use it it's because for doing this type of stuff [...] it's more fun than doing it in more 'traditional' languages like C(sound) and similar. And what does that change about anything ? I don't see where you are going with that. I won't say audio or I'll get flamed by Mathieu :) So, according to you, is it a flame, to point out that people do whatever else using pd ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, 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] PD OOP?
As for named variables, [rl] and [sl] are local. -Jonathan --- On Wed, 12/15/10, IOhannes m zmoelnig zmoel...@iem.at wrote: From: IOhannes m zmoelnig zmoel...@iem.at Subject: Re: [PD] PD OOP? To: pd-list@iem.at Date: Wednesday, December 15, 2010, 4:19 PM On 2010-12-15 15:38, brandon zeeb wrote: The point here refers to the common use of $0. This isn't necessarily a bad thing (and is actually helpful in most cases), but can make certain things a little more difficult with regards to true OOP. the point i was trying to make is: people usually argue that variables in Pd are global (even if you prefix them with $0), while they are really talking about _named_ variables and ignoring that Pd has a concept of passing data without naming variables at all that is entirely local. fgmasdr IOhannes -Inline Attachment Follows- ___ 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] PD OOP?
On Wed, Dec 15, 2010 at 6:49 PM, Mathieu Bouchard ma...@artengine.cawrote: On Wed, 15 Dec 2010, brandon zeeb wrote: do you, really ? Why are people getting offended here? Am I getting offended ? How would you know, anyway ? Well, you're certainly argumentative :-/ Having to reinvent all that's outside of pd-vanilla is a more severe information overload. If your background is in software development, then you know that you should rely on libraries to get stuff done. I use Pd to help learn these basics, and I will use pd-extended when I've mastered the basics. But, as I said, many of what I consider to be basics are outside of pd-vanilla (while several things in pd-vanilla are rarely ever used by anyone). Relying on the pre-baked solution that is pd-extended doesn't make for a very rewarding learning experience. Yet, if I were being paid for this, I would definitely be making use of pd-extended because as you mentioned, my primary motivation would be getting stuff done. As a software developer, I'm keen on avoiding the reliance on superfluous dependency, and right now pd-extended is just that. With that in mind, what's the point in using a pre-baked filter if I haven't created my own It's so that you don't have to create your own. As I mentioned, I do want to create my own... to learn. Using IoC / Strategy, you create your abstraction and pass a symbol referencing the metronome you want to use. But you can also create the [metro] outside of the object, provided that you have an inlet in the abstraction that accepts the bangs, and zero, one or two outlets for connecting back to [metro] depending on needs. Isn't that IoC ? Yes, that would be a fine example when the payload is rather simple, and when tilde~ objects aren't involved (block delay!). Anything beyond 1 or two outlet/inlet pairs would probably be too cryptic for my uses, but the same would go for creation style IoC. In Java / Spring IoC psuedocode: No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ? Most Java classes used in Spring follow that example with setters for most dependencies. With regards to IoC, Spring is the agent that deals with creating objects, resolving setter and constructor dependency, and connecting them together. This is accomplished either through XML, annotations, or simple code (as in my example, where I'm instantiating the objects myself). -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Would you make use of the following if they were included in Pd vanilla? * symbol2list * initbang and closebang * a way to read a text file that's guaranteed to not generate a bad argument error -Jonathan --- On Thu, 12/16/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 1:45 AM On Wed, Dec 15, 2010 at 6:49 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Wed, 15 Dec 2010, brandon zeeb wrote: do you, really ? Why are people getting offended here? Am I getting offended ? How would you know, anyway ? Well, you're certainly argumentative :-/ Having to reinvent all that's outside of pd-vanilla is a more severe information overload. If your background is in software development, then you know that you should rely on libraries to get stuff done. I use Pd to help learn these basics, and I will use pd-extended when I've mastered the basics. But, as I said, many of what I consider to be basics are outside of pd-vanilla (while several things in pd-vanilla are rarely ever used by anyone). Relying on the pre-baked solution that is pd-extended doesn't make for a very rewarding learning experience. Yet, if I were being paid for this, I would definitely be making use of pd-extended because as you mentioned, my primary motivation would be getting stuff done. As a software developer, I'm keen on avoiding the reliance on superfluous dependency, and right now pd-extended is just that. With that in mind, what's the point in using a pre-baked filter if I haven't created my own It's so that you don't have to create your own. As I mentioned, I do want to create my own... to learn. Using IoC / Strategy, you create your abstraction and pass a symbol referencing the metronome you want to use. But you can also create the [metro] outside of the object, provided that you have an inlet in the abstraction that accepts the bangs, and zero, one or two outlets for connecting back to [metro] depending on needs. Isn't that IoC ? Yes, that would be a fine example when the payload is rather simple, and when tilde~ objects aren't involved (block delay!). Anything beyond 1 or two outlet/inlet pairs would probably be too cryptic for my uses, but the same would go for creation style IoC. In Java / Spring IoC psuedocode: No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ? Most Java classes used in Spring follow that example with setters for most dependencies. With regards to IoC, Spring is the agent that deals with creating objects, resolving setter and constructor dependency, and connecting them together. This is accomplished either through XML, annotations, or simple code (as in my example, where I'm instantiating the objects myself). -- Brandon Zeeb -Inline Attachment Follows- ___ 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] PD OOP?
Yes, I would, as they fill language gaps :) While we're at it, toss in the IEM stuff (soundfile_info, iemguts, etc). On Wed, Dec 15, 2010 at 8:09 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Would you make use of the following if they were included in Pd vanilla? * symbol2list * initbang and closebang * a way to read a text file that's guaranteed to not generate a bad argument error -Jonathan --- On *Thu, 12/16/10, brandon zeeb zeeb.bran...@gmail.com* wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 1:45 AM On Wed, Dec 15, 2010 at 6:49 PM, Mathieu Bouchard ma...@artengine.cahttp://mc/compose?to=ma...@artengine.ca wrote: On Wed, 15 Dec 2010, brandon zeeb wrote: do you, really ? Why are people getting offended here? Am I getting offended ? How would you know, anyway ? Well, you're certainly argumentative :-/ Having to reinvent all that's outside of pd-vanilla is a more severe information overload. If your background is in software development, then you know that you should rely on libraries to get stuff done. I use Pd to help learn these basics, and I will use pd-extended when I've mastered the basics. But, as I said, many of what I consider to be basics are outside of pd-vanilla (while several things in pd-vanilla are rarely ever used by anyone). Relying on the pre-baked solution that is pd-extended doesn't make for a very rewarding learning experience. Yet, if I were being paid for this, I would definitely be making use of pd-extended because as you mentioned, my primary motivation would be getting stuff done. As a software developer, I'm keen on avoiding the reliance on superfluous dependency, and right now pd-extended is just that. With that in mind, what's the point in using a pre-baked filter if I haven't created my own It's so that you don't have to create your own. As I mentioned, I do want to create my own... to learn. Using IoC / Strategy, you create your abstraction and pass a symbol referencing the metronome you want to use. But you can also create the [metro] outside of the object, provided that you have an inlet in the abstraction that accepts the bangs, and zero, one or two outlets for connecting back to [metro] depending on needs. Isn't that IoC ? Yes, that would be a fine example when the payload is rather simple, and when tilde~ objects aren't involved (block delay!). Anything beyond 1 or two outlet/inlet pairs would probably be too cryptic for my uses, but the same would go for creation style IoC. In Java / Spring IoC psuedocode: No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ? Most Java classes used in Spring follow that example with setters for most dependencies. With regards to IoC, Spring is the agent that deals with creating objects, resolving setter and constructor dependency, and connecting them together. This is accomplished either through XML, annotations, or simple code (as in my example, where I'm instantiating the objects myself). -- Brandon Zeeb -Inline Attachment Follows- ___ Pd-list@iem.at http://mc/compose?to=pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, 15 Dec 2010, brandon zeeb wrote: Well, you're certainly argumentative :-/ If that's a problem... then it's over. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. Salut, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
--- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 5:40 AM On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. In the cases where a Vanilla hack is not possible, you are either forced to use an external, or you arbitrarily restrict yourself and shrug off the fact that there is no rational way to get features into Vanilla even if (everyone - 1) finds them useful/necessary. -Jonathan Salut, Chris. --- http://mccormick.cx ___ 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] PD OOP?
On Wed, Dec 15, 2010 at 09:57:08PM -0800, Jonathan Wilkes wrote: --- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 5:40 AM On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. Yep. In my experience, the cost-benefit balance usually falls on the side of restricting myself to not using many externals, or hacking functionality back into abstractions, rather than trying to port externals to multiple platforms. You are welcome to spend your own time however you like. In the cases where a Vanilla hack is not possible, you are either forced to use an external, or you arbitrarily restrict yourself and shrug off the fact that there is no rational way to get features into Vanilla even if (everyone - 1) finds them useful/necessary. I guess I view it in a different way. Pd-msp is a constrained software environment. I choose to match my patching style to those constraints so that I don't have to do more annoying and time-consuming work. It's like writing a haiku. If you can't change the world, change yourself. Ommm. I am not sure that (everyone - 1) is fair. It is certainly not accurate. Of course you are quite welcome to do whatever you like and patch however you like, and even pretend that there are no good reasons for others to avoid externals. I will continue to optimise for my own laziness. :) Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Mon, 13 Dec 2010, Andrew Faraday wrote: I've had a bit of a daydream about a further development in PD. Could an expression be placed into the arguments of an object, or even a named receive become part of expr Written the way you wrote it, that would conflict with the means to access a global variable in [expr]. That's a [v], not a [r]. I suppose the dream would be to have something like [osc~ (pitch * 2)] That conflicts with the syntax used in GridFlow for nested lists. It would also conflict with the syntax of [expr] itself, I suppose (depends on details). Does anyone know of anything like this to streamline pd? Or am I just dreaming here? I like dreaming too, but I need the dreams to be consistent with what's already there and without conflicts. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
Jmax Phoenix does this. If I recall correctly it breaks the nested list
feature in Gridflow.
Well, it's a bit more complicated. Back then, GridFlow's nested lists were
written using braces {}, but they weren't GridFlow's nested lists, they
were supported directly by jMax. I had to add the parentheses hack to
GridFlow so that I could port it to Pd.
the (pitch * 2) feature of jMax does it with variables only (such as [v])
(or constant-declarations, a jMax-only feature) and I think that this is
at creation time only, but I don't recall using it, anyway.
for some reason that I don't remember, the * that is supposed to be a
multiplication only within parentheses, was also considered a
multiplication sign outside of parentheses, where it was considered to be
a syntax error instead of a symbol. This is why I decided to ditch jMax
completely and go for Pd as much as possible. (But ditching jMax was going
to happen not long after that anyway, as IRCAM cancelled the project,
deleted the mailing-list archives, etc.)
But considering your [osc~ (pitch * 2)] example-- what would happen if
you change the value of pitch? The value of the [osc~] object's
argument is assigned to be the initial frequency only when the object is
created, so it doesn't seem like it would have an effect unless you
recreate the object.
It's not currently possible to know how to update it dynamically : the
creation arguments are only passed to creators (constructors), not
assigned in any explicit way to inlets or inlet/message combinations. The
first argument is not even consistently assigned to the second inlet.
As an example, if I implemented such a feature in GridFlow,
[# + (pitch * 2)]
Pd would read it as :
$1 = +
$2 = (pitch
$3 = *
$4 = 2)
GridFlow would reparse it as :
$1 = +
$2 = (pitch * 2)
But at that point, something is lacking, to say that the second argument
is assigned to the second inlet, and that the first argument corresponds
to a method named op instead.
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Hey ThereYou might want to have a look at Jamie Bullock's abstraction based
solution(which also went out on this list). Which was quite eloquent, if a
little limiting at first. It's a little way back from the dream of dropping
lines of OO code into pd but it's the kind of thing, when I find a syntax I
like for this, could be useful to streamline some of my patching.
I suppose what I'd really like is embedded ruby in pd, but that's either going
to be a case of some serious modification (a bit beyond me now) or possibly
shell scripts, something like
[loadbang]|[irb, pitch = 440, *other variables*(|[shell]
*number*|[pitch = $1{| [shell]
[pitch * 2{|[shell]|[osc~]
Although I suspect this may convolute issues more than solving them. Although
in theory it might simplify some logic blocks...
[if pitch 1,volume = .05,elsif pitch 5000,volume = .1,else,volume =
.15,end(|[shell]
I'm really not sure if this is worth pursuing or not. It might lead to some
impressive results, especially if I could define some methods in a ruby file
and call them via shell, meaning I could write a parallel ruby library for a pd
project.
The main problem I can see would be requesting live feedback from ruby. Would
probably have to poll a whole lot of variables quite regularly for irb to deal
with it.
All casting about ideas here, guys, but any ideas or guidance might be helpful.
Cheers
Andrew
Date: Tue, 14 Dec 2010 15:08:14 -0500
From: ma...@artengine.ca
To: jancs...@yahoo.com
CC: pd-list@iem.at; jbtur...@hotmail.com
Subject: Re: [PD] PD OOP?
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
Jmax Phoenix does this. If I recall correctly it breaks the nested list
feature in Gridflow.
Well, it's a bit more complicated. Back then, GridFlow's nested lists were
written using braces {}, but they weren't GridFlow's nested lists, they
were supported directly by jMax. I had to add the parentheses hack to
GridFlow so that I could port it to Pd.
the (pitch * 2) feature of jMax does it with variables only (such as [v])
(or constant-declarations, a jMax-only feature) and I think that this is
at creation time only, but I don't recall using it, anyway.
for some reason that I don't remember, the * that is supposed to be a
multiplication only within parentheses, was also considered a
multiplication sign outside of parentheses, where it was considered to be
a syntax error instead of a symbol. This is why I decided to ditch jMax
completely and go for Pd as much as possible. (But ditching jMax was going
to happen not long after that anyway, as IRCAM cancelled the project,
deleted the mailing-list archives, etc.)
But considering your [osc~ (pitch * 2)] example-- what would happen if
you change the value of pitch? The value of the [osc~] object's
argument is assigned to be the initial frequency only when the object is
created, so it doesn't seem like it would have an effect unless you
recreate the object.
It's not currently possible to know how to update it dynamically : the
creation arguments are only passed to creators (constructors), not
assigned in any explicit way to inlets or inlet/message combinations. The
first argument is not even consistently assigned to the second inlet.
As an example, if I implemented such a feature in GridFlow,
[# + (pitch * 2)]
Pd would read it as :
$1 = +
$2 = (pitch
$3 = *
$4 = 2)
GridFlow would reparse it as :
$1 = +
$2 = (pitch * 2)
But at that point, something is lacking, to say that the second argument
is assigned to the second inlet, and that the first argument corresponds
to a method named op instead.
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
I know Max has an [if] object that looks pretty much like your [if pitch...
etc.] example below.
-Jonathan
--- On Wed, 12/15/10, Andrew Faraday jbtur...@hotmail.com wrote:
From: Andrew Faraday jbtur...@hotmail.com
Subject: RE: [PD] PD OOP?
To: ma...@artengine.ca, jancs...@yahoo.com
Cc: pd-list@iem.at
Date: Wednesday, December 15, 2010, 1:53 AM
Hey There
You might want to have a look at Jamie Bullock's abstraction based
solution(which also went out on this list). Which was quite eloquent, if a
little limiting at first. It's a little way back from the dream of dropping
lines of OO code into pd but it's the kind of thing, when I find a syntax I
like for this, could be useful to streamline some of my patching.
I suppose what I'd really like is embedded ruby in pd, but that's either going
to be a case of some serious modification (a bit beyond me now) or possibly
shell scripts, something like
[loadbang]|[irb, pitch = 440, *other variables*(|[shell]
*number*|[pitch = $1{| [shell]
[pitch * 2{|[shell]|[osc~]
Although I suspect this may convolute issues more than solving them. Although
in theory it might simplify some logic blocks...
[if pitch 1,volume = .05,elsif pitch 5000,volume = .1,else,volume =
.15,end(|[shell]
I'm really not sure if this is worth pursuing or not. It might lead to some
impressive results, especially if I could define some methods in a ruby file
and call them via shell, meaning I could write a parallel ruby library for a pd
project.
The main problem I can see would be requesting live feedback from ruby. Would
probably have to poll a whole lot of variables quite regularly for irb to deal
with it.
All casting about ideas here, guys, but any ideas or guidance might be helpful.
Cheers
Andrew
Date: Tue, 14 Dec 2010 15:08:14 -0500
From: ma...@artengine.ca
To: jancs...@yahoo.com
CC: pd-list@iem.at; jbtur...@hotmail.com
Subject: Re: [PD] PD OOP?
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
Jmax Phoenix does this. If I recall correctly it breaks the nested list
feature in Gridflow.
Well, it's a bit more complicated. Back then, GridFlow's nested lists were
written using braces {}, but they weren't GridFlow's nested lists, they
were supported directly by jMax. I had to add the parentheses hack to
GridFlow so that I could port it to Pd.
the (pitch * 2) feature of jMax does it with variables only (such as [v])
(or constant-declarations, a jMax-only feature) and I think that this is
at creation time only, but I don't recall using it, anyway.
for some reason that I don't remember, the * that is supposed to be a
multiplication only within parentheses, was also considered a
multiplication sign outside of parentheses, where it was considered to be
a syntax error instead of a symbol. This is why I decided to ditch jMax
completely and go for Pd as much as possible. (But ditching jMax was going
to happen not long after that anyway, as IRCAM cancelled the project,
deleted the mailing-list archives, etc.)
But considering your [osc~ (pitch * 2)] example-- what would happen if
you change the value of pitch? The value of the [osc~] object's
argument is assigned to be the initial frequency only when the object is
created, so it doesn't seem like it would have an effect unless you
recreate the object.
It's not currently possible to know how to update it dynamically : the
creation arguments are only passed to creators (constructors), not
assigned in any explicit way to inlets or inlet/message combinations. The
first argument is not even consistently assigned to the second inlet.
As an example, if I implemented such a feature in GridFlow,
[# + (pitch * 2)]
Pd would read it as :
$1 = +
$2 = (pitch
$3 = *
$4 = 2)
GridFlow would reparse it as :
$1 = +
$2 = (pitch * 2)
But at that point, something is lacking, to say that the second argument
is assigned to the second inlet, and that the first argument corresponds
to a method named op instead.
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
Jmax Phoenix does this. If I recall correctly it breaks the nested list feature in Gridflow. But considering your [osc~ (pitch * 2)] example-- what would happen if you change the value of pitch? The value of the [osc~] object's argument is assigned to be the initial frequency only when the object is created, so it doesn't seem like it would have an effect unless you recreate the object. (I'm curious what Jmax Phoenix does in this regard.) -Jonathan --- On Mon, 12/13/10, Andrew Faraday jbtur...@hotmail.com wrote: From: Andrew Faraday jbtur...@hotmail.com Subject: [PD] PD OOP? To: pd-list@iem.at Date: Monday, December 13, 2010, 10:34 PM Hey All I've had a bit of a daydream about a further development in PD. Could an expression be placed into the arguments of an object, or even a named receive become part of expr I suppose the dream would be to have something like [osc~ (pitch * 2)] instead of [r pitch] | [* 2] | [osc~] or even [expr pitch * 2] | [osc~] And other such space-saving arguments. Does anyone know of anything like this to streamline pd? Or am I just dreaming here? Cheers Andrew -Inline Attachment Follows- ___ 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
