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.