[GEM-dev] Re: Gem/src/Pixes pix_filmDarwin.cpp,1.18,1.18

chris clepper cgc at humboldtblvd.com
Fri Dec 12 18:52:51 CET 2003


At 9:19 AM -0500 12/12/03, B. Bogart wrote:
>What is the purpose of auto to start with? Is it supposed to make it easier
>to built patches that have playing video (rather than using a
>counter+metro). Is it supposed to only allow a looping facility? If its
>meant to make patching players easier then I think it should be fully
>implimented (see my film_looper GOP on pure-data.org for an example). This
>is the first thing students complain about when using video in Gem they
>expect messages like:
>
>stop
>play
>rate [x]

I had added 'play' and 'stop', but found that they were confusing 
when used with the existing auto functionality.  Having both the 
play/stop and auto going at once made it difficult to figure out how 
to handle states, like you could have 'auto 1' but hit stop and the 
film would then do what?  Stop because I hit stop or continue playing 
because 'auto 1' has set the object to grab a frame each render pass? 
One reason I do like 'auto' is that I can put a toggle on it and that 
will show the state of the object, but play/stop threw that out the 
window.

>even qtvr panning, track control, open url etc..

these are, of course, only possible with Apple's QT.

>something like the MAX QT object.

Frankly, i don't really care to model much of GEM off of any of the 
existing Max systems.  In particular, I want to avoid the kitchen 
sink Nato 242.film object that attempted to do some sort of 
half-assed editing, which is completely unwieldy and inappropriate in 
a Max type environment.  I will probably add the ability to select 
tracks in pix_filmDarwin in the near future as it will make loading 
and switching between files a lot easier by making a reference movie 
of all of the clips then loading just that into the pix_film object. 
That way the overhead of loading all the film data like counting all 
the frames will only happen once, and switching tracks on the fly 
should be very fast.  I've had a QTVR object on the list for ages, 
but again this will only work on OSX and Windows.  Opening a URL is 
actually very simple in QT, you just tell the object to open a movie 
in the URL rather than in the file path.  If you need to play 
something off the internet with the current pix_film then make a 
local reference movie of the clip using 'save as QuickTime movie' in 
the browser or QT player and load the reference .mov in GEM.  Works 
with streaming content as well.  Not to shabby for a a single QT API 
call?

>At this point I think its not valuable to nick-pick over "auto" when the
>real solution should be just to build a player right into the pix_* video
>objects, or keep the nessesity (as in older versions) to make your own
>player. (and drop "auto" altogether, its just not intuitive!)

I agree that the basic film object could be more fleshed out; 
however, we have to be careful that the functionality of the current 
object is somehow kept intact.  I don't think a lot of people would 
like it if suddenly 'auto 1' didn't work the same way as before or 
was no longer even a supported message.  I think we will have to make 
a decision to favor one system over the other in order to avoid any 
confusion about the internal states of the object like I illustrated 
above about auto vs play/stop.  So perhaps 'play' always overrides 
the auto state?  But what about direct frame access, does that 
supercede the play state?

We need better indications of the internal states of GEM objects 
there's no argument about that.  Too many objects have vaguely 
defined messages like 'auto' that don't give a clear enough picture 
about how they are to be used.  One of the nice things about using 
messages is that they can be self-documenting, so perhaps the GEM 
devs need to take better advantage of this.

>my opinion anyhow.

Always appreciated.  thanks.

cgc

>B.




More information about the GEM-dev mailing list