How to get jit.qt.movie to output bangs on clip start and end?


    Aug 29 2007 | 5:24 am
    There must be a simple way to do this. I've read the docs and I feel like I must've lost a piece of my memory, but after scanning through it again didn't find an answer. This is rather urgent so I'd really appreciate any help.
    Basically, I want to have a bang or message output when a clip ends and when it begins. The end of a clip is what I need to toggle the random clip selector to load a new clip, and the beginning of the clip is what I need to toggle a fade-in. I've got everything done except the toggling of these functions.
    I've tried the solution of using the select object to send out a bang when the clip's current position equals the clip's length (or when it equals 0, to signal a clip's beginning), but it just skips over the value, as the select object doesn't seem to accept a value if it's quickly "zoomed by"--this can be done quite easily even with the scroller. But the point is that all this shouldn't be necessary.
    So how do I get a simple bang or output upon the start and end of a clip?
    Thanks, all.

    • Aug 29 2007 | 6:03 am
      There's no built-in function for this, but if I'm reading your email correctly, you don't really need it. Use the right output of jit.qt.movie to determine when the clip is loaded by routing for the word "read" and checking that the second arguments to the list is 1. Like this:
      
      jb
      Am 29.08.2007 um 07:24 schrieb Christopher Becks:
      > > There must be a simple way to do this. I've read the docs and I > feel like I must've lost a piece of my memory, but after scanning > through it again didn't find an answer. This is rather urgent so > I'd really appreciate any help. > > Basically, I want to have a bang or message output when a clip ends > and when it begins. The end of a clip is what I need to toggle the > random clip selector to load a new clip, and the beginning of the > clip is what I need to toggle a fade-in. I've got everything done > except the toggling of these functions. > > I've tried the solution of using the select object to send out a > bang when the clip's current position equals the clip's length (or > when it equals 0, to signal a clip's beginning), but it just skips > over the value, as the select object doesn't seem to accept a value > if it's quickly "zoomed by"--this can be done quite easily even > with the scroller. But the point is that all this shouldn't be > necessary. > > So how do I get a simple bang or output upon the start and end of a > clip? > > Thanks, all.
    • Aug 29 2007 | 6:09 am
      Thanks. That solves half of it. I knew I was overlooking something.
      But how to accurately set a trigger for the end of a clip?
    • Aug 29 2007 | 6:21 am
      And I'm embarassed to say that I don't know how to open up that text as a patch. I get the gist of it but would still like to know.
      And while I'm covering things I may've overlooked, is there a much simpler way to auto-fade out the end of every clip and fade-in the beginning? Right now I'm triggering a line for the beginning of the clip (driving the brightness of jit.brcosa), but I'm not sure how I'll accurately set the fade-out to begin so that it finishes exactly at the end of the clip. Each clip is a different length.
      Too bad QT doesn't give a duration value in milliseconds so I could simply tell the player to fade out at 500ms (or whatever) before the end of a clip (derived from the duration or loopend value, if it were in milliseconds, -500).
    • Aug 29 2007 | 6:31 am
      @loopreport is the attribute you want to set to enable notification at the end of a loop -- check the reference page - there's lots of interesting and useful information there; for instance, how to get jit.qt.movie to report the "loopend" attribute in milliseconds (hint: editmode).
      You seem to be falling into the trap of "why didn't someone make a single object that does all the things that I want?". Sometimes you get lucky, but in general, you're using Max because nothing does exactly what you want. Building an auto-fader isn't terribly difficult, and probably a great exercise as you get to know the software.
      To paste that patch-as-text stuff, check out this article:
      jb
      Am 29.08.2007 um 08:21 schrieb Christopher Becks:
      > > And I'm embarassed to say that I don't know how to open up that > text as a patch. I get the gist of it but would still like to know. > > And while I'm covering things I may've overlooked, is there a much > simpler way to auto-fade out the end of every clip and fade-in the > beginning? Right now I'm triggering a line for the beginning of > the clip (driving the brightness of jit.brcosa), but I'm not sure > how I'll accurately set the fade-out to begin so that it finishes > exactly at the end of the clip. Each clip is a different length. > > Too bad QT doesn't give a duration value in milliseconds so I could > simply tell the player to fade out at 500ms (or whatever) before > the end of a clip (derived from the duration or loopend value, if > it were in milliseconds, -500).
    • Aug 29 2007 | 6:43 am
      Thanks again. I don't often need things layed out for me like this, but I don't have the time on this one and I'm obviously a little rusty in my logic. That, plus I started using Jitter today.
      The auto fades are done, but since I haven't had the chance to look through all of the objects I wasn't 100% sure if there isn't something more suitable for doing a fade-out (fade-in is easy), since timing it to end with the end of a clip of any length is just a little more involved than a fade-in. But now that I know I can work with milliseconds this shouldn't be hard.
    • Aug 29 2007 | 7:44 am
      It is reported that loopnotify doesn't always does what it's supposed to do. I have had the same problem while patching the same thing you did and sometimes the same moovy loops 1 or 2 times (and it's not the odd chance of random choosing the same movie twice or trice)
      what I eventually ended up with is tracking frames and compare it with the total amount of frames in the movie, and that worked for me, obviously reporting frame 0 as the beginning and frame whatever as the lastframe.
      best
      pieter
    • Aug 29 2007 | 7:50 am
      I haven't been able to reproduce this failure on any of my machines using media at my disposal. If someone would be able to supply a patch with media which demonstrates the problem in a semi-consistent way, I would be more than happy to look at it.
      jb
      Am 29.08.2007 um 09:44 schrieb pieter coussement:
      > > It is reported that loopnotify doesn't always does what it's > supposed to do. I have had the same problem while patching the same > thing you did and sometimes the same moovy loops 1 or 2 times (and > it's not the odd chance of random choosing the same movie twice or > trice) > > what I eventually ended up with is tracking frames and compare it > with the total amount of frames in the movie, and that worked for > me, obviously reporting frame 0 as the beginning and frame whatever > as the lastframe. > > best > > pieter
    • Aug 29 2007 | 7:59 am
      Wow, I didn't expect this flood of replies. I have to get some sleep now, but...
      Thanks, Pieter. If loopnotify doesn't behave I'll have to try something based on framecount again although, as I mentioned, when I tried to use that method Max missed it unless I set the end as being at least 50 QT "units" (not frames) earlier than the real end, and use a > instead of == function.
      Jeremy, I'll get some videos to you. Actually, tomorrow I'm getting newly encoded videos from the person I'm working with. I hope that could solve some things. Either way, if I can fully confirm that the loopnotify is not working (it's late...too tired) I'll upload some of the videos I'm having this problem with.
    • Aug 29 2007 | 8:01 am
      the thing is I only get this kind of error when a patch is running for over 6 hours and even then it's not certain that it will happen. What could also be the problem here is that the loopnotify IS indeed reported but that the next action (loading another random movie) isn't triggered. I thus can't comment on the state of the loopnotify (without tracking six hours of movieloading) but I often find it easier to trigger an action some frames before the end of a movie and checking if the action took place on a later (few frames) time in the movie.
    • Aug 31 2007 | 6:29 pm
      So, I managed to test three types of Quicktime encoders with regards to loopnotify acting...loopy.
      Sorenson 3: works perfectly Photo JPEG: Inconsistent. Usually gives a loopnotify bang somewhere in the middle of the clip, but never at the proper loopnotify point. H.264: Same as Photo JPEG
      Hmm. This is unfortunate since Sorenson 3 files are huge compared to the latter.
    • Aug 31 2007 | 7:09 pm
      I take that information back.
      It's being inconsistent. Photo JPEG now works perfectly, though I don't know why this changed. H264 gave proper loopnotify bangs a few times and then started giving a double bang instead.
      So, I don't know how to approach diagnosis on this problem and unfortunately don't have the time. I'll have to re-encode all my videos to Sorenson 3 or Photo JPEG, it seems.
    • Aug 31 2007 | 7:13 pm
      And now the Sorenson 3 files which used to work great with loopnotify are giving a delayed bang. The file is just 7mb, and the other ones are about 1-3mb.
    • Aug 31 2007 | 7:17 pm
      1. Mac or PC? 2. Can you upload the files somewhere?
      jb
      Am 31.08.2007 um 21:13 schrieb Christopher Becks:
      > > And now the Sorenson 3 files which used to work great with > loopnotify are giving a delayed bang. The file is just 7mb, and > the other ones are about 1-3mb.
    • Aug 31 2007 | 7:23 pm
      are you running jitter 1.6.3 ? I believe there were some bug fixes wrt loop notify. If memory serves.
      On Aug 31, 2007, at 3:13 PM, Christopher Becks wrote:
      > > And now the Sorenson 3 files which used to work great with > loopnotify are giving a delayed bang. The file is just 7mb, and > the other ones are about 1-3mb.
      v a d e //
      www.vade.info abstrakt.vade.info
    • Aug 31 2007 | 7:27 pm
      Yes, I'm running the latest versions of Jitter and Max on a PC.
      I just restarted the patch and now all of the files are sending seemingly random bangs, even the Sorenson 3 file that was working properly before. All I need is for something to accurately signal the beginning and end of a clip--this aspect is taking up 90% of my time while accounting for a tiny piece of the patch's function. Sorry, but it's frustrating when trouble-shooting just makes the problem even harder to pin down.
      If there's another tried & tested way to send a bang on a clip's start/end, please inform me because I'd stop messing with loopnotify for this patch.
      Thanks.
    • Aug 31 2007 | 7:34 pm
      I may've screwed up and loaded an old version that I still had sitting my system, but this would just have been once So most of the other inconsistencies stand.
      I just loaded the patch again, this time definately in the new versions, and now it gives me 4 bangs at the correct loopnotify point. This is when I load all of my clips at once with a bang connected to all the "read clip.mov" messages. When I send the "read clip.mov" messages one by one, the loopnotify seems to act differently (giving "random" bangs), but I have no idea anymore what symptom is consistent.
    • Aug 31 2007 | 7:39 pm
      Here's my rather sloppy patch (built from a tutorial patch), if someone would do me the father of having a look for some glaring cause to my problem that I haven't noticed:
      Thanks.
    • Aug 31 2007 | 8:10 pm
      Hmmm...
      If you add a delay object with the time setting equal to the length of the anim then that should work - if I understand the issue.
      So - 1 bang fires your clip and that same bang triggers a delay object which will trigger your random-generator when the clip ends... or slightly before... or slightly after... it all depends on duration you enter into DELAY object.
      Hope that helps :>
    • Aug 31 2007 | 8:28 pm
      Ah, yes, delay! The delay object should solve things, but I'm not sure yet how to accurately convert a QT's timescale to milliseconds. I just need to know if it's possible, then I'll look it up in the docs. I need to make a function that will reset the delay to a clip's length automatically when each clip is loaded
      I'll try a delay object to get the random-clip selector to load a new clip at the right time, and I can use a delay to set a fade-out too. Perfect. Then I can just use the output that's sent when a new clip is rude to trigger the fade-in. Thanks. Now I should be able to avoid using loopnotify altogether.
    • Sep 01 2007 | 8:43 pm
      in case you are still wondering ...
    • Sep 02 2007 | 4:36 am
      Many thanks. I figured it out, but the very helpful and cleanly-done additions to your patch are making their way into mine.
    • Sep 02 2007 | 7:17 am
      I have one remaining problem. I gathered information on what I can use to solve this, but some practical experience of others could tell me how this really should be solved.
      There's a bank of ~150 Quicktimes, varying from 5mb-20mb but totalling around 1.2GB, that I'll be triggering randomly (as you know by now) with fade-outs/ins through jit.brcosa.
      Right now, I'm forced to have a black period between the fade-outs to hide the pause caused by the read time for the new clip. Because the read time varies based on the size of the clip, the pause varies too and this makes things look bad for what I'm doing.
      This isn't a problem at all when I'm looping one clip, which means that it is in fact based on the disk ride time, so I need to load these videos into RAM or somehow pre-roll them (which I believe is possible with QT, but not sure if it is in Jitter). Or I'm just missing something again as I try to do this at 3 in the morning.
    • Sep 02 2007 | 11:42 am
    • Sep 02 2007 | 12:38 pm
      man, just put it all in a poly~ and load all movies at startup. you will have such an easier time of it.
      On Sep 2, 2007, at 3:17 AM, Christopher Becks wrote:
      > > I have one remaining problem. I gathered information on what I can > use to solve this, but some practical experience of others could > tell me how this really should be solved. > > There's a bank of ~150 Quicktimes, varying from 5mb-20mb but > totalling around 1.2GB, that I'll be triggering randomly (as you > know by now) with fade-outs/ins through jit.brcosa. > > Right now, I'm forced to have a black period between the fade-outs > to hide the pause caused by the read time for the new clip. > Because the read time varies based on the size of the clip, the > pause varies too and this makes things look bad for what I'm doing. > > This isn't a problem at all when I'm looping one clip, which means > that it is in fact based on the disk ride time, so I need to load > these videos into RAM or somehow pre-roll them (which I believe is > possible with QT, but not sure if it is in Jitter). Or I'm just > missing something again as I try to do this at 3 in the morning. >
    • Sep 02 2007 | 4:07 pm
      Yea, if you look at the mess of a patch I linked to a few posts ago, I was trying that but ended up getting confused by the poly~ object. Well, not quite, but I stopped using it because it wasn't providing smooth playback from one video to the next, likely because I wasn't using it properly.
      Enabling preroll has had no effect on the load time of a clip, but if I understand it can only preroll the current movie to be quickly restarted. So, that's a no go.
      Loadram seems to expunge any previously loaded video, so that's also a no go, unless I'm wrong.
      Asyncread is just trying to jump ahead in the video after the pause of loading, instead of starting at the beginning.
      So, it may be back to the poly~ object, unless I can load all of the videos into RAM (with loadram or otherwise) as opposed to just one at a time.
    • Sep 02 2007 | 4:12 pm
      And if I go back to the poly~ object, as I understand it different files are loaded into different "instances" with the following syntax: [target 0, read filename.mov]
      So, since I have about 150 files, I want them all to be loaded when the patch opens. I'm having the patch find and list all the .mov's in the folder and I can then prepend "target #, read"... but I'm not sure how to add the sequential numbers after "target".
      Thanks for tolerating a noob.
    • Sep 02 2007 | 4:23 pm
      no, don't mess around with loading RAM. look at the poly~-movies example. un-black it, unskein it. you will see that it's an ideal solution. big trick: send a rate 0 message to the movie you are switching FROM before you switch to the next movie. you'll get amazing performance.
      On Sep 2, 2007, at 12:07 PM, Christopher Becks wrote:
      > > Yea, if you look at the mess of a patch I linked to a few posts > ago, I was trying that but ended up getting confused by the poly~ > object. Well, not quite, but I stopped using it because it wasn't > providing smooth playback from one video to the next, likely > because I wasn't using it properly. > > Enabling preroll has had no effect on the load time of a clip, but > if I understand it can only preroll the current movie to be quickly > restarted. So, that's a no go. > > Loadram seems to expunge any previously loaded video, so that's > also a no go, unless I'm wrong. > > Asyncread is just trying to jump ahead in the video after the pause > of loading, instead of starting at the beginning. > > So, it may be back to the poly~ object, unless I can load all of > the videos into RAM (with loadram or otherwise) as opposed to just > one at a time. >
    • Sep 02 2007 | 4:39 pm
      use an ubumenu, pointed to your media folder, *inside* the poly. take the thispoly~ instance minus one, and use that as the index for the ubumenu. do it on loadbang. your patch will take forever to load, as it opens all of those quicktime files at the same time, but then it will be ready to go.
      On Sep 2, 2007, at 12:12 PM, Christopher Becks wrote:
      > > And if I go back to the poly~ object, as I understand it different > files are loaded into different "instances" with the following syntax: > [target 0, read filename.mov] > > So, since I have about 150 files, I want them all to be loaded when > the patch opens. I'm having the patch find and list all the .mov's > in the folder and I can then prepend "target #, read"... > but I'm not sure how to add the sequential numbers after "target". > > Thanks for tolerating a noob. > > >
    • Sep 02 2007 | 4:53 pm
      Many thanks, Joshua. I'm going to try this in the next hour or two.
      Do me the favour of checking in again as I try to implement your ideas ;)
    • Sep 02 2007 | 5:04 pm
      But I don't see how having the ubumenu inside the poly will automatically make the right number of "voices".
      I also don't know how thispoly~ works so I've got to take a good look at the reference patches to put your solution into play.
    • Sep 02 2007 | 5:24 pm
      you define the number of voices with the poly~ itself: poly~ mypoly 150. the 150 is the number of instances.
      each mypoly file includes a loadbang attached to a thispoly~ object. the thispoly~ reports the instance number. so, if you subtract 1 from that, it will match. instance 1 will load ubumenu index 0, instance 50 will load ubumenu index 49.
      you do not need to deal with voices, or stealing, or anything like that. all instances are 'active'. the 'target [instancenumber]' message will just determine which instance will get the following messages, which include rate messages and timing bangs.
      On Sep 2, 2007, at 1:04 PM, Christopher Becks wrote:
      > > But I don't see how having the ubumenu inside the poly will > automatically make the right number of "voices". > > I also don't know how thispoly~ works so I've got to take a good > look at the reference patches to put your solution into play. >
    • Sep 02 2007 | 5:28 pm
      Thanks for the clear and succinct explanation. I've not used Max in a long time and it's been challenging my capacity for logic.
      So, thanks again, Joshua.