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