[thispatcher] problem
|
Feb 1, 2010 at 5:44pm
[thispatcher] problemMessages 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.. ?
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Feb 1, 2010 at 6:09pm
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… |
|
|
Feb 1, 2010 at 6:26pm
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 ! |
|
|
Feb 1, 2010 at 7:00pm
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 ! |
|
|
Feb 1, 2010 at 8:02pm
[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. |
You must be logged in to reply to this topic.