[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