Ensuring that jit.matrix outputs an 'important' frame

    discopatrick
    Jan 13 2013 | 2:14 pm
    I'm using Jitter to convert a note-on message into something visual.
    I convert the note-on into a setcell message for a jit.matrix, bang out the output, and then immediately clear the matrix.
    At the same time I have a metro running at 20 ms which is also banging the output of the matrix. This facilitates the jit.slide object that comes further down the patch.
    The problem is this: occasionally, a note on message will fail to create the visual effect.
    One theory was that my MIDI keyboard may have been missing a note, so I hooked up the notein to a noteout to audibly monitor whether a note was being produced, and indeed it was.
    So here's another theory:
    Jit.matrix has a built in capability to ignore an incoming bang if it has received more bangs than it can process within a given time. (this is documented in a tutorial - look under the heading 'GL Objects in the Context': https://cycling74.com/docs/max6/dynamic/c74_docs.html#jitterchapter30
    So perhaps the bang between my 'setcell' and 'clear' messages is being ignored because it has come too soon after one of the bangs outputted from the metro. This is problematic because that ignored bang is highly important - it is the most important bang, because it triggers the frame that includes the colour. This is what I mean by 'important' frame.
    How then could I ensure that this important frame is always outputted?
    • Rob Ramirez
      Jan 15 2013 | 5:46 am
      maybe something like the following, which uses onebang to sync to the metro:
    • Helmuth
      Jan 15 2013 | 10:58 am
      I encountered the problem of an ignored bang in other circumstances, perhaps due to the "drop off" behaviour of the computer itselfs. In this cases, a delay of 20 - 40 milliseconds for the bang AFTER the important bang, in your case, a delayded bang for the , helped me to work around. Maybe try with different delay lenghts Let me know. Best, Helmuth
    • discopatrick
      Jan 15 2013 | 12:29 pm
      Rob, that seems to work very nicely indeed, thanks!
      Helmuth, that makes sense too. I'll keep that in mind.
    • discopatrick
      Jan 16 2013 | 11:09 pm
      So, Rob Ramirez's solution worked very well in the Max app, but I'm having the original problem again when trying the same thing in Max for Live.
      I've created a simple looped clip with four notes that triggers the patch. The visual effect is often skipped.
      I've pasted the patcher code below, and have also attached the zipped project for the convenience of anyone who may like to help.
    • discopatrick
      Jan 16 2013 | 11:46 pm
      Ah-ha - using qmetro instead of metro seems to fix the problem.
      I need to understand why this is so. And why it wasn't necessary to use qmetro in the Max app.
      I understand that Max for Live is always set to Overdrive, which is why I set the same in the Max app in order to match my target environment. And Overdrive splits the messages into two threads: scheduled and queue.
      So perhaps using metro (which produces scheduled bangs) was fine in the Max app because there wasn't much else going on in the scheduled thread. Moving to Ableton however, maybe there's a load of extra stuff happening in the scheduler and so it's safer to use a qmetro (which produces queued bangs).
      Am I close?