Cycling 74 » Topic: List of all send and receive names http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/feed Wed, 19 Jun 2013 01:33:40 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-60926 <![CDATA[List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-60926 Fri, 30 Dec 2011 12:38:56 +0000 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?

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219388 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219388 Sat, 31 Dec 2011 18:59:53 +0000 Roman Thilenius sounds like a job for an internal object

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219389 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219389 Sat, 31 Dec 2011 21:26:55 +0000 Chris Muir 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219390 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219390 Sat, 31 Dec 2011 21:50:56 +0000 woyteg that would be really helpful!

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219391 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219391 Sat, 31 Dec 2011 23:28:01 +0000 dhjdhjdhj 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219392 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219392 Sun, 01 Jan 2012 01:55:12 +0000 woyteg 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219393 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219393 Sun, 01 Jan 2012 04:58:56 +0000 Roman Thilenius 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.

-110

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219394 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219394 Sun, 01 Jan 2012 05:41:27 +0000 dhjdhjdhj 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219395 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219395 Sun, 01 Jan 2012 06:44:33 +0000 Roman Thilenius why do it simple when you can have it complicated

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219396 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219396 Sun, 01 Jan 2012 08:07:36 +0000 dhjdhjdhj 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!

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219397 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219397 Sun, 01 Jan 2012 12:09:46 +0000 waj @c74

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

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219398 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219398 Sun, 01 Jan 2012 19:40:22 +0000 Luke Hall 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.

Any comments would be glady received!

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
]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219399 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219399 Sun, 01 Jan 2012 22:29:23 +0000 dhjdhjdhj 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219400 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219400 Mon, 02 Jan 2012 00:27:19 +0000 Luke Hall 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219401 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219401 Mon, 02 Jan 2012 01:11:03 +0000 dhjdhjdhj 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
[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

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!)

Does that help?

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219402 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219402 Mon, 02 Jan 2012 01:35:47 +0000 Luke Hall 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219403 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219403 Mon, 02 Jan 2012 02:18:05 +0000 dhjdhjdhj 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.

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219404 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219404 Mon, 02 Jan 2012 10:16:01 +0000 pid cmnd-f works pretty well for me

]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219405 <![CDATA[Re: List of all send and receive names]]> http://cycling74.com/forums/topic/list-of-all-send-and-receive-names/#post-219405 Mon, 02 Jan 2012 10:47:24 +0000 dhjdhjdhj 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)?

]]>