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

[ben at ekran.org]

> At 9:19 AM -0500 12/12/03, B. Bogart wrote:
> 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.

is the auto message from gem87 or 88? I've never used it until using gem
on OSX.

I do agree with this, but I think its the auto message that is causing
this problem rather than the play-pause/stop. It is nice to see the state
of the object indeed. What if there is a play message, all it does is tell
film to play or not (based on the gem timing) play 1 is playing play 0 is
stopped. This does not handle the original function of "auto" though,
which I think is more of a special case. I think it is reasonable to keep
auto as "auto start" or autostart that does nothing more than tell the
film player to start playing on load, "play 0" or "stop" would stop the
playback and it would not start again until a new clip is loaded.

"play 1" -> start playing (based on gem render timing)
"play 0" (or "stop") -> stop playing (stop on current frame)
"auto 1" (or autostart) -> when a new film is loaded start playing
"auto 0" -> do nothing but show the first frame when film loads.
"rate x" -> rate (maybe -1 for backwards, 0 for pause +1 forwards, +10 for
10 times faster, relative to render rate etc.)
"loop 1|2|3" -> looping, same as counter, 1 forward, 2 backward 3 pingpong
(this could make negative rate's confusing)

perhaps everything is in a "rate" method, "play 1" just calls "rate 1"
"play 0" calls "rate 0"

There are issues with this, but I'm just trying to point in another
direction.

for me, if I want control, I use a player. I use auto 1 for demo's and
quickies, for me auto would be best if it looped.

>>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?

I have no desire to immitate these things either. It served simply as an
example of functionality (softVNS2 uses a very similar scheme for playing
films.) the bottom line is this is how new users expect it to work, if its
an imitation or not. Track switching sounds very promising. Great hint
about quicktimeSDP files for receiving streams, I did not know this
worked!

>>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?

somtimes one has to break old patches for the better future. going from
680x0 to PPC was a big jump for apple, but it had to be done. I don't
think we should keep old functionality if we *agree* that it did not make
sense in the first place. I think direct frame access should just stop the
movie playing and not resume until play is hit again.

> 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.

I'm not so happy that I need to use "mode 0" to get pix_texture to act
right with some geos! Yes I think self-documenting is very important, as
in autostart. some verbosity here is probably worth it.

B.

>>my opinion anyhow.
>
> Always appreciated.  thanks.
>
> cgc
>
>>B.