[PD-dev] list math

[B. Bogart]

Alas Cyrille it seems we agree rather than disagree.

I think having list stuff seperate from mapping stuff IS logical, and is
not redundant. sorry for misunderstanding.

I think a lister cliper should differ from a float clipper only in the
ways that they are different. If we have a patch with a float clipper,
we should be able to change it to the list clipper, and the upper/lower
limits should be interfaced the same way, so it still works, but would
allow you to sent it lists as well at that point.

What do we mean by "mapping" exactly?

If the difference between the list clipper and the float clipper is just
being able to use lists, should we just have one clipper that acts as it
should based on the type of data it gets? I guess in PD this is not the
way we have now, since [clip] and [clip~] are a case, which would argue
for paralell list_clip, mtx_clip, etc..

The problem of libs again becomes the problem of objects that belong
equally in multiple catagories. In eyesweb we have a giant tree of all
the objects. the hypothetical object "myobj" would be located in BOTH
these places:

/video/input/myobj

/input/video/myobj

which is pretty confusing rather than liberating...

Add to that you can drag and drop any object anywhere you want in the
stucture, and RENAME it to anything you want, and you have one of the
ugliest patcher languages I can think of.

The following scenario sounds ok to me:

User searches for "clip range" in the PD help searching tool, and we end
up getting a list like:

/math/clip
/signal/clip~
/math/list/clip
/mapping/clip

ok, I'm done.

b.

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.
>
>>
>> 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?
>
>
>
>> 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...
>
>
>>
>> Just an opinion as a PD instructor.
>
> c
>
>>
>> .b.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060213/16916606/attachment.pgp>