On Fri, 14 May 2010, William Brent wrote:
Thanks for looking. The multiple object library vs. single multi-function object question is a good one. Personally, it just seems more tidy to me this way,
What's more tidy about it ?
That said, I did combine a lot of math operators together in the [#] objectclass, such that +,-,*,/ and more, are just arguments to [#], like [# +], [# -], [# *], [# /]. however I also used separate classes for different things. The classification criteria were :
the basic computation should be the combination of one number with another number to give another number.
the input should be two grids, the output should be a grid of the same size as the left inlet's grid, and the basic computation will combine together the nth element of the left grid with the nth element of the right grid to produce the nth element of the output grid. (if the right-inlet grid is too small, then we loop through its data as many times as necessary)
Any other kind of computation is to be put in a different objectclass. Some of them also have an argument of the same kind as [#], such that you have [#fold +] vs [#fold *] vs [#fold &] and so on, while you also have [#draw_image +], [#draw_polygon +], [#outer +], and nearly all imaginable variations on it : if [# ^] exists and [#draw_polygon] takes any $1 that [#] can take, then [#draw_polygon ^] exists.
There is definitely something more Pd-ish about the multiple objects though.
It depends. functionality such as "sinesum" is built into Pd as a method instead of a class.
The fact is, a class-centric design is preferred for its ease of use, while a method-centric design is preferred for its ease of use, but it's not the same ease of use. There is no way to design things, that has all advantages at once.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801