Abstraction, within abstraction, within abstraction, . . .

    Glennzone
    Aug 30 2013 | 5:37 pm
    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
    • vichug
      Aug 30 2013 | 5:59 pm
      er, this should work as expected. It seems a bit a specific issue to be able helping without an example patch..
    • Glennzone
      Aug 30 2013 | 6:05 pm
      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 ?
    • vichug
      Aug 30 2013 | 6:39 pm
      isn't there a problem with the blank spaces ?
    • Glennzone
      Aug 30 2013 | 6:40 pm
      I tried it both ways, and neither works.
    • Roman Thilenius
      Aug 30 2013 | 7: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]
    • Glennzone
      Aug 30 2013 | 7: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
    • vichug
      Aug 30 2013 | 8:24 pm
      Try this abstraction :
    • Glennzone
      Aug 30 2013 | 10: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
    • vichug
      Aug 30 2013 | 11: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.
    • Glennzone
      Aug 31 2013 | 1:32 am
      Thanks V. That does work. It's a little more cumbersome than expected, but it works.
      Thanks again, Glennzone
    • Roman Thilenius
      Aug 31 2013 | 2:40 am
      $uper.