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 systems). so here's a list of objects and suggested changes:
- pix_blur - this should be renamed pix_motionblur and pix_blur will be an abstraction for a convolution based blur.
- pix_buf - would it be better to rename this pix_separator to mirror the separator object? pix_buf can remain for compatibility.
- pix_depot - why not call it pix_buffer? or pix_table or pix_array? 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).
- 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 result as a single frame. useful for motion detection and compositing and pix_background type effects
pix_buffer_record - dumps the contents of the buffer into a Quicktime .mov and compresses them. could be useful in situations where the frames can be stored in the buffer but compression takes too much time to be done in real-time (like MPEG-2 or 4).
pix_buffer_motionblur - really high quality motion blurring requires lots of frames to be used and is generally not a real-time operation. if you've ever seen the shake motion blur you know about this.
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.
- 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 don't think any of the objects are really in wide-spread use except for pix_buf which can remain for compatibility purposes. maybe this is just a personal pet-peeve, and no one really cares what the objects are called as long as they work, but i thought i would make some suggestions and see what people think.
cgc
i agree strongly, consistant and logical naming is a great boon to usability. this matters to me right now becuase i've just this week started really digging into GEM (from CVS) for the first time and i've been doing some serious hed screatcing over a lot of the very names you mention. further, "fixing" this kind of stuff really needs to be done before the objects are in wide spread usage, like now :)
-josh
chris clepper wrote:
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 systems). so here's a list of objects and suggested changes:
- pix_blur - this should be renamed pix_motionblur and pix_blur will
be an abstraction for a convolution based blur.
- pix_buf - would it be better to rename this pix_separator to mirror
the separator object? pix_buf can remain for compatibility.
- pix_depot - why not call it pix_buffer? or pix_table or pix_array?
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).
- 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 result as a single frame. useful for motion detection and compositing and pix_background type effects
pix_buffer_record - dumps the contents of the buffer into a Quicktime .mov and compresses them. could be useful in situations where the frames can be stored in the buffer but compression takes too much time to be done in real-time (like MPEG-2 or 4).
pix_buffer_motionblur - really high quality motion blurring requires lots of frames to be used and is generally not a real-time operation. if you've ever seen the shake motion blur you know about this.
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.
- 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 don't think any of the objects are really in wide-spread use except for pix_buf which can remain for compatibility purposes. maybe this is just a personal pet-peeve, and no one really cares what the objects are called as long as they work, but i thought i would make some suggestions and see what people think.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
hi.
Zitiere chris clepper cclepper@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 ?)
With the rather messy name problems - it would be great to establish much more consistent naming than we have so far. In the short term we should certainly set up aliases for the old names... and then perhaps deprecate these - first with just a warning message and then perhaps with a catch-all deprecation error that doesn't actually instantiate the object but just prints the new name of the object. It's almost as confusing (in my opinion) to have multiple names lingering for a single object as it is to have misleading names in the first place...
Another idea - is it possible for a PD object to rename itself in the canvas? This may well be confusing in a different way but would provide patch-compatibility as well ensuring that objects are consistently (and singularly named). It also makes it very clear to the user that there's a new name for the object.
Daniel
----- Original Message ----- From: zmoelnig@iem.at To: "chris clepper" cclepper@artic.edu Cc: PD-dev@iem.kug.ac.at Sent: Wednesday, April 30, 2003 4:58 AM Subject: Re: [PD-dev] [GEM] names
hi.
Zitiere chris clepper cclepper@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 ?)
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
zmoelnig@iem.at wrote:
hi.
Zitiere chris clepper cclepper@artic.edu:
Hi
- 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] ?
- 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.
ok, because i have just came across it again, and i cannot remember a solution
[pix_buffer] : i think it would be a good name, but i really think it will be confused with [pix_buf] (not with [pix_separator] of course)
[pix_table] : this would probably be the best name (because of the [table] object). but (as i remember now) i was really thinking of a way to store images in real tables, which then should use [pix_tabread]/[pix_tabwrite] (that's why i am against it)
[pix_array] : maybe the only name that remains (but it is not so common again)
therefore i would vote for [pix_array], [pix_array_read], [pix_array_write].
but reading this, it seems like i was only arguing to prove that i was right.
therefore i would vote for [pix_buffer], [pix_buffer_read], [pix_buffer_write].
mfg.asd.r IOhannes
-
chris clepper -
Daniel Heckenberg -
IOhannes zmoelnig -
Josh Steiner -
zmoelnig＠iem.at