d17e

Is there a possibility of ensuring audio playback from a specific jit.qt.movie object?

the thing is, on one of the movies i'm playing there's a timecode (SMPTE) audiotrack wich syncs up samples and musicians with the video i'm playing; So it's pretty important that the timecode doesn't get distorted.

Now i sometimes have 'hick-ups' in the audio, it even happened allready when my movies were playing at 30fps, but the audio didn't come through ok all the time. (There's only one movie with an audio track)

Is there a way to prevent this, and guarantee that the audio comes through? i tried loading the audio track of the movie into ram already, but this gave buggy performance and sometimes crashed max... and that's not what i'd prefer either

... anyhoo, if someone can help or has any experience with this that 'd be great. and a small expample patch would even be better :)

Is there a possibility of ensuring audio playback from a specific jit.qt.movie object?
the thing is, on one of the movies i'm playing there's a timecode (SMPTE) audiotrack wich syncs up samples and musicians with the video i'm playing; So it's pretty important that the timecode doesn't get distorted.

ensuring-audio-playback-with-jit-qt-movie

I would load the audio in a buffer~ (use the 'import' message so you don't have to save the soundfile seperately) and let the jit.qt.movie follow the audio playback.

I do it like this: take the sync out of [groove~], connect it to a [snapshot~ 20] -> [* (timescale/1000)] -> [prepend time] -> [jit.qt.movie]. Make sure to set the movie's rate to 0.

Thanks for the input. The method you provided does work and ensures the audioplayback. Though, it runs a little slower than just playing back the video if i'm doing more than playing back the movie and audio.

But i found out that the distorted audio signal was not a problem with my patch, but more a physical problem. The audio signal that my laptop outputs was simply not strong enough at all times. So putting an amplifier after the output and before inputting into the DR8 device solved my problems.

How do you keep the importing into the buffer from stopping the video from playing?

Quote: grimepoch wrote on Mon, 16 July 2007 03:55

----------------------------------------------------

> How do you keep the importing into the buffer from stopping the video from playing?

I'm not sure if I understand your question, but in my case the video does stop during the time that the buffer is importing. It would be good if there would be an 'importlow' that would read the audio asynchronously (in a separate thread).

It would even be better if it was possible to assign one separate chain of events to a different thread altogether but well, I assume we'll have to wait a bit longer for that ;)

Quote: grimepoch wrote on Mon, 16 July 2007 03:55
----------------------------------------------------
> How do you keep the importing into the buffer from stopping the video from playing?
----------------------------------------------------

No, you understand exactly what I am dealing with. For doing live performance for me, this is a deal breaker at the moment with ANY kind of audio from a movie unless they are preloaded. I get the glitches with buffer~, jit.buffer~ and when using @soc with a jit.qt.movie.

No, you understand exactly what I am dealing with.  For doing live performance for me, this is a deal breaker at the moment with ANY kind of audio from a movie unless they are preloaded.  I get the glitches with buffer~, jit.buffer~ and when using @soc with a jit.qt.movie.

I feel your pain, and I would invite you to write lots of angry 

letters to Apple for breaking the good old Sound Output Component in 

QuickTime 7. We found a cross-platform solution which works for lots 

of different usage patterns. Unfortunately, not yours... If you have 

the luxury of multiple sound channels, you might be able to do some 

kind of loopback hack (sound output -> sound input) and do your live 

Am 16.07.2007 um 16:53 schrieb Rick Burnett:

> For doing live performance for me, this is a deal breaker at the 

> moment with ANY kind of audio from a movie unless they are preloaded.

I feel your pain, and I would invite you to write lots of angry  
letters to Apple for breaking the good old Sound Output Component in  
QuickTime 7. We found a cross-platform solution which works for lots  
of different usage patterns. Unfortunately, not yours... If you have  
the luxury of multiple sound channels, you might be able to do some  
kind of loopback hack (sound output -> sound input) and do your live  
processing that way.

> For doing live performance for me, this is a deal breaker at the  
> moment with ANY kind of audio from a movie unless they are preloaded.


I definitely understand that this breakage is in apples court, I wish they'd stop crippling their software for things like this.

The problem is, I need the two movies to come out two different stereo pairs so I could have both at the same time and filter each differently.

I wonder, have C74 looked at other video playback systems? Granted, we'd loose the built in QT effects.

I could probably get by if the buffer~ didn't stop all video playback when loading. I kinda wish I knew this before I dropped all that money for Jitter. Not that I don't understand the complexity of the system and limitations, it just leaves me stuck at the moment. I am using the volume control on the jit.qt.movie so I can at least scale them.

I wonder, have C74 looked at other video playback systems?  Granted, we'd loose the built in QT effects.

I could probably get by if the buffer~ didn't stop all video playback when loading.  I kinda wish I knew this before I dropped all that money for Jitter.  Not that I don't understand the complexity of the system and limitations, it just leaves me stuck at the moment.  I am using the volume control on the jit.qt.movie so I can at least scale them.

The importing of the audio via Jitter should happen in a background 

thread. If you read the movie using the "asyncread" message, you 

really ought to have very little interruption.

Am 16.07.2007 um 18:09 schrieb Rick Burnett:

> I could probably get by if the buffer~ didn't stop all video 

> playback when loading. I kinda wish I knew this before I dropped 

> all that money for Jitter. Not that I don't understand the 

> complexity of the system and limitations, it just leaves me stuck 

> at the moment. I am using the volume control on the jit.qt.movie 

The importing of the audio via Jitter should happen in a background  
thread. If you read the movie using the "asyncread" message, you  
really ought to have very little interruption.

> I could probably get by if the buffer~ didn't stop all video  
> playback when loading.  I kinda wish I knew this before I dropped  
> all that money for Jitter.  Not that I don't understand the  
> complexity of the system and limitations, it just leaves me stuck  
> at the moment.  I am using the volume control on the jit.qt.movie  
> so I can at least scale them.


Quote: grimepoch wrote on Mon, 16 July 2007 16:53

> No, you understand exactly what I am dealing with. For doing live performance for me, this is a deal breaker at the moment with ANY kind of audio from a movie unless they are preloaded. I get the glitches with buffer~, jit.buffer~ and when using @soc with a jit.qt.movie.

Ok, so you understand that this is a matter of assigning separate threads to different tasks. Max is not very good at that, I think you're right about that.

For example you might have experienced that drawing of interface elements is also done in this same bufferloading/movieplaying thread. Which means that rapidly updating gui elements have effect on your jitter output framerate.

The one way to have control over separate threads in Max is to start two different instances of the app. Max is quite tolerant in that, so making two different applications run simultaneaously and communicating between them with a network connection is likely to work well. Perhaps this info helps in some way?

I don't know what you're after of course, but I can imagine having a separate instance load and play the video, controlled by your play head in the other instance that does the timing and audio. Network communication between two apps on one computer is definitly fast and reliable enough to be frame accurate.

Quote: grimepoch wrote on Mon, 16 July 2007 16:53
----------------------------------------------------
> No, you understand exactly what I am dealing with.  For doing live performance for me, this is a deal breaker at the moment with ANY kind of audio from a movie unless they are preloaded.  I get the glitches with buffer~, jit.buffer~ and when using @soc with a jit.qt.movie.
>
> *sigh*  back to the drawing board.
----------------------------------------------------

Ok, so you understand that this is a matter of assigning separate threads to different tasks. Max is not very good at that, I think you're right about that. 

The one way to have control over separate threads in Max is to start two different instances of the app. Max is quite tolerant in that, so making two different applications run simultaneaously and communicating between them with a network connection is likely to work well. Perhaps this info helps in some way? 

I didn't use asyncread. I didn't fully understand the difference as it wasn't explained well. What is the difference between the two?

Also, is there any speculation as to future versions of max/msp/jitter, like when they'll surface. Just curious with thoughts of hope :)

I didn't use asyncread.  I didn't fully understand the difference as it wasn't explained well.  What is the difference between the two?

Also, is there any speculation as to future versions of max/msp/jitter, like when they'll surface.  Just curious with thoughts of hope :)


Interesting! I did not know you could run two copies of max. Will have to experiment with that. Thank you.

No, not ideal, but could be for some interesting testing to say the least. Thanks for the idea!

Interesting!  I did not know you could run two copies of max.  Will have to experiment with that.  Thank you.

No, not ideal, but could be for some interesting testing to say the least.  Thanks for the idea!

Ensuring audio-playback with jit.qt.movie