jsr_

this might be close to a double post, i admit. it is the same problem as described here: 

https://cycling74.com/forums/syncing-qt-with-midi

but i have come closer to the problem and i realize it is not a jitter problem, it is a problem with seq. i posted the other thread in the jitter subforum, this one now goes in the max/msp subforum.

when i play back a midi track exported from pro tools with the 'seq' object the midi information is drifting out of sync with audio + video. quite a lot.

is there a way to make the seq run tighter? perhaps in with timecode from the video? or with use of the 'tick' messages triggered by a metronome?

the midi file was exported from protools with a session running 120BPM. the same behavior happens if i record the midi data with the seq object, and play it back afterwards.

this might be close to a double post, i admit. it is the same problem as described here: https://cycling74.com/forums/syncing-qt-with-midi

the midi file was exported from protools with a session running 120BPM. the same behavior happens if i record the midi data with the seq object, and play it back afterwards.


seq-midi-drifting-out-of-sync

There is a small patch a the bottom of this topic that may help you:

https://cycling74.com/forums/syncplay-midi-and-audio-files

I don't know Jitter well, but I suppose you could regularly ask 

 messages as regularly as possible (48 messages / second). But I may be wrong...

I don't know Jitter well, but I suppose you could regularly ask jit.qt.movie its position with the gettime message to send seqtick messages as regularly as possible (48 messages / second). But I may be wrong...


gettime looks promising... but it only sends a msg every second. how would i go about getting 48 ticks/sec out of that?

ps: for reference: i added my current patch to this thread: 

https://cycling74.com/forums/syncing-qt-with-midi#post-165215

ps: for reference: i added my current patch to this thread: https://cycling74.com/forums/syncing-qt-with-midi#post-165215


gettime is as fast as you send it to jit.qt.movie. I can get values every couple of ms.

But it may indeed not be the right way... What if you sync your movie and your seq to a soundfile?

hm... this is interesting. perhaps i could even have that soundfile as a separate track in QT, routing it to max via something like soundflower?

but please explain, what is the sync that is coming out of an audio file? is it a tick on every sample, so sample rate based? what should this audio file contain?

and how is this more stable than just making some metro with the right tempo?

, but its speed is much more accurate than Max' internal scheduler.

As you saw in the other topic, the position in a soundfile is given as a signal (it doesn't depend on Max' scheduler), so it's refreshed at every vector.

To get those 48 ticks every sec., you could also imagine to have a sound file embedded in the QT movie with 48 digital clicks every second and analyse this file (with a 

 for instance). Unfortunately I see that 

Not sure soundflower is the right way to go for an installation...

There is no sync from an audio file per se, but its speed is much more accurate than Max' internal scheduler.

To get those 48 ticks every sec., you could also imagine to have a sound file embedded in the QT movie with 48 digital clicks every second and analyse this file (with a change~ for instance). Unfortunately I see that spigot~ is only stereo.

Not sure soundflower is the right way to go for an installation...


max is truly a different way of programming. but i like it :)

seq midi drifting out of sync