Abstraction, within abstraction, within abstraction, . . .

Aug 30, 2013 at 10:37am

Abstraction, within abstraction, within abstraction, . . .

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

#263758
Aug 30, 2013 at 10:59am

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

#263759
Aug 30, 2013 at 11:05am

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 ?

#263760
Aug 30, 2013 at 11:39am

isn’t there a problem with the blank spaces ?

#263764
Aug 30, 2013 at 11:40am

I tried it both ways, and neither works.

#263765
Aug 30, 2013 at 12:11pm

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]

#263766
Aug 30, 2013 at 12:58pm

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. –
#263770
Aug 30, 2013 at 1:24pm

Try this abstraction :

<code>

– Pasted Max Patch, click to expand. –

</code>

#263773
Aug 30, 2013 at 3:34pm

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
#263780
Aug 30, 2013 at 4:26pm

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.

#263784
Aug 30, 2013 at 6:32pm

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

Thanks again,
Glennzone

#263790
Aug 30, 2013 at 7:40pm

$uper.

#263792

You must be logged in to reply to this topic.