Hey Amo,

It sounds like you've got the right idea, however there aren't always 600 QTU/sec.. this is the case MOST of the time, but occasionally you'll run into a video file that has some other time signature. I do not believe it is dependent on being a particular filetype (such as MPEG or AVI), as I've noticed that standard QT DV files will sometimes have a timescale of 2997 QTU/sec.

One of the nice features of jit.qt.movie is that you can get this value once the movie is loaded (I think the gettimescale message), so it's pretty easy to adjust your patch accordingly.

This doesn't necessarily mean that you need to move to jitter now though.. another Max-head named Michael Egger makes a little app called Live Cut, and I'm pretty sure he wrote his own external for getting various bits of information out of a QT file, including the timescale. I'm not sure if the external is available to the public, but the Live Cut app is under the GNU GPL, so if you're using it for a non-commericial projects you might be able to drop Michael a line and ask him.

More info on Live Cut here: http://livecut.sourceforge.net

- DL

Yes, I once wrote a quick and dirty external for LiveCut that extracts the timecode information out of clips that are captured with final cut, for example - if you captured, say, the last ten minutes of a dv tape, my external will give you something like 0:50:00:00 for the start timecode. it works more or less, but I don't guarantee that it's 100% ok (was my first attempt to write an external, and I haven't looked into it since...) there's also a lot more information in QT files one could extract quite easily. it's open source (gpl), so feel free to improve it... ;-)

qttimecode:

cheers

Michael

Thanks a lot to both of you for the help. I will look closely to the external, cheers for that Michael ! In fact, my plug if for composers to write music on films provided by external people, so mainly I should not be annoyed by DV tapes captures etc... People provide renders in general, with start at 0.

But my main problem is I use the sample count to sync the movie to the sequencer's timeline. Now with 600 QTU, it's no problem, I get sync each 6 QTU, but the thing is quicktime doesn;t take float numbers, and with a QTU of 2997... the maths are not so simple (and my math are not so good as they used to !). So I have to find a way to divide those different QTU in either 44100, 48000 etc...

I'll investigate in those in the next week but If you've got any clue, that's much welcome.

Regards,

Amaury

Amaury Groc wrote: > So the question is (I'll investigate when I have time), > does quicktime follows another timing rule for mpeg movie ??

No, but eventually your mpg movie does. Not all devide by 600 as far as I know.

> btw, I plan to rebuild the plugin using jitter instead of > MAX object to play the movie. Does is sound like a good idea > to you, or is there something I miss ? The plug is hosted by pluggo in the end...

At least that way you find out what the division of the movie is...

Stefan

--

[][] [][][] [][] [][][] [][] [][][] [][] [][][] [][][][][][][][][][][][][][][][][][][][][][][][][][][][]

Stefan Tiedje Klanggestalter Electronic Composition & Improvisation

/~~~~~ \ /|() ()| ))))) )| | |( \ /// _/)/ ))))) ___/ ///

-------------------------x--- --_____-----------|---------- --(_|_ ----|-----|-----()--- -- _|_)----|-----()---------- ----------()------------x----

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France Phone at CCMIX +33-1-49 77 51 72

Hi,

I rewrote my patch using Jitter (maybe I should post in Jitter forum ?), and found out my not working mpeg files have 90000 QTU/s. Then my method of getting sync from the host doesn't work very well. Let me explain: with 600 QTU/s, what I did is get the sample count from song start, then divide it by 441 or 480 depending on the song's sample rate, and then multiplying it by 6. I send this number through a time message box to the qt.movie object and the sync is tight in all cases. Now I can't find a solution to send enough values to the time message box when QTU/s is 90000 for the movie to play fluid. There must be a simple solution, like a ramp or something but I didn't yet found out. If anyone knows a trick, welcome !

Regards, amo

Hi again,

I thought of sharing the process of my work here, since it could be usefull to others:

Firstly, I've rebuilt the MoviePlayer plug using Jitter... Works great BUT I, at the end of the process, found out that it won't run as a pluggo plugin if Jitter is not installed on the user's computer. So, totally useless.

At lest I've rebuilt a better sync engine, which deals with QTU/s greater than 600, though I still have problems with 2997 QTU/s (44100 and 48000 hardly devided well by 2997).

So I'll re-write it using only Max objects. I discovered that the Max imovie object can give the timescale with a timescale message. That was not documented in the Max reference file.

So Now, Either I have to find a way to give a bang to timescale message box once a movie is read in imovie object (If anybody has a hint to send a bang on movie read using imovie, much welcome. I've only thought of using a metro that bangs the timescale message box with a change object plugged to the imovie outlet to avoid too many values... not so beautifull solution), either I'll have a look at Michael's external.

Thanks for help so far,

Kind regards,

Amaury