[PD] PD OOP?

[Jamie Bullock]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ->.pd
Type: application/octet-stream
Size: 179 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/562e376a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test->.pd
Type: application/octet-stream
Size: 244 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/562e376a/attachment-0001.obj>
-------------- next part --------------




> 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
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list