Forums > Jitter

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

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


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

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 274 224 32 196617 sel 1;
#P newex 227 198 57 196617 unpack s 0;
#P newex 227 171 57 196617 route read;
#P newex 174 149 63 196617 jit.qt.movie;
#P comment 284 249 144 196617 < - bang here? movie is loaded;
#P connect 3 1 4 0;
#P connect 2 0 3 0;
#P connect 1 1 2 0;
#P window clipboard copycount 5;

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.


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


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


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

http://www.cycling74.com/twiki/bin/view/FAQs/BeginnersFAQ

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


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


August 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


August 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


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


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


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


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


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


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


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

http://www.vade.info
abstrakt.vade.info


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

Here are some of the files (1 of each codec):
http://www.christopherbecks.com/jitter/v_sorensen3_moyen.mov
http://www.christopherbecks.com/jitter/v_H264_moyenne.mov

http://www.christopherbecks.com/jitter/v_photojepeg_low_middle.mov

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.


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


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

http://www.christopherbecks.com/jitter/Poly~ForMovies.pat

http://www.christopherbecks.com/jitter/polymovie

Thanks.



rvr
August 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 :>


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


September 1, 2007 | 8:43 pm

in case you are still wondering …

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 280 351 100 196617 bang on loop;
#P flonum 286 259 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 265 349 15 0;
#P button 231 349 15 0;
#P newex 231 326 44 196617 togedge;
#P newex 231 304 27 196617 > 0.;
#P newex 248 282 48 196617 – 0.5;
#P newex 248 259 33 196617 / 0.;
#P comment 179 201 90 196617 duration (frames);
#P comment 180 308 24 196617 ms;
#P comment 128 308 24 196617 sec;
#P number 186 186 50 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 180 291 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 180 258 47 196617 * 1000.;
#P number 127 291 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 127 258 33 196617 % 60;
#P number 96 291 28 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 96 258 30 196617 / 60;
#P number 102 227 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 147 186 33 196617 / 0.;
#P number 147 152 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 133 54 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 133 74 43 196617 rate $1;
#P comment 299 173 145 196617 < - check for succesful reading;
#P newex 264 151 43 196617 zl nth 2;
#P newex 264 171 31 196617 sel 1;
#P message 264 194 124 196617 gettimescale , getduration;
#P user jit.pwindow 27 123 82 62 0 1 0 0 1 0;
#P toggle 28 34 15 0;
#P message 103 75 29 196617 read;
#P message 28 75 70 196617 bang , gettime;
#P newex 28 54 51 196617 metro 20;
#P newex 28 102 129 196617 jit.qt.movie;
#P newex 147 123 166 196617 route time duration timescale read;
#P comment 95 308 24 196617 min;
#P window linecount 2;
#P comment 321 259 100 196617 time before end to bang (secs);
#P window linecount 1;
#P comment 120 351 115 196617 bang 0.5 secs before end;
#P fasten 17 0 18 0 152 215 107 215;
#P fasten 17 0 23 0 152 219 185 219;
#P fasten 17 0 31 0 152 242 236 242;
#P connect 35 0 30 1;
#P fasten 3 2 17 1 230 175 175 175;
#P fasten 3 2 29 1 230 233 276 233;
#P connect 32 1 34 0;
#P connect 32 0 33 0;
#P connect 30 0 31 1;
#P connect 31 0 32 0;
#P connect 29 0 30 0;
#P fasten 25 0 29 0 191 238 253 238;
#P fasten 10 0 4 0 269 216 448 216 448 96 33 96;
#P fasten 7 0 4 0 108 96 33 96;
#P connect 6 0 4 0;
#P fasten 14 0 4 0 138 95 33 95;
#P connect 4 0 9 0;
#P connect 4 1 3 0;
#P fasten 3 1 25 0 191 148 191 148;
#P connect 18 0 19 0;
#P connect 18 0 21 0;
#P connect 23 0 24 0;
#P connect 16 0 17 0;
#P connect 3 0 16 0;
#P connect 3 3 12 0;
#P connect 11 0 10 0;
#P connect 12 0 11 0;
#P connect 15 0 14 0;
#P connect 21 0 22 0;
#P connect 5 0 6 0;
#P connect 8 0 5 0;
#P connect 19 0 20 0;
#P window clipboard copycount 37;


September 2, 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.


September 2, 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.


September 2, 2007 | 11:42 am


September 2, 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.
>


September 2, 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.


September 2, 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.


September 2, 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.
>


September 2, 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.
>
>
>


September 2, 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 ;)


September 2, 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.


September 2, 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.
>


September 2, 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.


Viewing 33 posts - 1 through 33 (of 33 total)