Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant.
2010/9/22 Bernardo Barros <[email protected]>: > 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 <[email protected]>: >> >> >> --- On Wed, 9/22/10, IOhannes m zmoelnig <[email protected]> wrote: >> >>> From: IOhannes m zmoelnig <[email protected]> >>> Subject: Re: [PD] jMax Phoenix >>> To: [email protected] >>> 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----- >>> >>> _______________________________________________ >>> [email protected] >>> mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
