*efficient* qt clip triggering with no delays
hello
i've got a bunch of clips. i want to trigger any one of 40. i might want to retrigger a clip which is already playing, effectively restarting it, or start another, in which case i want the one playing to stop and disappear but remain in memory for fast retriggering should i choose. think live video triggering and possibly scratching and triggering in high speed/d&b style.
my choices appear to be:
- multiple videoplanes, and enabling/disabling them
# 40 videoplanes? i think not.
- one .mov file and use frame to access one of 40 points
# the frame message is ok to move to a specific point in the .mov and play, but i want to have it stop when it reaches the end of that 'section' of the .mov (and not continue to play the next clip); see my other post about knowing which frame in a movie we're in https://cycling74.com/forums/knowing-which-frame-you-are-at-in-jit-qt-movie i.e. because we're dealing with unique 0 qt setup i can seemingly never know where i am in a movie in order to trigger it at a specific point as i'm in 600th timepoints (which might change dependent on the movie). am i better off working with timepoints?
- 40 movie and 40 related audio tracks in one .mov
# i'm considering this but given my failure to get what i want out of jitter thus far i don't want to waste any more time. is it possible to get an efficient response from jitter with a quicktime movie with 40 tracks and have control over looping of each/triggering of each (to the same videoplane) with an audio track for each video track so i can play a clip of a/v live and quickly move to the beginning of another with no delay?
- 40 textures, 1 videoplane
#i dont know enough about this to comment -would this be the way to go?
having spent the money on max/msp/jitter i really want to be able to use it in a live context as it's so flexible - in theory. i'm running everything at maximum efficiency (yuv422, unique 0, etc.) and i've not got it exactly working right so far.
timing is vital to the set. i don't want to buy vdmx5 or avenue. i just want to cut between lots of video clips with the control i want. can anybody recommend a way of doing this with jitter please?
thanks in advance.
the standard answer for this is usually utilizing the poly~ object to manage your 40 qt.movie clips.
you read them in at initialization time (making sure @autostart is 0), and either use the loadram message, or preroll message to put either all or part of the clips into memory. or at the very least, play each clip for a few frames before you leave initialization.
search the forum for "poly~ movies" or something similar.
however, a single movie with cue points is also a viable option.
you can easily get the current frame of a movie using the gettime, gettimescale, and getfps messages.
gettime sends current time out as qtunits. dividing that by timescale (qtunits per second) gives you current time in seconds. next multiply by fps (frames per second) will give you the current frame.
funnily enough, I've done a strip down version of the poly~ version and it works fine in HD... but I cannot swap movies faster than every 115 ms, it clutters the scheduler it seem so.
I am happy to post a patch if anyone has ideas on how to improve the random access between films. I would like to get to 1 frame per film (i.e. 40 ms period in pal)
any pointer welcome
p
my best results have always been to use one long movie and frame sections going to [pak looppoints 0 0]. You can use [preset] on the looppoint start and end for each section, maybe a [umenu] with the "scene name" that triggers the right preset.
If you want crossfading between clips, you can use a feedback loop with [jit.xfade], or [jit.slide] during the transition. Or have two main movieplayers, each with the same long movie-with-cues, and use [jit.xfade] as you would normally.
Loading any new movie, even a small image file, has always caused a bit of a pause/delay in my experience. Jumping around in a big movie has been totally seamless.
thanks for this. The only thing I don't understand is that the movies are actually already loaded in different voices of the poly, so I am literally just starting the movies of a given voice (as per video tutorial 4 by Andrew Benson)
the one big movie option is a pain, and not very dynamic either, so I would prefer to say away from it
p
Thanks to all of you for the comments. I'm glad I wasn't that far off. As I'm working only with jitter for the moment, I missed poly~. Robert I didn't know the maths with qt movies was reliable - thanks for allaying my fears.
any idea on how to get the poly~ option faster (i.e. switch film at each frame in PAL - every 40ms)
pa
hello pierre,
it is not possible with the poly~ version.
in the past it was discussed here:
https://cycling74.com/forums/loadram-in-andrew-bensons-movie-bank-patch-does-not-work
it would be great if this bug will be fixed with the next version
of max ....
fast switching movies seems to be important for may
jitter users ;-)
kugelschreiber
thanks so much for this, I did search for the forum but it seem difficult to get the result!
thanks again
p
actually, this is now a message for Andrew Benson ;-) seriously, I don't have the same issues than described in the thread you pointed at.
Random access of films is immediate, but when done too quickly, it clutters the scheduler. To reproduce what I am talking about, just put a qmetro before the 'random' button of the tutorial... I get it to work flawlessly down to a period of 125ms then it starts to freak out!
any help welcome
p
Robert Ramirez,
Im interested in your calculation of the current frame - as you need to pass gettimescale and getfps in order to get the values (which you only need once) and gettime (which you obviously get at intervals, what is the most efficient implementation of this logic?
I'm using 20-odd operators to acheive the right value and i'm sure there's a simpler way which is cpu light. a pasted patch would be much appreciated.
Hi Pierre,
I was experimenting with this at one point for a project. The best results I got were achieved by doing away with start and stop messages entirely, and directly driving the movie frames. Below is a version of the poly~ subpatch from VPS that uses this technique. The trick with this is you have to ensure that your metro is banging at the appropriate FPS, and you might need to implement some sort of periodic frame re-sync if you are doing something where movie timing is vital. Again, this is purely based on my empirical usage, and YMMV.
Dear Andrew
It works! This is ace, thanks! For the record, is it the quicktime API that clutters the thread?
Thanks for this, it is a great work around
p