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