hm..... no.

Would this be considered to be a bug? Or at least a seriously missing item? Since Max can find and list them, it is known where they are, so it should be easy to list them with a "Patcher"-path, no?

I wonder if the problem could be fixed by limiting how many [send] and [receive] objects you're using. Using too many is generally confusing anyway. If data needs to be sent synchronously, you could [pack] or [join] it before sending, for example.

if i would be the max.app i would ask you why you need to know which is which.

what is it good for to know which menu item corresponds with which instance?

currently all the menu does is opening the patcher window in question and i would not know how to highlight the individual external.

Hi Roman Thilenius. Imagine this scenario: it is a complex (OK), it has several subpatches some of them have sub-subpatches which have a direct cable connection to the parent but inside the sub-subpatcher is a send and the signal from the parent gets mixed with something in the sub-subpatcher. Now if the feed from the parent sends a signal that turns out to be a problem, you need to find it, in that situation you need know in which patcher the subpatcher is located. If the are many subpatchers it becomes difficult to remember where the signle one is located. If I would be the max.app, I would know where the subpatcher is, since otherwise I could not work at all, so it is only to allow this info to go to the user as well. Thanks for taking care and all the best PS: I built a presentation and performance Playback patch/app and I wonder if you would be interested to check it out. It is a bit like PowerPoint on steroid (if I may say so). If you'ld like to see it, I would be happy to send you the patch. That is the one with the complex structure. Just let me know...