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
er, this should work as expected. It seems a bit a specific issue to be able helping without an example patch..
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 ?
isn't there a problem with the blank spaces ?
I tried it both ways, and neither works.
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]
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
Try this abstraction :
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
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.
$uper.