click the "b" message box. Since there is @triggers 1, the stack should not overflow!
----------begin_max5_patcher---------- 403.3ocyT1sSCBCEG+Z3onoWiKT1XC8J84vXLEni0Enkz1Mmtr2coGfISYFT ma6lSx4+4v4iez1stN3X4FlFitC8HxwYqqiCHYEbZ7cvEzMI4TMjFVvdQFuD 6UGxv1X.YCR2pwSAkprtIpUatTXDzBFD4AEml2FQrpPtxjyLP4IMp0RlWKY0 yFFidpSoz72f.jfQ9MxkTSxBtH6YEKwT+QSlUEEEQr1fwf0ej+9BU0YtXeis Z6bcsFuAhhBlVSyXegEw8PhYWTRDDBnHDPQnu0RhNFJBNgnXdOnH7hhBheGT LNXT3+LJ5r3iuFVbBA17ISBO8mBNxaCIxhXtfglKknXpBcuQwyxXJMhzCkH+ TJEbTJ48mHU8CGjo298ubzETPF37pk8SuoBcwpeH8zxUpj1wsY4QezmTl1vE TCWJ5jSzA4rfmlxfvsaTJWSiyY.Q868u3PmlnALMjy1zLD1TcECQNKSS3UEa lMvo42vl5C0zxx0UWYaJILHUW9WJUV2odfKWT6BUDqXq4s4G4Zq1N22AGyU6 V. -----------end_max5_patcher-----------
OSX 10.6.7, Max6.0.8
(dev note: this seems to me related to the fact that proxy_getinlet() returns 1 instead of 0 in this recursive context)
don’t know if this is relevant, but a deferlow between the output of the combine and the trigger stops the recursion
@andrea proxy based object doesn’t support recursion. When you enter the combine object from the right inlet, you are in the outlet call of message "b", when you enter the combine object it’s from inlet 1 and everything which is happening after is still coming from the original message so, for combine you’re still using the inlet 1, which triggers.
@Terrry: that’s a good way to avoid the recursion indeed.
Salut Manu ;)
Yes, that’s what I feared… but recursion actually works with proxy-based objects, as long as the main inlet doesn’t come into play… no hope to have that working for the main inlet as well in some future release? And no other way to tell if a message is coming from the main inlet, instead of a proxy? (maybe this should be moved to the Dev forum though…)