Forums > MaxMSP

Abstraction, within abstraction, within abstraction, . . .

August 30, 2013 | 10:37 am

I’m using nested abstractions with their own send\receive object pairs, and these pairs are using #1, #2 and #3 within the name of the send\ receive object pairs. The main patch has a few occurrences of an abstraction, each of which has a few occurrences of another abstraction, which each contain a few occurrences of another abstraction.

A few months back I could swear I had all this working properly, but it’s not now.

Any insights into exactly how this should be done ? I would imagine I’m missing something here, but still learning along the way.

Thanks,
Glennzone


August 30, 2013 | 10:59 am

er, this should work as expected. It seems a bit a specific issue to be able helping without an example patch..


August 30, 2013 | 11:05 am

I need to mention that the abstractions in the main patch use #1 in the name of the send\receive objects,
the abstractions within those use #1 and #2,
and those within those #1, #2, and #3.
So at the deepest level the naming of the send\receive objects is basically like #1(DeviceID), #2(Bank), #3(Channel)something.

Example send object name : "s 1816processor"
In this case, DeviceID = 1, BankID = 8, ChannelID = 16

In the deepest abstraction, the send object would be "s #1 #2 #3processor"

Thoughts ?


August 30, 2013 | 11:39 am

isn’t there a problem with the blank spaces ?


August 30, 2013 | 11:40 am

I tried it both ways, and neither works.


August 30, 2013 | 12:11 pm

In the deepest abstraction, the send object would be "s #1 #2 #3processor"

somehow i doubt that this was working before.

with spaces the name of the [s] would be only "#1" and without spaces the #2 wont function as argument because it is not at the beginning.

you might want to switch to

[loadbang]
[int #1] [int #2] [int #3] [t processor]
[sprintf %s%s%s%s]
[prepend set]
[forward]


August 30, 2013 | 12:58 pm

Hi Roman,

I tried to understand what you’re suggesting, and created a patch with an abstraction here:

Could you modify this so it works ? I don’t really understand what you’ve got there.

Thanks,
Glennzone

– Pasted Max Patch, click to expand. –

August 30, 2013 | 1:24 pm

Try this abstraction :

<code>

– Pasted Max Patch, click to expand. –

</code>


August 30, 2013 | 3:34 pm

Boy, I must really be missing something on this V. This doesn’t do anything at all on my system.

I saved that patcher as an abstraction, created a parent patcher to put that into, and put in the arguments as I would expect to do with the #1, #2 variables. Save, close, open, . . . no magic. Is there something I’m missing here ?

Attached is a graphic of what I have :

Thanks,
Glennzone

Attachments:
  1. AbstractionTesting2

August 30, 2013 | 4:26 pm

ah, sorry, you might have more luck wiht #1 #2 instead of $1 $2 :s also those [r] are [receive] object so you must have [send] objects named the same to test this correctly. (in this case, one [send MB16] and one [send MB16_else] a priori) (but maybe they are hidden by the abstraction window in your patch :) )

in PureData there is no #1 #2 #0 etc, only $1 $2 $0 etc, and the logic is slightly different, that’s why i tend to mix these.


August 30, 2013 | 6:32 pm

Thanks V. That does work. It’s a little more cumbersome than expected, but it works.

Thanks again,
Glennzone


August 30, 2013 | 7:40 pm

$uper.


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