paulclift

I am using a time-code display (metro + transport) with an external monitor to avoid the need for a click-track in a piece of mine. The output from the transport object is sent to a group of ints (bar number, beat, etc.) which update on each change, allowing the performers to follow along visually. Among other things, I use a panel covering the whole screen which should flash on every new measure. The problem is that, although the CPU is only running at around 20%, there is a huge lag on the elements of the time-code updating on the display, most notably when changing the bgcolor of the panel object (which seems to occur almost randomly). Everything else that is dependent upon the time-code for triggering is working fine... This led me to conclude that these types of display update messages are, by default, treated as low priority by Max. I can understand that in most cases, this would be a good idea, but given that I am using a time-code which has to be very precisely in time, I was wondering if anyone knew how to make this kind of process high priority? (...assuming that this is the cause of the problem.) I have searched for answers on here and elsewhere on the internet but to no avail. Help very much appreciated.

Hi all,
I am using a time-code display (metro + transport) with an external monitor to avoid the need for a click-track in a piece of mine. The output from the transport object is sent to a group of ints (bar number, beat, etc.) which update on each change, allowing the performers to follow along visually. Among other things, I use a panel covering the whole screen which should flash on every new measure. The problem is that, although the CPU is only running at around 20%, there is a huge lag on the elements of the time-code updating on the display, most notably when changing the bgcolor of the panel object (which seems to occur almost randomly). Everything else that is dependent upon the time-code for triggering is working fine... This led me to conclude that these types of display update messages are, by default, treated as low priority by Max. I can understand that in most cases, this would be a good idea, but given that I am using a time-code which has to be very precisely in time, I was wondering if anyone knew how to make this kind of process high priority? (...assuming that this is the cause of the problem.) I have searched for answers on here and elsewhere on the internet but to no avail. Help very much appreciated. 

Hi all,
I am using a time-code display (metro + transport) with an external monitor to avoid the need for a click-track in a piece of mine. 

prioritise-a-process-that-is-by-default-low-priority

not exactly low priority, GUI objects run in their own thread and will ignore scheduler rate anyway.

but i would exclude the possibility that a numberbox is noticable slow or inaccurate because of non-.optimal patching. it might be something else which casues the trouble.

under windows it might be a background process which slows down you GUI.

In a similar situation I opted for JSUI. Depending on OS and Max version you may also want to try mgraphics/jitter.

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

Thanks for the suggestions! I should have mentioned that I am running Max 7.3.5 on OSX 10.12.6. JSUI would be great, but I have to have this working in a couple of days for a performance, so don't have time to learn it :-) I might try with Jitter though...

It's not that difficult in JS. An example is included.

By the way, Max8 has improved graphics performance.

var black = [0., 0., 0., 1.];
var white = [1., 1., 1., 1.]

function set() {
    draw(white);
    refresh();
}

function reset() {
    draw(black);
    refresh();
}

function draw(color)
{
    with (sketch) {
        glclearcolor(color);            
        glclear();            
    }
}

It's not that difficult in JS. An example is included.
By the way, Max8 has improved graphics performance.

function set() {
	draw(white);
	refresh();
}

function reset() {
	draw(black);
	refresh();
}

function draw(color)
{
	with (sketch) {
		glclearcolor(color);			
		glclear();			
	}
}

My guess is that the problem lies in you drawing the Max GUI with very large areas (big int boxes, panels, etc).

Test your patch with a Jitter approach and see if the performance improves. I bet it does.

Drag the Jitter window to the 2nd monitor and press the Esc key to go fullscreen.

 My guess is that the problem lies in you drawing the Max GUI with very large areas (big int boxes, panels, etc).
Test your patch with a Jitter approach and see if the performance improves. I bet it does.
Drag the Jitter window to the 2nd monitor and press the Esc key to go fullscreen.
 

@PEDRO SANTOS Yes, you are right about that. I wouldn't have guessed that the *size* of the panels would make a difference, but it does! It's true that it was running SLIGHTLY more smoothly in Max 8, but still not so good as to be reliable. I redid it all with Jitter and now it is working like a charm.

@JVKR I see what you mean! On this occasion I used Jitter, but I think that I will use JSUI in future. Thank you very much for your help.

panel is old and/or does something "wrong". 

i use lcd to display time-critical stuff with up to 50 fps on 20 years old computers and it works fine.

panel is old and/or does something "wrong". 

try if [lcd] is faster than panel.

i use lcd to display time-critical stuff with up to 50 fps on 20 years old computers and it works fine.


[lcd] is older than [panel] and its use has been deprecated.

Unless forced by a very specific situation, generally I wouldn't use [lcd].

[lcd] is older than [panel] and its use has been deprecated.
Unless forced by a very specific situation, generally I wouldn't use [lcd].

Prioritise a process that is (by default?) low priority