cclepper@users.sourceforge.net wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1:/tmp/cvs-serv9968
Modified Files: pix_filmDarwin.cpp Log Message: rewrite to make playback using 'auto' more efficient. 'rate' message sets the playback speed when using 'auto' mode. the movie rate is properly set for correct qt playback.
hi. i have already implemented something similar under linux, but of course, differently. i am simply using the argument to "auto" as the framerate. so with "auto 0", no auto-playback is used, with "auto 1", we have normal speed playback. with "auto 0.5", we have half-speed playback.
is this confusing to the user ?
mfg.as.dr IOhannes
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.
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]
perhaps: in out loop [type]
even qtvr panning, track control, open url etc..
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. (and drop "auto" altogether, its just not intuitive!)
my opinion anyhow.
B. ----- Original Message ----- From: "IOhannes zmoelnig" zmoelnig@iem.kug.ac.at To: cclepper@users.sourceforge.net Cc: GEM-dev@iem.at Sent: Thursday, December 11, 2003 6:30 AM Subject: [GEM-dev] Re: Gem/src/Pixes pix_filmDarwin.cpp,1.18,1.18
cclepper@users.sourceforge.net wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1:/tmp/cvs-serv9968
Modified Files: pix_filmDarwin.cpp Log Message: rewrite to make playback using 'auto' more efficient. 'rate' message
sets the playback speed when using 'auto' mode.
the movie rate is properly set for correct qt playback.
hi. i have already implemented something similar under linux, but of course, differently. i am simply using the argument to "auto" as the framerate. so with "auto 0", no auto-playback is used, with "auto 1", we have normal speed playback. with "auto 0.5", we have half-speed playback.
is this confusing to the user ?
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
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.
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.
Zitiere "B. Bogart" ben@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
On Friday, December 12, 2003, at 01:20 PM, zmoelnig@iem.at wrote:
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]
...I'm against a start/stop functionality: I like the idea of [auto 1< with a toggle control, and I'd also support the ability to speed it up via an argument...but I thought that the point of auto was to allow the film to play back at whatever framerate you'd set the gemwin?
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 ?
...edit...
which brings us back to the long-discussed, approved and never done "abstractions"-folder
...I really think we need this! We already have the objects: I think something like ben's abstractions are probably a good place to start...A good set of abstractions will go a looong way toward improving the newbie's learning curve...
l8r, jamie
On Friday, December 12, 2003, at 01:20 PM, zmoelnig@iem.at wrote:
...I'm against a start/stop functionality: I like the idea of [auto 1< with a toggle control, and I'd also support the ability to speed it up via an argument...but I thought that the point of auto was to allow the film to play back at whatever framerate you'd set the gemwin?
Why against start/stop? (play 1|0) I think it would be great to not reply on external counters to do most playing stuff. a rate message tied (perhaps as a percetage) to the render commands is great.
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 ?
...edit...
which brings us back to the long-discussed, approved and never done "abstractions"-folder
...I really think we need this! We already have the objects: I think something like ben's abstractions are probably a good place to start...A good set of abstractions will go a looong way toward improving the newbie's learning curve...
This is true, and I would be happy to make non-Gop versions of these abstractions is necessary. We do need easy access for a user to at least play pause video, rate control is also nice. As an abstraction or as an object means little for my argument here, its a purely from a user pov.
I'm apologize to all for not having my GOPs in the cvs abstractions, I'll get on that when vacation hits. I think it would be great if they could be included with Gem, or some form of them. (they now require zexy, OSC and prepend)
B.
l8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Quoting IOhannes zmoelnig zmoelnig@iem.kug.ac.at:
hi. i have already implemented something similar under linux, but of course,
differently. i am simply using the argument to "auto" as the framerate. so with "auto 0", no auto-playback is used, with "auto 1", we have normal speed playback. with "auto 0.5", we have half-speed playback.
is this confusing to the user ?
I had considered doing this but did not use 'auto' because I didn't know if it created a discrepency in behavior accross platforms. My only question is: How does using 'auto' affect existing patches? If it doesn't really affect that and as long as we have something consistant then either using 'auto' or 'rate' is fine by me.
cgc
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
cgc@humboldtblvd.com wrote:
Quoting IOhannes zmoelnig zmoelnig@iem.kug.ac.at:
I had considered doing this but did not use 'auto' because I didn't know if it created a discrepency in behavior accross platforms. My only question is: How does using 'auto' affect existing patches? If it doesn't really affect that
well, it shouldn't do much: as for now, the valid arguments are 1 and 0, which would be 100% compatible. the only problem may arise if someone uses numbers other than 1 for setting the auto to "true", which i -- personally -- consider bad style.
however, if someone has objections, he ought to speak now or be silent forever (should we post this to the normal pd-list then ?)
mfg.asd.r IOhannes
-
B. Bogart -
ben＠ekran.org
-
cgc＠humboldtblvd.com -
chris clepper
-
IOhannes zmoelnig -
tigital＠mac.com -
zmoelnig＠iem.at