ramp that synchs itself to a stream of floats

Jun 25, 2010 at 9:57am

ramp that synchs itself to a stream of floats

I would like to substitute a [sig~] below with something that generates a ramp approximating the speed of the incoming floats (so that I have “movie time” signal). How would I go about that?

– Pasted Max Patch, click to expand. –
#47123
Jun 25, 2010 at 11:29am

bump, this version demonstrates the problem better. I would like to make a signal approximator that is more continuous then the [sig~] output, like a [line~] that keeps improving its approximation of the “signal” sampled by floats.

– Pasted Max Patch, click to expand. –
#169416
Jun 25, 2010 at 12:30pm

Bump, I’ve come up with the following myself. Try to playback a movie in presentation mode and watch the redline extrapolating the movie time. The extrapolation isn’t continuous (it jumps to reported value each time it receives one) and goes crazy at the moment movie loops (and hence won’t like jumps either).

My idea is to use the extrapolated ramp to control the playback of cued samples together and in sync with video.

I guess I could do something quite similar other way around – generating the speed ramp myself and using it to control both audio and [jit.qt.movie].

– Pasted Max Patch, click to expand. –
#169417
Jun 26, 2010 at 11:54am

hi raja

thanks a lot for the ideas, I myself are too biased by having seen how videoplayers synchronize video to audio and other way around and have a great difficulty thinking outside of that box :-)

I was making the ramp to go from 0 to movie duration in miliseconds, but maybe that’ll loose too much accuracy with time (I use movies up to around 7 minutes). My current approach produces way too wiggly ramp, if I then use it to drive [play~] there are too much artefacts in audio. So I now think it should be much more conservative in adapting to the apparent movie rate and only (smoothly) change its own rate when current time difference between the two is above some threshold.

I’m starting to think that this approach is unnecessary overcomplicated, I think I’ll try something simpler before I get back to this.

#169419
Jun 28, 2010 at 1:51pm

ok, so I’m back to this problem.

I had a look at seq~, it manifests exactly the “problem” I’m trying to solve with my ramp. I work with long movies and long samples / sound files that I’m placing on the same timeline. If I jump to a place in the movie that’s in the middle of a long sample I want to hear the sample from that point, which as far as I can see seq~ won’t allow me to do.

So I thought I’d make a master time signal (milliseconds or (0.0-1.0) stretched across the movie) and use that minus sample sync point to drive play~.

I use time reported by jit.qt.movie because I can’t see a proper way to drive it by an MSP signal.

But maybe what I actually have to do is compare my master time and time reported by the movie and adjust the movie playback rate a little bit if the difference becomes too large.

#169420

You must be logged in to reply to this topic.