I know Max has an [if] object that looks pretty much like your [if pitch... etc.] example below.
-Jonathan --- On Wed, 12/15/10, Andrew Faraday <jbtur...@hotmail.com> wrote: From: Andrew Faraday <jbtur...@hotmail.com> Subject: RE: [PD] PD OOP? To: ma...@artengine.ca, jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, December 15, 2010, 1:53 AM Hey There You might want to have a look at Jamie Bullock's abstraction based solution(which also went out on this list). Which was quite eloquent, if a little limiting at first. It's a little way back from the dream of dropping lines of OO code into pd but it's the kind of thing, when I find a syntax I like for this, could be useful to streamline some of my patching. I suppose what I'd really like is embedded ruby in pd, but that's either going to be a case of some serious modification (a bit beyond me now) or possibly shell scripts, something like [loadbang]|[irb, pitch = 440, *other variables*(|[shell] *number*|[pitch = $1{| [shell] [pitch * 2{|[shell]|[osc~] Although I suspect this may convolute issues more than solving them. Although in theory it might simplify some logic blocks... [if pitch > 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: ma...@artengine.ca > To: jancs...@yahoo.com > CC: pd-list@iem.at; jbtur...@hotmail.com > Subject: Re: [PD] PD OOP? > > On Mon, 13 Dec 2010, Jonathan Wilkes wrote: > > > Jmax Phoenix does this. If I recall correctly it breaks the nested list > > feature in Gridflow. > > Well, it's a bit more complicated. Back then, GridFlow's nested lists were > written using braces {}, but they weren't GridFlow's nested lists, they > were supported directly by jMax. I had to add the parentheses hack to > GridFlow so that I could port it to Pd. > > the (pitch * 2) feature of jMax does it with variables only (such as [v]) > (or constant-declarations, a jMax-only feature) and I think that this is > at creation time only, but I don't recall using it, anyway. > > for some reason that I don't remember, the * that is supposed to be a > multiplication only within parentheses, was also considered a > multiplication sign outside of parentheses, where it was considered to be > a syntax error instead of a symbol. This is why I decided to ditch jMax > completely and go for Pd as much as possible. (But ditching jMax was going > to happen not long after that anyway, as IRCAM cancelled the project, > deleted the mailing-list archives, etc.) > > > But considering your [osc~ (pitch * 2)] example-- what would happen if > > you change the value of pitch? The value of the [osc~] object's > > argument is assigned to be the initial frequency only when the object is > > created, so it doesn't seem like it would have an effect unless you > > recreate the object. > > It's not currently possible to know how to update it dynamically : the > creation arguments are only passed to creators (constructors), not > assigned in any explicit way to inlets or inlet/message combinations. The > first argument is not even consistently assigned to the second inlet. > > As an example, if I implemented such a feature in GridFlow, > > [# + (pitch * 2)] > > Pd would read it as : > > $1 = + > $2 = (pitch > $3 = * > $4 = 2) > > GridFlow would reparse it as : > > $1 = + > $2 = (pitch * 2) > > But at that point, something is lacking, to say that the second argument > is assigned to the second inlet, and that the first argument corresponds > to a method named "op" instead. > > _______________________________________________________________________ > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list