metro vs qmetro vs deferlow - explanation required

    May 12 2020 | 9:20 pm
    Hello everyone!
    I'm currently working on a patch and try to understand why I'm getting different results when triggering it from a [qmetro] or a [metro] or a [metro] followed by a [deferlow] object. I read the helpfiles and understand there is a difference in scheduling, I just can't seem to make sense why this would apply in my patch. I extracted the section in question, it's basically 3 count loops which are being triggered by a [trigger] object in the correct sequence. When triggering it manually with [bang] the following sequence of messages is generated:
    - 6 x loop1 - 96 x loop2 and 96 x loop3, alternating
    This is the result I want to achieve. However, when triggering it with a [metro] object I get the following result:
    - 6 x loop1 - 96 x loop2 - 1 x loop3
    When using [qmetro] or [metro] followed by [deferlow] I get the correct sequence. I've been scratching my head trying to understand why this is a case, so if anybody would take a moment to check out the patch this would be much appreciated!

    • May 12 2020 | 10:04 pm
      This article may be helpful.
    • May 12 2020 | 10:32 pm
    • May 13 2020 | 9:01 pm
      Thank you both for pointing me in the right direction! After reading the articles it seems that the issue with my patch is that I'm storing and reading values in a [jit.matrix] object. When I replace this with a standard Max object, I achieve the correct order of sequence. Is my understanding correct that the "getcell" message addressed to the [jit.matrix] object is never executed because the Max objects are processed in the high priority queue, and Jitter objects in the low priority queue?
    • May 13 2020 | 11:47 pm
      I think it's correct, as explained in the article under "Changing Priority".
    • May 14 2020 | 9:16 am
      Thank you for the confirmation Broc!