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

    Feb 13 2019 | 11:19 am
    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.

    • Feb 13 2019 | 12:47 pm
      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.
    • Feb 13 2019 | 12:57 pm
      In a similar situation I opted for JSUI. Depending on OS and Max version you may also want to try mgraphics/jitter.
    • Feb 13 2019 | 1:35 pm
    • Feb 13 2019 | 2:38 pm
      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...
    • Feb 13 2019 | 4:35 pm
      It's not that difficult in JS. An example is included. By the way, Max8 has improved graphics performance.
      Save this as flash.js:
      var black = [0., 0., 0., 1.];
      var white = [1., 1., 1., 1.]
      function loadbang() {
      function set() {
      function reset() {
      function draw(color)
      	with (sketch) {
      Save this patch in the same location:
    • Feb 13 2019 | 5:57 pm
      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.
    • Feb 13 2019 | 6:12 pm
      @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.
    • Feb 13 2019 | 6:13 pm
      @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.
    • Feb 13 2019 | 8:56 pm
      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.
    • Feb 14 2019 | 3:13 am
      [lcd] is older than [panel] and its use has been deprecated. Unless forced by a very specific situation, generally I wouldn't use [lcd].