[thispatcher] problem
Messages to be sent to [thispatcher] are stored in a coll. [line] triggers them out of the coll, and the message is passed to [thispatcher]. This works fine. But as a smaller part of a larger patch, this crashes max every time. In the larger patch, [thispatcher] has a handful of other messages connecting to it, but none triggering simultaneously with the disconnect messages. Any advice on what how I’m making max angry.. ?
hard to say without seeing the entire patch (plus I am not an expert on thispatcher). however I would question the use if line in this example. since the time-grain of your line is 20 msec, each disconnect message is sent out multiple times… maybe you are getting things crossed from other parts of the patch?? try using counter or uzi and see if it improves stability. if you are hellbent on line put a change object in between line and coll or calculate the proper time-grain…
Good point about the grain time. If you connect the message box to [print] you can see that many messages are sent. Uzi works in principle, but i’m still crashing my patch sending the messages to [thispatcher]. i’ll look into my other issues…. Thank you for the quick advice !
I think I’ve traced the problem. Your [line] advice was entirely correct. Not only was I sending several duplicate messages, but one of the messages was impossible for thispatcher to execute. I was basically asking thispatcher to make a disconnection that didnt exist in the first place because of the format of a sprintf message. And the incorrect message was sent like 10 times… thanks for pointing me in the right direction !
[trigger] and [defer] might also help when you’re dealing with tons of commands sent very fast. sometimes you need a more explicit order-of-operations (trigger) when certain things take a bit of time, and sometimes you need to allow a command to wait a bit (defer) before executing. I’d imagine this is the case with lots of scripting messages.