[PD-dev] list math

[Hans-Christoph Steiner]

On Feb 12, 2006, at 12:02 PM, cyrille henry wrote:

> hello Ben
>
> B. Bogart a écrit :
>> cyrille henry wrote:
>>> i don't fear redondancy.
>> Hi Cyrille,
>> Perhaps you don't but anyone who is learning PD should! Without
>> consitancy and a lack of redundancy learning PD becomes a much more
>> complex and confusing proposition.
>> Wherever possible objects with the same functionality should be  
>> unified.
> yes.
> i want to unified mapping objects together. and list objects together.
>
> i think mixing list object with mapping objects for a patch is  
> confusing. mapping object should be consistant, and one should not use  
> list object when he's looking for a mapping object.

I don't think this should be a problem at all and its quite common with  
many programming languages.  In C, libc doesn't have any math functions  
in it, they are in libm.  In Java, java.lang.* does not have any GUI  
classes at all, you have to use java.awt.* or javax.swing.*.

"mapping" should be a library like java.awt, and "math/list" also.

>> Otherwise things tend towards a state where the dominant (first  
>> written)
>> object gets priority in patches and in workshops. Then the users miss
>> the second object, that might be better, and then we end up with
>> different camps of users using different versions of "functionally"  
>> the
>> same object, and incompatible patches.
>> Its my personal opinion that one should never write an object that
>> overlaps more than 60% of the functionality of an already existing
>> object. One should "fix" the existing object to cover the 40% the new
>> object would allow.
>
> ok. so let's embeded a [list_clip 0 1] in the mapping_clip.
> what do you think?

[mapping/clip] object would just be a shortcut, which could also create  
confusion.  If someone imports "math/list" before "mapping", then  
[clip] would loose its defaults.  So I think that it would probably be  
a better idea to just use [math/list/clip] in the context of mapping.   
If we start making distinct math objects for the mapping lib, where  
will it stop?  Should we have [mapping/*], [mapping/cos], etc. etc.  
also?


>> If you really want to write your own redundant objects then please  
>> don't
>> bother releasing them. It just adds to the chaotic fuzz and it would
>> serve the community much better to integrate rather than "fork" even  
>> if
>> its hard and takes longer.
>
> i don't think it's chaotic to have all object need for mapping in a  
> mapping folder, and all object need for list processing in a list  
> folder...

This structure worked well when you had to work around Pd's lack of  
order.  But with Pd-extended, the aim is to have a clean, standard  
library mechanisms.  There is much work to be done, but its usable now.  
  And quite frankly, these days all Pd objects I write are organized to  
work in the structure of Pd-extended.  I see little or no reason to do  
otherwise.

We need to think of Pd as a common platform, not as just a collection  
of code you find from wherever, and assemble however into some  
cobbled-together thing that isn't the same as anyone else's install.

.hc

>
>
>> Just an opinion as a PD instructor.
> c
>
>> .b.
>>

________________________________________________________________________ 
____

            "The arc of history bends towards justice."
                                            - Dr. Martin Luther King, Jr.