[PD] jMax Phoenix

IOhannes m zmoelnig zmoelnig at iem.at
Thu Sep 23 09:20:01 CEST 2010


On 2010-09-22 20:04, Jonathan Wilkes wrote:
> 
> Yes, Max/MSP's [if] object has a more readable syntax.  Yet even 

i don't know max's [if], but i guess you could basically implement this
with an abstraction.

> 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.
> 

yes, but i believe this is because you are very used to C-like
languages, so you assume that expr's if looks like: "if <condition>,
<then>, <else>".
you have been trained on that, probably since high school (and
eventually used it before) [*]. if you had been fed on perl, you might
find other things more easily to read.


> I could put comments closer to each object chain, but then that's 
> even more objects.

so?

we all know that source-lines-of-code has nothing to do with raedability
nor complexity.
more objects doesn't mean that the code is better OR worse to read.

(though of course it might be preferrable that the code makes it clear
what is going on without having to resort to comments).

>> 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 think the main problems come from people trying to implement C-like
control flow in a dataflow language like Pd.
even my implementation was only trying to reproduce the algorithm you
wrote down, rather than trying to figure a Pd-way to implement pong.

you can make _very_ elegant super-readable control flow with the use of
[route] and friends.


> 
> 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).


if you find it difficult to patch 25 objects, then you should get
yourself accustomed to keyboard short-cuts.
if you need go to the menu->put->object for each of the 25 objects, then
i understand your concerns. with Ctrl-1 i don't see the problem with
patching 25 or 3 objects.


> 
> 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.

i hardly ever use [value].
i think it doesn't integrate so well into the patcher paradigm, thus
making you want to program C-like rather than Pd-like.

that's not to say that i never use [value], it surely has its merits.

> 
> 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.

btw, i'm not very interested in getting rid of all overlapping wires.
spaghetti code is probably something that is unreadable, but the odd
overlapping wire is something my brain has adapted to decyphering very well.

fgmasdr
IOhannes




[*] note that i went to highschool in austria around 1990; things might
have changed substantially since then.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100923/2f0ebb3e/attachment-0001.bin>


More information about the Pd-list mailing list