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
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 jbturgid@hotmail.com wrote:
From: Andrew Faraday jbturgid@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
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
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 > 10000,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: matju@artengine.ca To: jancsika@yahoo.com CC: pd-list@iem.at; jbturgid@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
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 jbturgid@hotmail.com wrote:
From: Andrew Faraday jbturgid@hotmail.com Subject: RE: [PD] PD OOP? To: matju@artengine.ca, jancsika@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 > 10000,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: matju@artengine.ca To: jancsika@yahoo.com CC: pd-list@iem.at; jbturgid@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
Hi,
On 15 Dec 2010, at 00:53, Andrew Faraday wrote:
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.
Actually the original message didn't get through to the list because I accidentally posted from an unsubscribed account, so FWIW, here's the original email...
The attached '->' abstraction supports the following syntax:
[-> <object name> <receive name> <operator> <right operand>]
So you can do:
[-> osc~ pitch * 2]
or
[-> *~ foobar + 30]
Jamie
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 > 10000, 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: matju@artengine.ca To: jancsika@yahoo.com CC: pd-list@iem.at; jbturgid@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
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 global
- No control over abstraction (object) construction order and lifecycle
- 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
What exactly would "this" (#4) look like in Pd?
-Jonathan
--- On Wed, 12/15/10, brandon zeeb zeeb.brandon@gmail.com wrote:
From: brandon zeeb zeeb.brandon@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 "this"No 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
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 jancsika@yahoo.com wrote:
What exactly would "this" (#4) look like in Pd?
-Jonathan
--- On *Wed, 12/15/10, brandon zeeb zeeb.brandon@gmail.com* wrote:
From: brandon zeeb zeeb.brandon@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 global
- 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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.brandon@gmail.com wrote:
From: brandon zeeb zeeb.brandon@gmail.com Subject: Re: [PD] PD OOP? To: "Jonathan Wilkes" jancsika@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 jancsika@yahoo.com wrote:
What exactly would "this" (#4) look like in Pd?
-Jonathan
--- On Wed, 12/15/10, brandon zeeb zeeb.brandon@gmail.com wrote:
From: brandon zeeb zeeb.brandon@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 "this"No 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
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
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 zmoelnig@iem.atwrote:
On 2010-12-15 13:51, brandon zeeb wrote:
- 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
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
As for named variables, [rl] and [sl] are local.
-Jonathan
--- On Wed, 12/15/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@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
On Wed, 15 Dec 2010, IOhannes m zmoelnig wrote:
On 2010-12-15 13:51, brandon zeeb wrote:
- 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
Agreed. By "everything" I should have been more precise:
- tables
- ui elements
- values
- send/receive
- throw/catch
- I'm probably forgetting something...
All of the above are available globally within a given patch without some kind of namespacing (either with $0 or some eventual derivative thereof).
In a scalable Pd patch, this makes up most of the communication in a given patch. You are right, when something must be local, a patch cord is most appropriate.
Cheers, ~Brandon
On Wed, Dec 15, 2010 at 10:36 AM, Mathieu Bouchard matju@artengine.cawrote:
On Wed, 15 Dec 2010, IOhannes m zmoelnig wrote:
On 2010-12-15 13:51, brandon zeeb wrote:
- 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
On Wed, 15 Dec 2010, brandon zeeb wrote:
- No control over abstraction (object) construction order and
lifecycle
What's that ?
- 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.
- 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.
- 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...
- 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
#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
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.
- No control over abstraction (object) construction order and lifecycle
In a given abstraction you do NOT have control of the order in which your abstractions are created in memory. With my attempt at the Flyweight pattern for large lookup tables, it became apparent that if I were to remove an abstraction while editing a patch, I would have no idea if I removed the abstraction with reference to the real table or not. This is almost similar to prototypal inheritance where the instantiated object controls the resource, not the prototype. For example, a given UI on an Android phone widget will usually share graphic resources with others of it's type to save memory.
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 care more about Pd as a language and as a means to learn. For my purposes, using externals is pointless, although I do appreciate all the hard work.
#5. No interfaces or abstract abstractions (to control inlet patterns)
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.
With a bit of introspection, one could determine the name of the inlet, and thus autowire (dynamically patch) it to the correct binding (binding in my library, u_dispatch in RjDj). I work around this by enforcing a strict interface (as with RjDj) of two event inlets (hot and cold) where the cold inlet receives binding (dispatch) events. ~ objects just prepend signal inlets to the hot-side.
Please first give an example of a useful use of the FlyweightPattern.
Any given abstraction that requires a large lookup table obtains a reference (ie: the table name) of this large table without having to construct it by itself, it doesn't know how to create it, it just receives it... but every abstraction that requires this table receives the same one. This is much like a singleton. Otherwise it's a complete waste of resources.
- 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 :
That would be great. In my uses I don't really need a [unpack a a a], usually by the time I reach a [pack] I already have a strong enough determination of what types I'm working with (my binding/dispatch is type-agnostic though), but it would be nice.
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.
Basically, an abstraction (or object) is given what it needs to function by a 3rd party. The abstraction in question only focuses on it's given task and doesn't know how to create it's dependencies. For testability and reusability, this is a fantastic pattern. So far I've been using constructor IoC (in creation arguments), but one could just as easily pass this information as a list to an abstraction's inlet. Max's [poly] and RjDj's u_makepoly~ objects are a very simple example of this.
If you look at the structure of any given synthesizer voice in Pd, I'm sure you can think of other useful examples of this.
Cheers, ~Brandon
On Wed, Dec 15, 2010 at 10:23 AM, Mathieu Bouchard matju@artengine.cawrote:
On Wed, 15 Dec 2010, brandon zeeb wrote:
- No control over abstraction (object) construction order and lifecycle
What's that ?
- 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.
- 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.
- 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...
- 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
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
Sorry, gmail is hacking up the comment log. Comments are inline.
On Wed, Dec 15, 2010 at 11:52 AM, Mathieu Bouchard matju@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
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 ?
I'm simply attempting to avoid information overload,
Having to reinvent all that's outside of pd-vanilla is a more severe information overload.
my background is primarily in software development, not DSP.
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).
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.
and don't yet fully understand the theory behind it?
Have you recreated Pd's message-system yet ? What's the theory behind it ?
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.
That doesn't fit any definition of delegation that I can find. What makes you say that ?
1st definition : a kind of inheritance used in some OOP programming languages
2nd definition : a kind of forwarding of a message to another object. the message is normally sent as-is to the other object.
If I have a [metro], the outgoing message is not coming from anywhere at all. The only way it can be considered delegation is if the outlet is considered as an intermediate object. Conceptually, if you want to add this layer and really talk about delegation, it still doesn't prove that it's not lying inside of a bigger IoC pattern.
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 ?
In Java / Spring IoC psuedocode:
No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ?
Within Pd we can't achieve pure IoC since we can't construct abstractions by themselves and pass them into other abstractions.
Why can't we ?
Why don't you want to use outlet/inlet combinations for that purpose ?
Although, we can only pass along the name of the abstraction with it's creation arguments.
You can pass a patchcord to the object as a creation argument. That attribute is called an "outlet".
This rides a blurry line between Strategy and IoC patterns.
Design patterns have quite blurry lines themselves.
Is this making more sense?
It will need more discussion.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, Dec 15, 2010 at 6:49 PM, Mathieu Bouchard matju@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).
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.brandon@gmail.com wrote:
From: brandon zeeb zeeb.brandon@gmail.com Subject: Re: [PD] PD OOP? To: "Mathieu Bouchard" matju@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 matju@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).
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 jancsika@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.brandon@gmail.com* wrote:
From: brandon zeeb zeeb.brandon@gmail.com Subject: Re: [PD] PD OOP? To: "Mathieu Bouchard" matju@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 <matju@artengine.cahttp://mc/compose?to=matju@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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mathieu Bouchard wrote:
On Wed, 15 Dec 2010, brandon zeeb wrote:
- No control over abstraction (object) construction order and
lifecycle
What's that ?
- 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
- 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.
- 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...
- 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
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
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: matju@artengine.ca To: lsutton@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
-----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
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
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.
--- On Thu, 12/16/10, Chris McCormick chris@mccormick.cx wrote:
From: Chris McCormick chris@mccormick.cx Subject: Re: [PD] PD OOP? To: "Mathieu Bouchard" matju@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.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Dec 15, 2010 at 09:57:08PM -0800, Jonathan Wilkes wrote:
--- On Thu, 12/16/10, Chris McCormick chris@mccormick.cx wrote:
From: Chris McCormick chris@mccormick.cx Subject: Re: [PD] PD OOP? To: "Mathieu Bouchard" matju@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
- 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.
--- On Thu, 12/16/10, Chris McCormick chris@mccormick.cx wrote:
From: Chris McCormick chris@mccormick.cx Subject: Re: [PD] PD OOP? To: "Jonathan Wilkes" jancsika@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 chris@mccormick.cx
wrote:
From: Chris McCormick chris@mccormick.cx Subject: Re: [PD] PD OOP? To: "Mathieu Bouchard" matju@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
- 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.
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
On Fri, Dec 17, 2010 at 12:10:24PM -0500, Mathieu Bouchard wrote:
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,
I don't care about those things as much as I care about making a noise that makes people want to dance[1] and getting my patches running with the least effort on the most platforms.
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.
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 ?)
I don't know of a good way to quantify "how much are you compensating?" I guess I could be similarly ambiguous and say "somewhat". I am compensating somewhat.
As for "learn kludgy workarounds," I probably do that less in reality than I seem to do in your imagination.
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).
That is a lovely fantasy. It may become a reality, but the person to make it a reality would probably be me. I am not going to do that becuase I can already do most of what I want without investing in externals. If someone else, like Hans, does it and I can use those externals on all platforms where I run my patches without having to port them myself then I might start using them, although probably not because future platforms will be less likely to support those externals than pd-msp. This might sound terribly lazy and self serving to you, in which case you would be interpereting the situation correctly.
I have actually used externals before on one platform for a specific niche need. That made those patches less portable. So there you go. Externals are a tool I have made use of in the past. I am not religiously against the idea of externals in all situations.
If I want my code to be as portable as possible, I use fewer libraries.
If I want my patches to be as portable as possible, I use fewer externals.
What do you do to get [fiddle~] loaded, on a system on which you don't
have the dynamic loading support running ?
I don't remember. I think Peter Brinkmann wrote something about this on Android OS, so he's probably a better person to ask (he did all of the porting work).
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.
Heheh, you can say whatever you like but it does not change reality. My definition of annoying includes porting, compiling, and maintaining externals on obscure platforms. No amount of lengthy, philosophical pd-list emails will make that fun for me.
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.
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? I don't remember that. Please feel free to continue to care about whatever you like.
I must go now, because in exactly three hours I will stand in a field and use Pd to help people party[2].
Cheers,
Chris.
[1] http://sciencegirlrecords.com/chr15m/squeakyshoecore [2] http://www.rtrfm.com.au/dreamgirl/filesend/13390/SSS2010%20Web.jpg
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
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: matju@artengine.ca To: chris@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
On Sat, Dec 18, 2010 at 09:27:14AM +0000, 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.
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
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 matju@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
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
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.
...that is exactly what Nadia Boulanger taught Quincy Jones!
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
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
-
Andrew Faraday -
Andy Farnell -
brandon zeeb -
Chris McCormick -
Ed Kelly -
IOhannes m zmoelnig -
Jamie Bullock -
Jonathan Wilkes -
Lorenzo Sutton -
Mathieu Bouchard