[PD] Re: [PD-dev] Re: [GEM] pix_blur ???? which Gem-objects do we need (have) ?

Thomas Loop thomas.loop at unibas.ch
Thu Feb 20 09:47:01 CET 2003


Hi list,

Chris Clepper asked for user comments, so here we go... 
In my opinion this goes along the lines of the recent thread on pd useability. 
I'm a pd/Gem user with a small background in computer science and 
I fully agree with Chris' view on this subject. 

Basically Gem should provide both ways of thinking.
The high-level, specialized object displaying its "user-world" function in the 
name (like pix_blur) and the low-level, generic object (like pix_convolve).

This way everybody can use the software in the way they like. 
If you have a degree in computer science you can laugh at pix_blur and develop
your own kernels with pix_convolve. And if you don't care or know about theory 
you can jump right in and blur your images using pix_blur. 
Try to find a balance between minimalism and code-bloat.

I think pd lies right on the border between being a programming 
language and being an abstracted, interface-driven software.
It should support people coming from both worlds.

Sometimes developers tend to be a bit ignorant on the needs 
of the less coding-literate users of their software. This is a problem 
with the open source world in general. As somebody who tries to accomplish 
a certain task with the software, one sometimes can get the feeling it is 
being developed just for the sake of coding and not for being used.

Please do not be offended by this view. I'm very thankful for the great 
software the pd dev community is giving us and I think it has come a long way.

A growing user-base does not mean that you suddenly have to switch 
everything to a modeless, wizard-driven software with a one-mouseclick installer. 
Still, it sometimes can be healthy to take the view of a "normal" user 
that can't read code (this should be the majority) and just wants to produce music or visuals.

All the best and thanks for your efforts,

Thomas.



*********** REPLY SEPARATOR  ***********

On 19.02.2003 at 20:22 chris clepper wrote:

>>Hi list, hi chris.
>>
>>Maybe a stupid question:
>>What is this [pix_blur] for ?
>>Hey, i don't want to be rude (mr. bad guy again....), but there 
>>already is a thing like [tv_biquad] that does very similar things 
>>(and more)
>>
>>I think, Gem should follow pd's (vs. other libraries) object-policy:
>>make a minimum orthogonal object-set, that let's you do "everything" you
>want.
>>This implies, that there shouldn't be 2 objects, that do basically 
>>the same thing.
>>basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is 
>>a two-stage feedback-filter.
>
>>I do see the point, that a 1-stage filter needs less CPU-power than 
>>a 2-stage filter.
>
>well you sort of answered your own question, but here's the breakdown:
>
>- pix_blur is faster, more direct and perhaps easier to use if you 
>just want to blur something
>- tv_biquad is slower and may be harder to use depending on your 
>understanding of filters
>
>
>>btw. [tv_*] was meant to "work (only) on series of images", while 
>>[pix_*] should work on single images as well. thus [pix_blur] should 
>>rather be [tv_blur] (but never mind)
>
>this is not stated anywhere, and this is the first info on tv_* that 
>i have seen.  i have ignored them until now, especially after the too 
>long yuv vs pix debate, where 'everything should be pix_' was the 
>result.
>
>>And I would like to have more control over the filter-paramters: i 
>>prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", 
>>especially, when clipping is involved.
>
>that's a good suggestion.  both can be used  for [pix_blur] with only 
>a small change to the code.
>
>>Ah, that leads to what i wanted to ask/state anyhow:
>>Is it possible to make objects that perform "scientific tasks" (like 
>>convolution) rather than "folkloristic FX" (like smoothing)
>>[pix_convolution] is far more powerful than [pix_smooth] could be.
>>And of course, you can build a [pix_smooth]-abstraction with
>[pix_convolution]
>>Maybe a bit of a thought before doing a "quick hack" could save 
>>programming-time in the long term. (ooh, this sounds really like mr. 
>>bad-guy. i don't want to insult anybody)
>>
>>i do think, that pd is a programming language (with a lot of flaws 
>>(in terms of a prog-lang), sure)
>>i do think, that Gem should be a language-extension, rather than a 
>>set of cool effects.
>>That's why i thought it a good idea, to make this openGL-wrapping 
>>stuff (which is surely harder to use than all those ready-made Geos)
>
>ok this is a HUGE difference in our approaches.  i would never assume 
>that anyone using GEM would know how to program a convolution kernel 
>or openGL, and that shouldn't prevent them from using these things. 
>i actually intend on making [pix_edgedetect] and [pix_sharpen] at 
>some point because those are process that people like to do on 
>images, whether or not they even know that they are just variations 
>on the same mathematical formula.
>
>this goes back to the reason i even got involved with GEM in the 
>first place, which was to help  make a high-performance Mac OSX 
>version of the software for ARTISTS to use.  that means 'ready-made' 
>tools need to be available, most of these tools GEM lacks at the 
>moment.  you might consider something like photoshop's sharpen/blur 
>to be 'folkloristic', but this is how these processes are referred to 
>in common practice.  i don't see any reason why both the lower level 
>[pix_convolve] can't exist alongside the more abstracted 
>[pix_sharpen/blur] objects.  if anything the latter is more direct 
>and understandable to the larger number of users.  the abstractions 
>are one way to go but the higher level objects C code can be 
>optimized for each specific kernel.
>
>>any comments ?
>
>always...
>
>but i really really really would like to hear what users of GEM and 
>people interested in GEM have to say about things like this.
>
>cgc
>
>>
>>mfg.as.dr
>>IOhannes
>
>
>_______________________________________________
>PD-dev mailing list
>PD-dev at iem.kug.ac.at
>http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev







More information about the Pd-list mailing list