discopatrick

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.

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?

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

How then could I ensure that this important frame is always outputted?


ensuring-that-jit-matrix-outputs-an-important-frame

maybe something like the following, which uses onebang to sync to the metro:

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

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


Rob, that seems to work very nicely indeed, thanks!

Helmuth, that makes sense too. I'll keep that in mind.

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.

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).

Ensuring that jit.matrix outputs an 'important' frame