Forums > MaxMSP

ramp that synchs itself to a stream of floats


artm
June 25, 2010 | 9:57 am

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

artm
June 25, 2010 | 11:29 am

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

artm
June 25, 2010 | 12:30 pm

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

artm
June 26, 2010 | 11:54 am

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.


artm
June 28, 2010 | 1:51 pm

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.

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