andrea agostini

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 "read, nth 0", I open "test67.mid", 60 and 62 are output (not 67 and 69, as expected)

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

Hi.
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!

bug-with-detonate

actually it works for me with [deferlow]:

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

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

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

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. 

bug with detonate?