[PD] PD OOP?

[Jonathan Wilkes]

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 at hotmail.com> wrote:

From: Andrew Faraday <jbturgid at hotmail.com>
Subject: RE: [PD] PD OOP?
To: matju at artengine.ca, jancsika at yahoo.com
Cc: pd-list at 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 at artengine.ca
> To: jancsika at yahoo.com
> CC: pd-list at iem.at; jbturgid at 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
 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101214/9d64aa10/attachment.htm>