bug with detonate?

Jul 9, 2012 at 8:05pm

bug with detonate?

I have met a weird behavior with detonate, in both Max 5 and 6. Here’s the thing (see patch below, and files attached):

I have two midi files, one (test60.mid) starting with a midinote 60, the other (test67.mid) with a 67.
I click “read, nth 0″, I open “test60.mid”, nothing happens (I expect 60 and 62 output from the pitch outlet).
I click “nth 0″, 60 and 62 are output.
I click “read, nth 0″, I open “test67.mid”, 60 and 62 are output (not 67 and 69, as expected)
I click “nth 0″, 67 and 69 are output.
And so on.
Putting a deferlow object after the “read, nth 0, nth 1″ message box doesn’t help (this was my only hope, in case the read operation was deferlow-ed inside detonate).
It looks to me like the file is not actually loaded until past the event containing the “read” message…
… I’d call this a bug!


– Pasted Max Patch, click to expand. –
  1. miditest.zip
Jul 9, 2012 at 9:03pm

Hi Andrea,

actually it works for me with [deferlow]:

– Pasted Max Patch, click to expand. –


Jul 9, 2012 at 9:12pm

Thank you Ádám, it works !

But I still don’t understand: neither of these version works… but once the message has been deferlow-ed the evaluation order should be preserved in any case, as the message itself is put at the tail of the queue, shouldn’t it? Or maybe I’m not seeing something obvious…

What do you think?

– Pasted Max Patch, click to expand. –
Jul 9, 2012 at 9:13pm

(I mean, neither of the two versions I have pasted in my last reply works…)

Jul 10, 2012 at 5:05am


If you have a look with shark you can see that detonate_import seems _always_ deferlow-ed and the detonate_doimport call occurs in the main thread even banged in timer thread. In this case i’m not sure the order is guaranteed, it may depend of concurrency.

# Report 0 – Session 1 – Time Profile of MaxMSP.mshark – Time Profile of MaxMSP
# Generated from the visible portion of the outline view
- 68.9% detonate_doimport (detonate)
+ 21.6% detonate_nth (detonate)
| + 21.6% detonate_sendevt (detonate)
| | + 21.6% outlet_int (MaxAPI)
| | | – 21.6% outlet_int (MaxMSP)
+ 9.5% detonate_import (detonate)
| + 9.5% defer_low (MaxAPI)
| | + 9.5% defer_low (MaxMSP)
| | | – 1.4% qelem_set (MaxMSP)
| | | 1.4% object_alloc (MaxMSP)
| | | 1.4% lockout_set (MaxMSP)
| | | – 5.4% getbytes (MaxMSP)

– Pasted Max Patch, click to expand. –
  1. detonate
Jul 10, 2012 at 6:52am

Ugh. I see the problem now. I was definitely sleepy hier soir ;)

Let’s take the example on the left, in the last patch I posted:
button outputs a bang in the main thread (it is triggered by the mouse)
“read” is issued in the main thread, and is deferlowed. It becomes the nth event in the queue.
“bang” is issued in the main thread, and is deferlowed. It becomes the (n+1)th event in the queue.
the nth event in the queue is reached. detonate receives “read”. It deferlows the “doimport” method. The method call becomes the (n+2)th event in the queue.
the (n+1)th event is reached. the message box receives a bang, outputs its messages, detonate receives “nth 0″ and “nth 1″ and outputs the contents of the MIDI sequence it contains (that is, the “old” one!)
the (n+2)th event is reached. the “doimport” method is executed and only now the “new” MIDI sequence is loaded.

So ok, technically it’s not a bug. But sure it looks like one.

I imagine myself some years ago, before diving into the joys of the Max SDK, trying to cope with this problem. I simply wouldn’t get it. Someone more experienced than me would have posted the solution in the forum (thanks again guys btw ;) ) and I would take it for granted, and be utterly puzzled.

I think this kind of behavior (which methods are deferred? which are deferlow-ed?) should be better documented, and the whole mechanism of defer and deferlow would deserve a much more thorough explanation, with examples and everything. These asynchronous mechanisms are maybe the single less intuitive thing within Max…


Jul 10, 2012 at 8:20am


Yep ; i agree : sure that 99 % of my headaches comes from main / timer thread artefacts.

And something make me mad too is that in an external every method you implement must be multihtreaded as it can always be called from main or timer thread : i suppose that is the price to be paid to merge all that streams (UI / commands / MIDI / audio / and video) in a unique software.


You must be logged in to reply to this topic.