[PD] jMax Phoenix

[Bernardo Barros]

Well maybe there is a Python object? If it has a neat and clean
implementations would be brilliant.

2010/9/22 Bernardo Barros <bernardobarros2 at gmail.com>:
> 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 at yahoo.com>:
>>
>>
>> --- On Wed, 9/22/10, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>>
>>> From: IOhannes m zmoelnig <zmoelnig at iem.at>
>>> Subject: Re: [PD] jMax Phoenix
>>> To: pd-list at 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 at iem.at
>>> mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>