Gui slow to respond

[gavspav]

I've got quite alot going on in my set now - 4 movies playing from the hard drive and a fair few observers and api calls.

Its working fine but I've noticed that the Gui is becoming a bit slow to respond.

I've got my clips midi learned and if I trigger them via my midi keyboard performance is spot on.

So I'm wondering whats going on here - what does the Live GUI share a thread with?

[andrewbenson]

Hi Gavspav,
UI redrawing, etc. all happens in the main application thread, which is also where the jit.qt.movie objects live as well. It's fairly well known among longtime Jitter users that pretty much any fancy UI stuff you do will interfere with your video playback to some extent. Some folks even go so far as to separate their entire GUI and video processing patches into separate standalone applications that talk over OSC or MIDI to reduce this issue. Things like rapidly updating number boxes and such are the most common offenders. You might also have a look at the fact that accessing 4 independent movie clips from disk at the same time can be pretty taxing, both in terms of CPU usage and disk access. If you are also playing back audio file from disk, you might eventually hit a limit there as well. No matter which way you slice it, if you are getting heavy into Jitter in Max for Live, you'll become more in tune with the limitations of your CPU, threading concerns, and performance. You'd probably be well served combing around the Jitter forum archives for different discussions of efficiency and performance.

Ultimately, you might reach a level of complexity where doing everything inside of a Max device inside of Live is going to be more of a hassle than a convenience. When you reach that point, come on over to the Jitter forums and we'll help you come up with another solution.

Andrew B.

[gavspav]

Andrew, thanks for your response, I was actually thinking of asking your advice on some of this stuff.
I have scoured the jitter forums over the past few weeks and have already picked up some of what you say.
I realize that there are limits - particularly those of hard drive bandwidth and jitter thread priority.
Also understand that the convenience of running everything in Live does compromise performance.

All of this is an experiment for me at this stage to see how far it can be pushed and in a way I posted because I was surprised at how much I could do with Jitter/M4L inside Live. I dont have much jitter or max experience so I'm sure my patch is not even optimised as best it could be but it seems to be able to cope with 4 tracks of video. Haven't even had to load into ram although this is an option.

As I said the Live GUI is slightly slow to respond but if I dont use the keyboard or mouse performance seems pretty good to me.
CPU meter in Live reads 13%, Activity Monitor reports Live as using 77%!
If I use an fps counter it reports 45 - 60 fps - not sure what this actually means though - I guess it is the number of times the jitter window draws as opposed to the number of times the video frames actually reach that window.
Incidentally the fps counter is the main rapidly updating GUI element - when I remove it performance does improve.

The main issue with my set is that I'm banging out a get playing position message to a live object around 40 times a second on each track to get around the resolution limit of live.observer! To be honest I am blown away that it will handle this at all. One thing I'd like to know - say for examples sake that live.observer reports a value 25 times a second, would using live.object 25 times a second be more expensive than this or the same? ie Is the observer inherently more efficient?

I should probably use the observer in conjunction with a phasor locked to the live tempo and just scan the playing_position data for changes/loop points etc. But this is going to create some latency which at the moment I just dont seem to have!

[Gregory Taylor]

One question you might profitably ask yourself when working with Jitter and UI objects in a Max patch in general has to do with *why* you think you need to have all those number boxes updating constantly or why you need to poll stuff at the resolution that you do. In terms of the "bang model" that Jitter uses, ask yourself what frame rates you actually need: arguably, anything above a certain rate's not going to buy you much anyway, so why throw in bangs that are going to do anything more than use resources and show you the same frame of video you've already seen (which is what you do if you bang a jitter object playing at, say, 30 FPS at a higher rate than 30 times per second). Similarly, some serious thought about what kinds of UI feedback you really *need* and what stuff you could consider putting "under your fingers" instead will benefit you in the long run.

Anything you do using the Live API is going to be coming back to you in the low priority queue - so if there's any way you can use the Max transport object to provide you with data about time-related information, it is to your considerable advantage to do so.

[gavspav]

Yes those decisions are not taken lightly!

Regarding the updating number boxes err I haven't got any.

And regarding the polling well the live observer reports ~ 17 times a second on my macbook pro - this value does not seem to be linked to tempo.

So I decided to go for the polling and see if I could get away with it. I can set the frequency but like you said seems you get no extra frames if you go lower than about 30ms. So i've getting about double the (potential) framerate from the polling.

Yes it would be possible to utilize the transport or a phasor locked to the tempo but ultimately the polling frequency determines the latency when a non linear clip event occurs - by this I mean a jump or a loop point - something other than just moving forward at the project tempo. The theoretical latency would be somewhere beteen 0 and around 60 ms as oppposed to 0 - 30 which I have now.

Is it worth the extra cpu hit for the 30 ms - ~1 frame of video!- possibly not - I dunno I'm only experimenting anyway.

[andrewbenson]

One thing which a lot of Jitter users wind up doing is thinning the flow of data to only happen at ~30fps. This means only polling your control data once every ~33ms or so, to reduce the amount of extra message passing, since you aren't actually going to see the results of any increase in data sampling rate. You can often get away with 10-15fps for video control data and be fine. Audio is far less forgiving. Also, something to consider when you are planning for synced audio and visuals, is that the human brain is very forgiving when it comes to associating audio and visual stimuli, so you don't need to stress about the latency too much.
I'm impressed that you are getting such good framerates with 4 simultaneous streams of video. I haven't done much stress testing of Jitter playback in Max for Live, so I'm heartened to hear it is going well for you in general.

A

[gavspav]

Whilst it works alot better than I thought, I'm not sure about the frame rate thing tbh.

The fps counter reports how many time the gl window gets rendered but not necessarily how many frames of video actually reach it.
All my jitter playback devices are in different tracks and therefore threads. Hard to tell if the frames reach the window.

The video frame pointer seems to get hit about 30 times a second for each track but at the moment, due I think to the inconsistency of API timing but possibly to programming error some of these frames are duplicated so I might have frame 1, frame 2, frame 3, frame 3 , frame 5.

I will sort this out next but even so I don't know how to see if all these frames are rendered as the renderer and the videoplane are in different threads.
I could thepretically change this but it would make it all alot harder to manage.