[PD-dev] [GEM] names

[zmoelnig at iem.at]

hi.

Zitiere chris clepper <cclepper at artic.edu>:
> Hi
> 
> I mentioned in the last post about a new GEM release that some of the 
> names of various objects don't really match what they do very well. 
> i think i've said on a few occasions that the name of the object 
> needs to tell the user what they do rather than be some excessively 
> cute, clever name from a book no one has read, Hindu deities  or 
> someone's cat (btw, all of these are used as names in other video 

right to some point, but otoh i really like objects like miller's [moses] that
divides the sea...
(but ok, i can use zexy for my personal naming schemes...)


> - pix_blur - this should be renamed pix_motionblur and pix_blur will 
> be an abstraction for a convolution based blur.
ok
> 
> - pix_buf - would it be better to rename this pix_separator to mirror 
> the separator object?  pix_buf can remain for compatibility.
[pix_buf] *has* to remain for compatibility. but [pix_separator] really should
be an alias.
btw. [pix_buf] can do some things that are not expected by a real separator
(like repeating the buffered image on demand (bang) or automatically)
(maybe no one knows of this)

> 
> - pix_depot - why not call it pix_buffer?  or pix_table or pix_array? 
because i couldn't come to a decision which one to take.
i would have taken [pix_table] if it wasn't for the [pix_write] object.
and [pix_tabwrite] ?

> something that is a common term for a chunk of memory filled with 
> data (frames of video in this case).  yes, a depot is a place to 
> store things but it's mainly used as a military term or in the name 
> of a large chain of hardware and office supply stores in the US (Home 
> Depot and Office Depot respectively).
ok, maybe i have a weird sense of humor

> 
> - pix_put/get - could be pix_buffer_write and pix_buffer_read.  these 
> seem a little more specific to me and the name-space extension allows 
> for direct association of functions with the pix_buffer object.
> 
> also i was thinking of making objects that performed various actions 
> on the buffer or used it in some way for processing.  also, this 
> could facilitate non-realtime renders. examples:
> 
> pix_buffer_average - averages the frames in the buffer and stores the 
> pix_buffer_record - dumps the contents of the buffer into a Quicktime 
yes of course.
but i was rather thinking of reading/writing to/from [pix_depot] (or whatever)
with messages sent to the object itself instead of separate objects.

> there are some other ones that are new to CVS that might need better
> names:
> 
> - pix_background - this removes the background from based on a static 
> image snapshot.  is there a more meaningful name that better 
> describes this?  pix_background_remove is a bit excessive i think.
well, [pix_buffer_read] is excessive too.

> 
> - pix_scanline - this does image decimation based on either repeating 
> or removing rows of pixels, so it does do scanline processing but is 
> that really clear?
i was already wondering what it was for, but had had no time to look.

actually we have one app under development that is already using [pix_depot] and
friends, but this can be changed easily.

mfg.asd.r
IOhannes



PS.
[pix_write]: although it has been in the CVS (or at least on my pc) for some
time there might still be lots of changes to this.
maybe adding support for writing movie-files instead of single-frames would be
easier to understand than having another object.

[pix_movie]/[pix_film]/[pix_video]:
the changes i proposed are not that big. it is mostly copy'n'paste the
os-specific stuff out of the pd-object-class into separate loader classes.
as daniel has mentioned he is writing on qt-support for windows, this is exactly
the time where such becomes handy.
under linux already several loader (child-)classes are used in one pd-object,
if the first fails to load the movie, the second tries to open it,...
so maybe this would be the right time for windows to make this step.
under macOS it might to be a number one prize, since i guess qt handles almost
everything at mac (can you open pdf's ?)