Iterative loops are pretty easy with [until]. In certain circumstances recursive loops are not so difficult, either.
For me there are just certain types of conditional statements and chains of operators that are easier to do and read in expr rather than with several objects.
In the attached example, the comparison between the object chain with [random] and [expr random($f2, $f1)] isn't really fair, but even if expr's random function only took one argument, I still prefer [expr random($f1-$f2) + $f2].
Also, I just realized that if I want to really make "max" be the maximum I just have to insert "+1", whereas with [random] I have to disconnect some wires and connect a new object [+ 1] to the chain.
-Jonathan
--- On Wed, 9/22/10, Bernardo Barros bernardobarros2@gmail.com wrote:
From: Bernardo Barros bernardobarros2@gmail.com Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, "IOhannes m zmoelnig" zmoelnig@iem.at Date: Wednesday, September 22, 2010, 8:57 PM the only solution I see to write this kind of things in Max-like languages is to allow the user to just open a text-box and write what he/she wants in python or supercollider :-) that's for control structures, loops, etc
2010/9/22 Jonathan Wilkes jancsika@yahoo.com:
--- On Wed, 9/22/10, IOhannes m zmoelnig zmoelnig@iem.at
wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD] jMax Phoenix To: pd-list@iem.at Date: Wednesday, September 22, 2010, 6:36 PM On 2010-09-22 16:48, Jonathan Wilkes wrote:
expr if(bx<=20, if (py<=by &&
py+60>=by, 0, 1), -1);
if (bx>=415, 2, -1); if (by<=0, 4, if (by>=500, 5, -1))
honestly i find this hard to read as well, esp.
compared to
traditional C-like syntax:
if(bx<=20) if(py<=by && py+60>=by) return 0; else return 1; if(by>=415) return 2; else return -1; if(by<=0) return 4; else if (by>=500) return 5;
Yes, Max/MSP's [if] object has a more readable syntax.
Yet even
with the two nested "ifs" I find it easier to read
than your
implementation because I don't have to look up to the
inlet to
remind myself which list elements correspond to which
variable.
I could put comments closer to each object chain, but
then that's
even more objects.
and as a matter of fact, i don't think the pd-implementation of the algorithm is so bad.
Yes, IMO the way you implemented it is nice because
there are
very few wires crossing over objects.
I'd also mention I find it more difficult to patch
your
implementation because there are 25 objects (not
including the
number boxes), 16 of which correspond to the args of
[expr] in
my implementation. That's 16 objects for which I
have to change
modes between the mouse (for connections) and the
keyboard (for
text).
With [expr] I find it conceptually easier (and more
ergonomic) to
set up my [v] objects, my [sel], and my [outlet], then
code the
entire algorithm inside one box.
Btw- you can get rid of 3 overlapping wires if you put
[value py]
closest to [unpack 0 0 0] and cascade them that way.
-Jonathan
the only awkwardness in my implementation i find
is the
[*-1]->[moses 0] , which one could simply replace by [moses -1]
(supposed we
don't care about values between -1 and 0) (or with a [<=0]->[select 1] which i didn't do for conceptual reasons)
fgmasdr IOhannes
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Jonathan Wilkes