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

zmoelnig at iem.at zmoelnig at iem.at
Fri Dec 12 19:20:34 CET 2003


Zitiere "B. Bogart" <ben at ekran.org>:

> Hey all,
> 
> is "auto 1" supposed to make the video loop, or play through once? I
> remeber
> when teaching a workshop that the video only played once, but this was
> an
> old beta.

this is not only beta, this is the behviour of "auto" (as i see it):
auto is for playback of a movie with no external counter required: this is
especially important, as counters that are triggered via a metro will most
probably not play back smoothly; instead one should derive the trigger from the
gem-list itself

furthermore it should be aware of stereo-rendering (but this is not yet implemented)

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

i don't think that i (personally) want the looping facility within the [pix_film]


> is the first thing students complain about when using video in Gem
> they expect messages like:
> 
> stop
> play
> rate [x]

but you could really use 
[auto 0( for "stop"
[auto 1( for "play" (at normal speed)
[auto x( for "rate"

> 
> perhaps:
> in
> out
> loop [type]

the whole thing is:
should we make a complete movie-player-object for Gem ?
or should it be possible to build a complete movie-player with Gem ?

as stated before, i rather favour RISC-architecture (since that is, what i
believe that pd is)

the only reason to implement as much features into an object, that could be
easily build with pd itself is effectivity.
if speed is not affected, i see no reason to do it as an external object instead
of an abstraction.


which brings us back to the long-discussed, approved and never done
"abstractions"-folder


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

"open url" is partly possible under linux.
"track control" is theoretically taken into account (at least in the code that i
have written), but only the generic parts are implemented (and to be honest: i
don't how to make a multitrack video for testing)



> 
> something like the MAX QT object.
> 
> 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.
see above.

> (and drop "auto" altogether, its just not intuitive!)

it looked to me quite intuitive, when i did it.
now i am used to it.
but you might be right.

> 
> my opinion anyhow.
> 

mfg.a.dr
IOhannes




More information about the GEM-dev mailing list