Forums > Dev

Finding connections / patchlines from a patcher object

September 23, 2007 | 11:25 am

Hi all,

Has someone here looked at a patcher object’s patchlines before?

I’m looking for a way to see which object(s) is(are) connected to a subpatcher. What I want to achieve resembles how tapin~ connects to tapout~ to determine tapout~’s source buffer.

If any of you has some example code, I would love to see it.

Thanks,
Mattijs


September 23, 2007 | 7:26 pm

tapin/out don’t work this way. When dsp is compiled the dsp routine in tapin sends a max message so that the tapouts get whatever info they need to access the right buffer. For this kind of thing you don’t need to examine patchcords and the like, just send the appropriate message at the appropriate time (dsp routine or whenever) between objects.

You can verify this:

#P user ezdac~ 192 76 236 109 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 110 109 32 196617 print;
#P newex 110 75 71 196617 tapin~ 12323;
#P connect 0 0 1 0;
#P window clipboard copycount 3;

Turn on dsp and you’ll see the message tapconnect in the max window. To see the rest of the message you’d need to use something different from the print object (CNMAT’s printit)….

Regards,

Alex


September 24, 2007 | 11:22 am

Ah! Thanks a lot Alex.

Nonetheless I’d be interested in a way to scan the connections to/from any object and get the pointers to objects that connect to my external. Has anyone ever done this? Is it supported at all by the API?

Cheers, Mattijs

Quote: AlexHarker wrote on Sun, 23 September 2007 21:26
—————————————————-
> tapin/out don’t work this way. When dsp is compiled the dsp routine in tapin sends a max message so that the tapouts get whatever info they need to access the right buffer. For this kind of thing you don’t need to examine patchcords and the like, just send the appropriate message at the appropriate time (dsp routine or whenever) between objects.
>
> You can verify this:
>
> #P user ezdac~ 192 76 236 109 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 110 109 32 196617 print;
> #P newex 110 75 71 196617 tapin~ 12323;
> #P connect 0 0 1 0;
> #P window clipboard copycount 3;
>
> Turn on dsp and you’ll see the message tapconnect in the max window. To see the rest of the message you’d need to use something different from the print object (CNMAT’s printit)….
>
> Regards,
>
> Alex
—————————————————-


September 24, 2007 | 10:31 pm

Is this related to the oo stuff? Why do you need to know what’s connected?

Once you have the patcher saved into a binbuf, I think "connect 4 0 8 0" means connect the first outlet of object 4 to the first inlet of object 8. The numbering appears to run backwards from the last object before the first connect, beginning at zero. Segmented patchcords use "fasten".

A patcher structure will be broken up by nested subpatchers (#N vpatcher to #P pop), so counting the object numbers will need to skip those.

Then you have to try to relate the position and type of what you’ve found back to the patcher’s box positions, iterating over the patcher’s box linklist, testing each box’s b->b_rect for position and calling ob_name() to check type. When found, b->b_firstin is (hopefully) your pointer.

The oo patcherargs code you have does most of this, you’d just need to add the connection parsing. Beware objects of the same type with the same position, I’ve not found a way to distinguish those.


September 25, 2007 | 10:58 am

Thanks John, wow, I almost forgot you actually implemented these idea’s. I am not sure I have the oo patcherargs code you mention. It’s not in the latest version of your oo objects, right?

Since there is no ‘proper’ way to access the patcher object’s connections I guess your idea could be a good way to test the concept I’m thinking about.

It is related to the oo stuff, yeah. I had a little idea of which I was trying to find out the pros and cons. The idea is to place the definition of an object outside its subpatcher. A quick sketch:

— save as oo.object:

#P outlet 181 128 15 0;
#P inlet 181 40 15 0;
#P outlet 81 128 15 0;
#P inlet 81 40 15 0;

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 349 155 292 196617 Con:;
#P comment 45 155 285 196617 Pro:;
#P comment 348 171 292 196617 – how to implement? Maybe put oo.class object inside [p Pad]?;
#P window linecount 3;
#P comment 45 187 285 196617 – paste-replace support (i.e. if I modify one copy of Pad I can paste-replace the other copies) without depending on subpatcher arguments , attributes or object name;
#P window linecount 1;
#P comment 45 171 285 196617 – more visual resemblance with code;
#N vpatcher 233 471 833 871;
#P inlet 41 60 15 0;
#P window setfont "Sans Serif" 9.;
#P comment 41 79 127 196617 constructor arguments;
#P pop;
#P newobj 324 95 34 196617 p Pad;
#P newex 45 95 276 196617 oo.object myPad3 1.62 tony this.pathfinder @access public;
#N vpatcher 233 471 833 871;
#P inlet 41 60 15 0;
#P window setfont "Sans Serif" 9.;
#P comment 41 79 127 196617 constructor arguments;
#P pop;
#P newobj 324 75 34 196617 p Pad;
#P newex 45 75 275 196617 oo.object myPad2 2.72 john this.pathfinder @access public;
#N vpatcher 452 291 1052 691;
#P inlet 41 60 15 0;
#P window setfont "Sans Serif" 9.;
#P comment 41 79 127 196617 constructor arguments;
#P pop;
#P newobj 346 55 34 196617 p Pad;
#P newex 45 55 298 196617 oo.object myPad1 3.14 margaret this.pathfinder @access public;
#P comment 388 55 305 196617 public Pad myPad1 = new Pad (3.14 , margaret , this.pathfinder) ;;
#B color 13;
#P window linecount 4;
#P comment 45 228 285 196617 – less scan time for objects inside [p Pad] to find out whether [p Pad] is an object (no need to parse all objects inside [p Pad]). Of course only if the subpatcher’s connections can be read in a convenient way (which doesn’t seem to be the case).;
#P window linecount 1;
#P comment 13 25 100 196617 Just a quick sketch;
#P connect 5 1 6 0;
#P connect 3 1 4 0;
#P connect 7 1 8 0;
#P window clipboard copycount 14;

Quote: johnpitcairn wrote on Tue, 25 September 2007 00:31
—————————————————-
> Is this related to the oo stuff? Why do you need to know what’s connected?
>
> Once you have the patcher saved into a binbuf, I think "connect 4 0 8 0" means connect the first outlet of object 4 to the first inlet of object 8. The numbering appears to run backwards from the last object before the first connect, beginning at zero. Segmented patchcords use "fasten".
>
> A patcher structure will be broken up by nested subpatchers (#N vpatcher to #P pop), so counting the object numbers will need to skip those.
>
> Then you have to try to relate the position and type of what you’ve found back to the patcher’s box positions, iterating over the patcher’s box linklist, testing each box’s b->b_rect for position and calling ob_name() to check type. When found, b->b_firstin is (hopefully) your pointer.
>
> The oo patcherargs code you have does most of this, you’d just need to add the connection parsing. Beware objects of the same type with the same position, I’ve not found a way to distinguish those.
>
>
—————————————————-


September 25, 2007 | 11:35 pm

Quote: Mattijs wrote on Tue, 25 September 2007 22:58
—————————————————-
> It’s not in the latest version of your oo objects, right?

obj_findAndProcessPatcherArgs() in oo.object.c

Note the parentpatcher and its saved binbuf get statically cached. This is then compared to the current parentpatcher to avoid saving an identical binbuf as much as possible. I tested this, it really cuts the load time down.

> It is related to the oo stuff, yeah. I had a little idea of
> which I was trying to find out the pros and cons. The idea is
> to place the definition of an object outside its subpatcher. A
> quick sketch:

> more visual resemblance with code

I’m not convinced there’s much wrong with [p 3.14 margaret this.pathfinder @public myPad1] ? The definition is right there on the object container, and there’s only one object.

I don’t think regular arguments should be used to name the object, this may require extra effort to oo.object-ify existing patches (existing arg numbers will move). That’s why the name is part of the @ access attribute at present.

> less scan time for objects inside [p Pad] to find out whether
> [p Pad] is an object (no need to parse all objects inside [p
> Pad]). Of course only if the subpatcher’s connections can be
> read in a convenient way (which doesn’t seem to be the case).

That’s the problem. I think using a separate connected object definition is probably going to be slower than putting the definition in the containing patcher args, because you’ll still have to save and parse the parent patcher’s object types and positions (as the current version does to find the object patcher args), and you need to find two objects and a connection, not one.

> paste-replace support (i.e. if I modify one copy of Pad I can
> paste-replace the other copies) without depending on
> subpatcher arguments, attributes or object name

Good point. But this applies to Max programming generally, not just our oo implementation. I’ve been wanting a "paste-replace, keep arguments" command for some time. Is there a feature request in for Max 5?


September 26, 2007 | 5:40 am

Quote: johnpitcairn wrote on Wed, 26 September 2007 01:35
—————————————————-
> > paste-replace support (i.e. if I modify one copy of Pad I can
> > paste-replace the other copies) without depending on
> > subpatcher arguments, attributes or object name
>
> Good point. But this applies to Max programming generally, not just our oo implementation. I’ve been wanting a "paste-replace, keep arguments" command for some time. Is there a feature request in for Max 5?

Good point :)


Viewing 7 posts - 1 through 7 (of 7 total)