why no scoping for send/receive objects?


    May 09 2006 | 6:15 pm
    I am repeatedly vexed by the lack of scoping for send/receive objects. It seems like if i make a patcher that sends stuff inside itself, and then i duplicate that patcher, that it ought to be the norm that the two patchers won't communicate. If not the norm, then at least send/receive objects could take a second argument to prevent global scope (or if it were the norm, then an argument to specify global).
    Is there some technical reason why this has not already been implemented?

    • May 09 2006 | 6:27 pm
      It works with abstractions, but not with patchers. Use send~ #0.foo and receive~ #0.foo for instance. The #0 gets replaced with a four digit unique random number at instantiation.
      Peter McCulloch
    • May 09 2006 | 6:31 pm
      Use #0name for local namespaces. Otherwise namespace for send/receive/ table/coll/buffer~./etc is global. Arguments for both designs, but this is the one Miller chose for simplicity's sake while having multiple patchers loaded which intercommunicate.
      For more info on the subject of #0, please consult the manual and mailing list archives.
      -Joshua
    • May 09 2006 | 6:47 pm
      if you make sends which communicate only inside the patcher, they communicate only inside the patcher, seems like the exspected behaviour.
      if you want to send stuff elsewhere (to a copy of the patcher) you have to use sends which do not only communicate inside the patch.
      ...
    • May 09 2006 | 6:57 pm
      how do i make sends which communicate only inside the patcher? that is what, but so far as i know, it is not possible.
    • May 09 2006 | 7:00 pm
      didn't see joshua's email, am looking into it...
    • May 09 2006 | 7:11 pm
      "It works with abstractions, but not with patchers." So there's no way to achieve scoping for patchers? I'm trying to figure this out with the manual too, but am having trouble.
    • May 09 2006 | 7:12 pm
      Try using "pvar"
      Peter McCulloch
    • May 09 2006 | 7:16 pm
      ok i get it now. I can use the #1 object to do it with patchers if i supply an argument to the patcher object. this will do.
      thanks :)
    • May 09 2006 | 8:01 pm
      Quote: george.locke.maxmsp wrote on Tue, 09 May 2006 13:11 ---------------------------------------------------- > "It works with abstractions, but not with patchers." So there's no way to > achieve scoping for patchers? I'm trying to figure this out with the manual > too, but am having trouble.
      again: s, send, send~, buffer~, coll, and similar objects with unique names as arguments _are always working through the whole runtime, even between collectives and patches if you want, or
      it is _only neccesary to do something (which is such a very secret that i wont tell you) when you _dont want this.
      if it does not work for you to send from a [s thing] to a [r thing] in another patcher window, then something else is wrong but not your sends.
    • May 09 2006 | 9:58 pm
      i thought i had figured it out but no.
      Roman, what i'm trying to do is prevent the global scope of send and receive objects. I need to know the special secret >:0
      It seems like the #1, #2, etc trick only works for abstractions and not for patchers. However i like patchers, i prefer working with them.
      i'm looking at pvar, and it seems to work pretty well, but it doesn't send to subpatchers. pv might work, but i have to send it a bang message in order to get a value from it. If that's what i have to do then i'll have to send a bang along some global variable that sends to all pv objects in the entire patch, which is a lot of unnecessary command traffic.
      Say i have patch A. inside A is X and Y identical subpatchers. X and Y have nested subpatchers X_a, X_b and Y_a and Y_b, respectively. I want to have something that will send from X to X_a and X_b but not to A, Y, Y_a or Y_b.
      One of teh first lessons you learn in computer programming is to avoid global variables wherever possible!
      thanks for your help, George
    • May 09 2006 | 10:39 pm
      and that?
      best
      huts
      ( ) ~ O ~ www.kineticsoundsystem.com ( )
    • May 09 2006 | 10:58 pm
    • May 11 2006 | 9:24 pm
      Peter McCulloch wrote: > Now, if we could just get that functionality for send~ and receive~...
      We got somthing even better, called pattrforward. You can send messages directly to a named object. In general it seems the whole pattr system is what fills the gap of local variables completely: A named object is a local variable by the way, the name is only valid for that patcher. Pattrforward turns any named object into a local receive object, which is still accessable from outside.
      Stefan
      -- Stefan Tiedje------------x---- --_____-----------|----------- --(_|_ ----|-----|-----()---- -- _|_)----|-----()----------- ----------()-----www.ccmix.com
    • May 12 2006 | 9:12 am
      On 11 May 2006, at 22:24, Stefan Tiedje wrote:
      > We got somthing even better, called pattrforward. You can send > messages directly to a named object.
      d'oh! Well spotted. I still have a bit of a blind spot for the pattr stuff, even though I've used it quite a lot, so this technique didn't even register...
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com