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!
----------begin_max5_patcher---------- 606.3oc0VssiSCCD84juBKuuFprcZtT3ID7LhGPnUBsB4lX15kDmHG2xBq1+ c7XmzKKsoofDZ2pJeYl4L9jSlwsODFfW1bunCidM5KnffGBCBbl.CA86Cv07 6Kp3ctvv0htN9sBbj2mQbuwYunRv0CVa4lhUR0seUKJL9ryXrYjHDMFFiybq ymQP2zCQV5RSyx6dU1PZ9VixzI+k.7PA3dyp00RUkv3HDamwl0lAqzdqdSle 1J7r.i2dfPxU7ZmC7a0RdEFb7XXHLD8OJGJyJj8QDlninJz33cpRFcLUI4Ej pnD+vR4+PTZ0RkA0JsxvXUJYyRhPKxAwH0ILLxwkD1kHIziJIj+KUCZAuzWL LkZh46JInjQqIXou7KJJElFE2HNqhj50Eqvjb5RB5kHH4GUPxOkfXKdwQW5z XhXumN9lgi3pO.31IIH75E4LBgPmyfcuAFt5ZXrSXZ4ZdscsUVveRVK7KseW 393VRsfA4x63DIfZ29QeaIrFfwxrJtaQDZ9XXs9weVTs8r8HmOAjw1sues1i j1y5dtlOAVaSN9cq3psIfl5lxGdHNAtDPtz7huuEXLaR.soGeMceU1Mm6n5X .y.froBTK5LMZwguuI9WG.jDR+i6P91KL+q6T1jib9jiL47QhsDu0yazM6cE gqI.WIUO8+Z3Z1A6GduQWyZcwPOwvEcncM7kVERZ6PjMp8BhdPLqjkkB092w WJ63KqDtKKHG8BroRmrmUrI4YEafShdF1v9KYiuNh21tQn65SoiH1eo4tFMr MMxsUp7acYz1QsQNDeRHjsGC+M.uMQ2f -----------end_max5_patcher-----------
actually it works for me with [deferlow]:
----------begin_max5_patcher---------- 687.3ocyWsziSCCD9b5uhHuWKqhcadAmPvYDGPnUBsB4l3s0PhSjiCagU6+c FamzWqRZBpjtUUieNi+lOOisySybPqJ1xpPtu08atNNOMywwzktCml1Nnb51 jLZkYZnU0JUg.M2NjnNunVkwTlAwM8Z6R86Rl0xnUTwZj68MCySMVpX0OdCl zZoRpJYCWr96RVhxpF1+Vu4MRhWqbmYf0lK1sz59dd1LsX9.ckbVUEcMqEAJ 1VyBiDpMtvhoKvsC9PgPIn4FGB8dImlMRJXu6qMUE+OlAvDvsdIq3cdVwyTD hMMh5hVH+Czhf8H.hWvJJ2UtRFMcrLBo2fh4tHiQGA6DcVxYoQ5iu7gLcvMo rGXxrhGuJQKAmkOBs7QvzkBkjwnxqBaD1CaPhNL2YQ3kO24U6QJ98QKXuqyQ JkRtP4VxADMVRwavddu2vXcYbfoHXwzkfnOzyFObUCKHACfcZKlt.iTF7FCp hMVNIpKNAhyzW0LthwbicOzXrM6ZgkEwKt0uufrVWnh9qVveymzHZOm3hpii Hddd3kDcq2oE2bmVVwTkTIMGpCKF5K7blsJ7O17yTECJqAgcfNL.FZ9YatYi EvjPHKwTAtjsOcgwQekkchlKGflKflerVZ0D2f5FrFM.TCFG8gMTwNCfCLEQ FY254qoKIM4m6TbAYPJBlGcG9PV1TFYfZeJFpUjLTEkrJUgjc79s9PqPqJ9d Mtaq8NXZ1s6f3gNyP7fmI47yDA.uzha26O3LBS7OJiKN8CPL4P59O9fiphZY RaNQ6GO3tOMJEXHNjgvgOOY+jhNZNa3ooLwgWfjySKKfr8FLbDBmOZHEL.Do ec+DBoSVtNvzjBI8dB9xhH3ws95PbsLNts9E.mmi4Bl1MyAvbjIEQ9u5htBe 0gHRv+YHAMdd1eg2dHff -----------end_max5_patcher-----------
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?
----------begin_max5_patcher---------- 847.3oc6X08aSCCD+4z+Jh7dsax14a3ID7LhGPnIgPH2FuUOZbhRb2FLs+2w ejzzVVS7ZCAsQ6CNw12c428ym8ctOLwALK+dZEv8Mte00w4gINN5gTC3T22A jQte9RRkVL.mdW9ra.SMSIn2KzCmRuhVtL+tlIJHh4KX7q+dIctvXeOunKfS cCgp1fPUKV9t62pUgkpsjz5miBZryU4bQE6WT0THrTGyv7UYL9RpPiIT6f4q D6NpYHwOKnFX..q+hJiyIY5I.uqjQVBTS73jIploVxHyVID479cbOXiKueGe seeLN3LB+ZoSd.tRFsphbM8OVc4hEtRTqdf52QQFeLBo6D+zdZzyYEF+ucEd Ow7B2YtkTRZ+LRhlPR76ZoO43C4wcFQL0EnQ63PNEkLtvsfIojN3GerIhIVS Pgdcdnf2wyPvwv0SoxyCHBZW9sF1tn.seiPdWDzgi6+bb73mzwi2WngbUREY 77dzUHT8LUjaa9Dm8QkdsrhKXURLFBgHerp2aUMmcopshJJHkjL46RdA7YVF 07pZ6i9m9UjTYEeYlXOF.I69IS7WsEP3HU9G0KSc86RW47fuPWtil9Vnomr6 GVUZzDUi5ZrFaApkFG79ED9ZCfB0Oh0s6Wu.EcURl+i0J5gsRQo4AWh1jk0O i0PsKEiTJhsUwRZkHujt85sZOejQkyQFuswbaHkY0NLwRAiP1JHtWAARPWXv 7AkP8vqVBACZybzc0RdupJVBZasRH7K6hkfVWqDB9+QwRv16GzcsRwutpUxl KOAs8zfvWPmFbT0NVu0wpZGwudJcrNwfkkNdpxwSUNdpxwdEDVu5BM6rrRN3 fZs.3vZOzPaP7PavS72I9an3uw6le5DXfkL9t+s45T0pw2NqeU9px4M4yZ9u scaSVmJOciIytwj2JpUnjsjYAKMkx2rHjTVEY1RpNQO7IK+vV3XCZ1Ax+MgS hEvIZTQCpOxwezfi9S0Kd7FM7DYSry3QOwVvNiG43YC4zCZxXoE4xxlqOpAg 7UE6iv5Z92rW62Y3B1vV3.wiFcFZCcBGushvAX4cXC86CMgiG4XwFQ7AhFS9 WRQwszxpZSpAh7902jWp5FNU2kwMc0VTdKhaYMxGLQYsGm7anyAtvB -----------end_max5_patcher-----------
(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…
Forums > MaxMSP