Martin Beck

It would help a lot to have a subscribe message for [mtr] in order to bind to objects - similar to pattrstorage.

The "bindto attribute" does not work with message sequences like this 

instead you are forced to create messages like "bindto 1 s1 2 s2 3 s3", which leads to a lot of unnecessary patching logic if you have many bindto targets whose names are not readily available as a single list as it happens e.g. with parameters that are contained in multiple instances of bpatchers and you create the scripting name path by [iter] and [sprintf] objects.

It would help a lot to have a subscribe message for [mtr] in order to bind to objects - similar to pattrstorage.
The "bindto attribute" does not work with message sequences like this 
"bindto 1 s1, 
bindto 2  s2,
bindto 3  s3"

It would help a lot to have a subscribe message for [mtr] in order to bind to objects - similar to pattrstorage.
The "bindto attribute" does

-feature-request-mtr-subscribe-message-similar-to-pattrstorage

Looks to me like it's working. I tried with this:

Thank you for taking a look. With your patch it works for me too. I guess I got confused while figuring out this [mtr] bug 

https://cycling74.com/forums/-bug-mtr-bindto-on-patch-startup-causes-problems

Thank you for taking a look. With your patch it works for me too. I guess I got confused while figuring out this [mtr] bug https://cycling74.com/forums/-bug-mtr-bindto-on-patch-startup-causes-problems .

mtr - bindto similar to subscribe message in pattrstorage