Hi,
I think it is very good that this question popped up.
I am trying to sketch the advantages and disadvantages of the different approaches as I see them:
1) Usability and high level objects:
Pro: - user has a single object that does what he wants, using an intuitive name - can be optimized for speed, because its less general
Cons: - confuses the user by adding yet another object to the list of objects that have to be learned. - not as flexible for experimental uses - code duplication (yet another convolution kernel) - building a consistent set of high level object needs organization
2) Building higher level abstractions:
Pro: - usability, name corresponds to function (same as with dedicated external) - allows for a more consistent hierarchy when patching (e.g. general low level objects are externals, abstractions are more specified objects programmed in pd itself). - code base is kept small --> easier to debug/maintain/optimize
Cons: - loss in performance (how much ?) - building a consistent set of high level object needs organization
I think the key question is really the loss in performance. This said, I think we should make a folder within GEM for GEM abstractions, and based on the performance issue decide if a new object will be an abstraction or a dedicated external.
For the special case of "blur", I would have been happier if the pix_convolve object gets optimized, and pix_blur built as an abstraction.
The tv_ objects problem: It would be great if we could come up with a way in GEM to store images and do recursion, in order to implement these effects directly as a patch. Can this be done without loosing too much performance ? I think yes.
Greetings,
Guenter