Ensuring that jit.matrix outputs an 'important' frame

Jan 13, 2013 at 2:14pm

Ensuring that jit.matrix outputs an 'important' frame

I’m using Jitter to convert a note-on message into something visual.

– Pasted Max Patch, click to expand. –

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’: http://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?

#66042
Jan 15, 2013 at 5:46am

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

– Pasted Max Patch, click to expand. –
#237764
Jan 15, 2013 at 10:58am

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

#237765
Jan 15, 2013 at 12:29pm

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

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

#237766
Jan 16, 2013 at 11:09pm

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.

– Pasted Max Patch, click to expand. –
#237767
Jan 16, 2013 at 11:46pm

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?

#237768

You must be logged in to reply to this topic.