dhjdhjdhj

Isnthere a way to get a list of all send and receive names that are currently instatiated? This would be very helpful for debugging?

list-of-all-send-and-receive-names

sounds like a job for an internal object


You probably know this, but if you just want to see a list of a specific s/r name you can double-click on a send/receive object.

I believe that just shows you the corresponding objects for the particular name and the names of the patchers in which they live. The issue is how to easily find out what send/receive objects are available whe you don't actually know the name.

Actually i am dreaming of a more or less similar overview function:

I would love kind of a tree diagram for patchers subpatchers bpatchers and so on.

Working on big patches i often have to think: ahh where did i do that..

And if it's in a reasonably named patcher this structural overview would help a lot.

Similary this overview of all send and receive objects as a list.

These things would really ease working on big projects.

Actually i am dreaming of a more or less similar overview function:
I would love kind of a tree diagram for patchers subpatchers bpatchers and so on.
Working on big patches i often have to think: ahh where did i do that..
And if it's in a reasonably named patcher this structural overview would help a lot.
Similary this overview of all send and receive objects as a list.

These things would really ease working on big projects.


of course one could try to build abstractions for "send" and "receive" which do know about their names and tell all other instances of this abstraction about it, so that every send abstraction knows what "receive" abstractions are around.

That seems like a very complicated and messy approach that, by the way, would instantly fail as soon as a patcher was used that contained a regular send/receive object in it, either by mistake, or by the use of some older patcher you build that doesnt have the new abstraction, or because you downloaded or otherwise got hold of a third party library or tool that uses them. Then you immediately have the original problem again.

Since the list of currently available send/receive names must exist globally, it seems to me that another object could be added to that group (send,receive, forward) that just sends out the list of all names when banged.

why do it simple when you can have it complicated

I'm confused. Seems to me that creating a single object that can return a list of all known names and works with existing patchers created by anyone in the max community is much simpler than having to design, implement, and manage an entirely new set of conventions that wouldn't in fact solve the debugging problem in the first place.

But perhaps I'm just hungover from new year celebrations!

I'm confused. Seems to me that creating a single object that can return a list of all known names and works with existing patchers created by anyone in the max community is much simpler than having to design, implement, and manage an entirely new set of conventions that wouldn't in fact solve the debugging problem in the first place. 

But perhaps I'm just hungover from new year celebrations!


why not to have the double-click thing for send~/receive~ as for send/receive?

The following javascript will load the patch data as JSON and output the names of all send/receive/send~/receive~ objects in the same level of your patcher. I'm working on a version that will recurse through subpatchers which should turn out to be a little bit more useful. The obvious caveats are that the patch must be a saved maxpat file (so there is some JSON to read) and therefor it can't be a collective or standalone.

Drop it in to your patch, send it the "init" message to load in the data and then bang it to output the names of these objects.

autowatch = 1;

var memstr;

function loadbang() {
    if(!max.loadbangdisabled) {
        init();
        outlet(1,this.patcher.filepath);
        outlet(1,1);
    }
}

function init() {
    memstr = "";
    data = "";
    maxchars = 800;
    target = this.patcher.filepath;
    f = new File(target,"read");
    f.open();
    if (f.isopen) {
        while(f.position


Thanks for providing this. Unfortunately it doesn't really address the issue, even with a recursive option. I had already considered writing a simple command line grep script that would just find all the names but apart from the issue that patchers aren't necessarily all living in a single tree, the real question is to determine what send/receive names are "live", that is, the list of names that are found just in patchers that are open. For example, if [send xyz] doesn't appear to be working, then what one needs is a list of names associated with just active [receive ] objects.

Thanks for providing this.  Unfortunately it doesn't really address the issue, even with a recursive option. I had already considered  writing a simple command line grep script that would just find all the names but apart from the issue that patchers aren't necessarily all living in a single tree, the  real question is to determine what send/receive names are "live", that is, the list of names that are found just in patchers that are open. For example, if [send xyz] doesn't appear to be working, then what one needs is a list of names associated with just active [receive ] objects.


I'm not sure I understand what you mean by "active" receive objects. Are you saying that if you try to create a [receive] object but there are no similarly named [send] objects (and vice versa) then this instance is not "live"? I do see the problem with objects being in separate patches which would communicate but could not be read from the JSON.

By active, I mean a send or receive object that is in a patcher (including its contained abstractions) that is currently loaded/running. (NB whenever I refer to a patcher, I will always mean a patcher + its nested abstractions)

Here are some scenarios that may help to explain the motivation

1) Suppose I have a patcher containing [send xyz1] in it and I determine that it's not working properly. If I could get a list of all the [receive] objects that are in patchers that are loaded, I could quickly find out (for example) that there's no [receive xyz1] anywhere, but there is in fact a [receive xyz2]. With that information, I can quickly determine if my [send xyz1] should have actually been a [send xyz2]. A generic list of all send/receive names in all the patchers on my file system would not help me because there might very well be a [receive xyz1] in some other patcher.

2) In general, my send/receive objects often include arguments. For example, I recently built a multi-channel mixer using a basic abstraction that implements individual channel-strips with effect sends. The volume slider in each channel strip of the mixer is accessible remotely because it contains

Now, when I instantiate a mixer, an abstraction is instantiated for each channel which means that at runtime, there will be multiple receive objects such as

A search through JSON or grep would only reveal the single #1_StripVolume name but I want to be able to see that there are three instantiated names (and if there aren't, there's a bug somewhere!)

2) In general, my send/receive objects often include arguments. For example, I recently built a multi-channel mixer using a basic abstraction that implements individual channel-strips with effect sends. The volume slider in each channel strip of the mixer is accessible remotely because it contains
   [receive #1_StripVolume]
Now, when I instantiate a mixer, an abstraction is instantiated for each channel which means that at runtime, there will be multiple receive objects such as
   [receive 1_StripVolume]
   [receive 2_StripVolume]
   [receive 3_StripVolume]
etc

The javascript I posted does not look through all the patches on your filesystem, it just looks in the file that you have th [js] object instantiated in. So if your projects are self contained (which is unlikely) then it should help you find send/receive names that are used/available. I see the problem with the use of abstractions and [bpatcher]s etc though, also I can't see a way to overcome the variable names obstacle using this method.

It looks like you might be right and a true external might be needed to provide this information, but seeing as I have no experience in external building I have no idea if it would be possible, it would definitely be useful in many situations though, I've often wished for a send/receive autocomplete that uses the currently used names as suggestions.

I've only built the basic example myself. I don't know how isolated is this stuff....for example, it would not surprise me if the information was held in a singleton defined in a class shared only by the Send/Receive objects and other parts of Max don't even know about it. That would mean that this new feature could only be added by the developer of the original send/receive mechanism.

I don't understand --- how does that help you to find an item whose name you might not know (and in a patcher or abstraction other than the one where you open a search)?

List of all send and receive names