call bpatcher from the patch


    Feb 22 2007 | 10:38 am
    hi
    i would like to be able to call a bpatcher directly from the patch,
    not from the inspector of the bpatcher.
    I looked at the inspector patch, and it seemed it that there is a
    "thisobject" object communicating with the bpatcher object... ( for
    calling a patch it receives the "replace mypatchname" message)
    there is no pdf reference for "thisobject" (at least i did not found
    it in the max docs).
    hummm;; how could I communicate, from the patch itself with the
    bpatcher??? maybe building a "fake" bpatcher with a.... with a what
    - just an input, something else???
    could be scripting, maybe...
    any idea is welcome
    many thanks
    kasper
    --
    Kasper T. Toeplitz
    noise, composition, bass, computer

    • Feb 22 2007 | 1:45 pm
    • Feb 23 2007 | 9:27 pm
      do you need to dynamically "create" new bpatchers that reference certain patch files? if so, you need to use scripting to create the bpatcher using the filename of the subpatch you want to use inside of it.
      or, are you just trying to send messages to and from an existing bpatcher file? if so, a simple send/receive pair will do the job. if you have multiple bpatchers accessing the same patch file and you need to communicate with each one independently, then you'll either have to filter the send/receive messages (i.e. assign an instance number to each bpatcher by incrementing a [value] object during patch initialization) or dynamically name the bpatchers' send/receive objects using a similar technique.
      if your bpatchers are permanent and not being dynamically created, then i believe bpatchers can have inlets and outlets, just like a subpatcher object. that's another option.
    • Feb 24 2007 | 12:42 am
      the [thispatcher] object ONLY works in inspectors!
      its a shame that we cant exchange bpatchers via messages
      if you ask me. :)
      -110
    • Feb 24 2007 | 1:37 am
      .. what ?
      you... can.......
      On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:
      >
      >
      > the [thispatcher] object ONLY works in inspectors!
      >
      >
      > its a shame that we cant exchange bpatchers via messages
      > if you ask me. :)
      >
      > -110
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 24 2007 | 2:45 am
      Quote: vade wrote on Fri, 23 February 2007 18:37
      ----------------------------------------------------
      > .. what ?
      >
      > you... can.......
      then enlighten me, i need it too.
    • Feb 24 2007 | 8:36 am
      thisobject is for inspectors. thispatcher is used for scripting. see
      the helpfile of the tutorials for scripting the creation of bpatcher
      object dybamically.
      its friday ni8ght and ive had too many beers to come up with an
      actual solution.
      perhaops you meant to say that thisobject is useful only in inspectors?
      On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:
      >
      > Quote: vade wrote on Fri, 23 February 2007 18:37
      > ----------------------------------------------------
      >> .. what ?
      >>
      >> you... can.......
      >
      >
      > then enlighten me, i need it too.
      > --
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 24 2007 | 8:51 am
      check out page 281/tutorial 47 in max4.6 tutorials perhaps if you
      want ot dynamically make bpatchers. Its pretty straightforward.
      On Feb 24, 2007, at 3:36 AM, vade wrote:
      > thisobject is for inspectors. thispatcher is used for scripting.
      > see the helpfile of the tutorials for scripting the creation of
      > bpatcher object dybamically.
      >
      > its friday ni8ght and ive had too many beers to come up with an
      > actual solution.
      >
      >
      > perhaops you meant to say that thisobject is useful only in
      > inspectors?
      >
      >
      > On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:
      >
      >>
      >> Quote: vade wrote on Fri, 23 February 2007 18:37
      >> ----------------------------------------------------
      >>> .. what ?
      >>>
      >>> you... can.......
      >>
      >>
      >> then enlighten me, i need it too.
      >> --
      >> http://vst-mac.info/
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 24 2007 | 8:59 am
      ok you mean this?
      dynamically re-assigns mybpatcher to bpatcher1 or bpatcher2 ?
      or am I completely mis-interpreting this?
      On Feb 24, 2007, at 3:36 AM, vade wrote:
      > thisobject is for inspectors. thispatcher is used for scripting.
      > see the helpfile of the tutorials for scripting the creation of
      > bpatcher object dybamically.
      >
      > its friday ni8ght and ive had too many beers to come up with an
      > actual solution.
      >
      >
      > perhaops you meant to say that thisobject is useful only in
      > inspectors?
      >
      >
      > On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:
      >
      >>
      >> Quote: vade wrote on Fri, 23 February 2007 18:37
      >> ----------------------------------------------------
      >>> .. what ?
      >>>
      >>> you... can.......
      >>
      >>
      >> then enlighten me, i need it too.
      >> --
      >> http://vst-mac.info/
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 24 2007 | 1:28 pm
      >do you need to dynamically "create" new bpatchers that reference
      >certain patch files? if so, you need to use scripting to create the
      >bpatcher using the filename of the subpatch you want to use inside
      >of it.
      >
      no, what i want is
      _I have a patch, with a bpatcher in it (the bpatcher object) this
      bpatcher can be empty or can be used to "host" a patch, whatever
      i want to send a message to this bpatcher (object, not the patch it
      contains) so that the bpatcher calls and hosts another patch. just
      like what happens when you call the bpatcher's inspector, but without
      calling the inspector, from the patch containing the bpatcher.
      thanks
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 24 2007 | 1:32 pm
      hi vade
      if you can, could you please tell me how???
      many thanks
      kasper
      >.. what ?
      >
      >you... can.......
      >
      >
      >
      >On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:
      >
      >>
      >>
      >>the [thispatcher] object ONLY works in inspectors!
      >>
      >>
      >>its a shame that we cant exchange bpatchers via messages
      >>if you ask me. :)
      >>
      >
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 24 2007 | 2:48 pm
      >
      > i want to send a message to this bpatcher (object, not the patch it
      > contains) so that the bpatcher calls and hosts another patch. just
      > like what happens when you call the bpatcher's inspector, but without
      > calling the inspector, from the patch containing the bpatcher.
      >
      and excuse me if I'm a bit off-topic here, but why do you absolutely want
      that to happen with a bpatcher ?
      I surely have less experience than you all with max but I always try to
      avoid the use of bpatcher...
      I much prefer to load-close patches when needed.
      I have here an exemple with pcontrol that you surely know but it can be
      usefull for others :)
      save this one as jaune.pat:
      save this one as vert.pat:
      this is the main one:
    • Feb 24 2007 | 3:12 pm
      >i want to send a message to this bpatcher (object, not the patch it
      >contains) so that the bpatcher calls and hosts another patch. just
      >like what happens when you call the bpatcher's inspector, but without
      >calling the inspector, from the patch containing the bpatcher.
      >
      >
      >and excuse me if I'm a bit off-topic here, but why do you absolutely
      >want that to happen with a bpatcher ?
      >I surely have less experience than you all with max but I always try
      >to avoid the use of bpatcher...
      >I much prefer to load-close patches when needed.
      >
      >I have here an exemple with pcontrol that you surely know but it can
      >be usefull for others :)
      >
      a few connections seem to be missing in your main patch but i see the point
      _ I use Bpatchers mostly when i write for other musicians (but also
      for myself) "modules" (think of modular synth) such as a filter, an
      effect, a generator - this way all the controls (and only the
      controls) are exposed to the player, building a personal set-up is
      quick (with those premade modules) and easy; and it works.
      the idea is to have the "instrument" in one patch as opposed of
      opening closing (or even navigating) between patches
      _____scripting seems actually to do what i want - i am working on a
      "frame" (such as a mudilar synth "frame", with "slots") in which i
      include at will the needed modules....
      ******* by the way - I am not yet there, but does anyone tried
      scripted messages in max runtime??? does it work??? (it should.....)
      best
      kasper
    • Feb 24 2007 | 3:30 pm
      >
      > a few connections seem to be missing in your main patch but i see the
      > point
      >
      ??
      ******* by the way - I am not yet there, but does anyone tried scripted
      > messages in max runtime??? does it work??? (it should.....)
      >
      here (win xp) it does :)
      cheers
      _y.
    • Feb 24 2007 | 3:39 pm
    • Feb 24 2007 | 3:54 pm
      I also love the fact that you can make bpatcher prototypes with these
      > modules and insert them into the project within seconds - I definitely
      > intend to keep building my library this way.
      >
      wow, I totally overlooked the fact that a bpatcher can also be "prototyped"
      !
      This changes my point of view !
      _y.
    • Feb 24 2007 | 7:43 pm
      Im still confused after reading the thread why you cant use scripting
      with thispatcher to replace bpatchers and script the connections. Did
      you see the archive I sent?
      On Feb 24, 2007, at 8:32 AM, Kasper T Toeplitz wrote:
      > hi vade
      >
      > if you can, could you please tell me how???
      >
      > many thanks
      >
      > kasper
      >
      >> .. what ?
      >>
      >> you... can.......
      >>
      >>
      >>
      >> On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:
      >>
      >>>
      >>>
      >>> the [thispatcher] object ONLY works in inspectors!
      >>>
      >>>
      >>> its a shame that we cant exchange bpatchers via messages
      >>> if you ask me. :)
      >>>
      >>
      >
      > --
      > Kasper T. Toeplitz
      > noise, composition, bass, computer
      > http://www.sleazeArt.com
      >
      > http://www.myspace.com/sleazeart
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 25 2007 | 1:42 am
      Der Unterschied ist... they want to load/replace patches from the bpatcher
      object itself (and not scripting from the parent patch), and without dealing
      with the inspector :
      "i want to send a message to this bpatcher (object, not the patch it
      contains) so that the bpatcher calls and hosts another patch"
      Am I (not) right ?
      ;)
      _y.
    • Feb 25 2007 | 6:25 am
      But a bpatcher HAS to be within a parent patch by definition.
      On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:
      > Der Unterschied ist... they want to load/replace patches from the
      > bpatcher object itself (and not scripting from the parent patch),
      > and without dealing with the inspector :
      >
      > "i want to send a message to this bpatcher (object, not the patch it
      > contains) so that the bpatcher calls and hosts another patch"
      >
      > Am I (not) right ?
      >
      > ;)
      >
      > _y.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 25 2007 | 7:22 am
      Send the thispatcher script from within the bpatcher to out outlet
      and then to a thispatcher in the parent? ... I it should be pretty
      straightforward.
      Bah anyway.
      On Feb 25, 2007, at 1:25 AM, vade wrote:
      > But a bpatcher HAS to be within a parent patch by definition.
      >
      > On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:
      >
      >> Der Unterschied ist... they want to load/replace patches from the
      >> bpatcher object itself (and not scripting from the parent patch),
      >> and without dealing with the inspector :
      >>
      >> "i want to send a message to this bpatcher (object, not the patch it
      >> contains) so that the bpatcher calls and hosts another patch"
      >>
      >> Am I (not) right ?
      >>
      >> ;)
      >>
      >> _y.
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 25 2007 | 8:04 am
      gotta script this one. My attempts have developed to somewhat stability, albeit, I get crashes sometimes.
    • Feb 25 2007 | 10:08 am
      hi
      yes, in the first place i wanted to have a message which calls (from
      the outside - from the top patch) the patch to be hosted in the
      bpatcher-object.
      since this does not sem to work, yes, i took the script route which
      is (thanks vade) to delete the bpatcher (and its contents) and
      recreate a new bpatcher complete with its content (patcher). Not the
      same but same results.
      this works well, and for the user it makes no difference - he still
      has a list of possible bpatcher-content patches (my-filter,
      my-generator etc) which he chooses and calls with a Umenu
      i also made a "blank" (no effect) patch to be called - similar to an
      empty space in a rack. (now i have to make an "intelligent" matrix
      for interconnections between them all)
      many thanks to all
      best
      kasper
      >Send the thispatcher script from within the bpatcher to out outlet
      >and then to a thispatcher in the parent? ... I it should be pretty
      >straightforward.
      >
      >Bah anyway.
      >
      >
      >On Feb 25, 2007, at 1:25 AM, vade wrote:
      >
      >>But a bpatcher HAS to be within a parent patch by definition.
      >>
      >>On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:
      >>
      >>>Der Unterschied ist... they want to load/replace patches from the
      >>>bpatcher object itself (and not scripting from the parent patch),
      >>>and without dealing with the inspector :
      >>>
      >>>"i want to send a message to this bpatcher (object, not the patch it
      >>>contains) so that the bpatcher calls and hosts another patch"
      >>>
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 25 2007 | 10:11 am
      On Feb 24, 2007, at 8:43 PM, vade wrote:
      > Im still confused after reading the thread why you cant use
      > scripting with thispatcher to replace bpatchers and script the
      > connections. Did you see the archive I sent?
      >
      > On Feb 24, 2007, at 8:32 AM, Kasper T Toeplitz wrote:
      >> hi vade
      >>
      >> if you can, could you please tell me how???
      >
      If I have understood correctly, Kasper wants to use bpatchers boxes
      as slots into which he'd load dynamically premade dsp modules, from
      which user can only see the control interface.
      You could do this by sending the "replace" message to the bpatcher
      box via scripting (using the "sendbox" keyword), followed by the name
      of the target patch (or module) and dedicated arguments.
      Don't know how reliable it is (you may need to refresh the window
      display, for example), but it's an interesting way of presenting a
      clean mixing interface.
      I'd be interested to know if you can send embed messages as well, in
      a runtime app as well (in other words, can one embed foreign patches
      into a standalone app).
      Example :
    • Feb 25 2007 | 10:31 am
      >
      >
      >If I have understood correctly, Kasper wants to use bpatchers boxes
      >as slots into which he'd load dynamically premade dsp modules, from
      >which user can only see the control interface.
      exactly
      >You could do this by sending the "replace" message to the bpatcher
      >box via scripting (using the "sendbox" keyword), followed by the
      >name of the target patch (or module) and dedicated arguments.
      >Don't know how reliable it is (you may need to refresh the window
      >display, for example), but it's an interesting way of presenting a
      >clean mixing interface.
      how/where did you found (about) the "replace" thing???
      anyhow that seems to work as well as deleting/recreating the whole
      bpatcher and its contents (by scripting as well) - in both cases you
      also have to recreate the connections...
      >I'd be interested to know if you can send embed messages as well, in
      >a runtime app as well (in other words, can one embed foreign patches
      >into a standalone app).
      exactly - this is why, i belive, you can not access the "thisobject"
      object by any other way than by the inspector (which you can not
      access in runtime)
      thanks manuel
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 25 2007 | 7:30 pm
      > thisobject is for inspectors. thispatcher is used for scripting. see
      > the helpfile of the tutorials for scripting the creation of bpatcher
      > object dybamically.
      >
      > perhaops you meant to say that thisobject is useful only in inspectors?
      no, i meant to say that scripting to thispatcher is not the
      same as sending a message to the object.
      scripting does not count.
      plus it does not do what i want.
    • Feb 25 2007 | 7:45 pm
      Quote: vade wrote on Sat, 24 February 2007 23:25
      ----------------------------------------------------
      > But a bpatcher HAS to be within a parent patch by definition.
      haha fun, now he is lost.
      if you have a [cycle 0.] and you want to change it
      to [cycle 5.] later in the app, do you name the object
      and script-replace it?
      no, you will send float "5." to its inlet.
      anbd thats what we want to do with our bpatchers; change
      the source file by sending it a message as if the path
      would be just a regular argument.
      see [fpic] ... :)
    • Feb 25 2007 | 8:46 pm
      oh ffs.
      you stated thispatcher doesnt work within anything other than an
      inspector. Thats what I replied to. If you want added functionality
      for bpatcher, fine by me - id be all for not using thispatcher hacks
      (especially since the manual states that thispatcher scripting isnt
      officially supported).
      I gave a workable and usable solution, bite me :P *wink*
      On Feb 25, 2007, at 2:45 PM, Roman Thilenius wrote:
      >
      > Quote: vade wrote on Sat, 24 February 2007 23:25
      > ----------------------------------------------------
      >> But a bpatcher HAS to be within a parent patch by definition.
      >
      >
      > haha fun, now he is lost.
      >
      > if you have a [cycle 0.] and you want to change it
      > to [cycle 5.] later in the app, do you name the object
      > and script-replace it?
      > no, you will send float "5." to its inlet.
      >
      > anbd thats what we want to do with our bpatchers; change
      > the source file by sending it a message as if the path
      > would be just a regular argument.
      >
      > see [fpic] ... :)
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 25 2007 | 8:48 pm
      so ... viable solutions that work, do not count, because you say so?
      - gee thats pretty clever :D
      hah! *sigh*
      *boss : do x for me
      *you I can only do x one way, BUT THAT WAY DOES NOT COUNT BECAUSE I
      ARBITRARILY SAY SO, so we cant do x.
      *boss : ........
      yeah :P
      On Feb 25, 2007, at 2:30 PM, Roman Thilenius wrote:
      >
      > scripting does not count.
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 25 2007 | 8:50 pm
      and btw, you can do that - you just have to roll your own. since
      bpatcher is the same thing as a subpatch (just a 'graph on parent' in
      PD parlance), you have to make your own inlets and use pcontrol or
      thispatcher, the same as for subpatching.
      im assuming youd want the same functionality for a regular
      abstraction or subpatch then?
      see where this is going?
      On Feb 25, 2007, at 2:45 PM, Roman Thilenius wrote:
      >
      > Quote: vade wrote on Sat, 24 February 2007 23:25
      > ----------------------------------------------------
      >> But a bpatcher HAS to be within a parent patch by definition.
      >
      >
      > haha fun, now he is lost.
      >
      > if you have a [cycle 0.] and you want to change it
      > to [cycle 5.] later in the app, do you name the object
      > and script-replace it?
      > no, you will send float "5." to its inlet.
      >
      > anbd thats what we want to do with our bpatchers; change
      > the source file by sending it a message as if the path
      > would be just a regular argument.
      >
      > see [fpic] ... :)
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 26 2007 | 11:36 am
      vade wrote:
      > Send the thispatcher script from within the bpatcher to out outlet and
      > then to a thispatcher in the parent? ... I it should be pretty
      > straightforward.
      Tricky, the examples delete and reinstantiate the bpatcher, (could be
      done also with a replace command). But, the message to reinsatiate is
      sent from a bpatcher which is just deleted...
      I think I tried things like that, eliminating the instatiating scripting
      part from a patch, it ended up not too surprisingly with crashes.
      But of course it still should be possible with some patching outside of
      the bpatcher. You first have to store the scripting messages (a coll
      seems appropriate) and then send a dump, maybe deferlowered to the coll
      connected to thispatcher...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Feb 26 2007 | 12:00 pm
    • Feb 26 2007 | 12:16 pm
      Kasper T Toeplitz wrote:
      > i also made a "blank" (no effect) patch to be called - similar to an
      > empty space in a rack. (now i have to make an "intelligent" matrix for
      > interconnections between them all)
      This sounds like Jamoma in its entire glory beauty...
      Maybe you're not the first...
      Its worth to check out...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Feb 26 2007 | 9:41 pm
      Quote: vade wrote on Sun, 25 February 2007 13:48
      ----------------------------------------------------
      > so ... viable solutions that work, do not count, because you say so?
      > - gee thats pretty clever :D
      ja, teh 110 very clever is.
      scritping interrupts DSP, requires named objects and so on ...
      it is bad (and does not count) like java is bad too (and does
      not count too (because i say so))
      i exspect the update i requested within 24 hours!
      -110 (controlled autism mode)
    • Feb 26 2007 | 9:49 pm
      > bpatcher is the same thing as a subpatch (just a 'graph on parent' in
      > PD parlance), you have to make your own inlets and use pcontrol or
      > thispatcher, the same as for subpatching.
      thats true - i am aware of this logical reason for why it
      does not work the way i would like it to.
      sending the bpatcher _object a message would not force it
      to reinitialise. problem.
      > im assuming youd want the same functionality for a regular
      > abstraction or subpatch then?
      >
      > see where this is going?
      yeah, exactly. otoh, kasper pointed out correctly that
      you can change the path in an inspector to a bpacther object.
      (... or to a patcher object hehehe ... )
      a solution would be a bpatcher object which allows to load
      10 patches at once, and then switch between them.
      (can you make me one?)
    • Feb 26 2007 | 9:53 pm
      and btw - third post - i used to script replace [patcher]
      objects in some project.
      it was done by putting them into poly~s for safely
      performing "turn off", "replace it", "turn on again".
      now, for bpatchers, we have reasons not to put them
      into poly~s ...
      -110 :)
    • Apr 02 2007 | 3:26 pm
      Hello,
      Very interesting thread !
      Kasper,
      Did you finally manage to get your slot system working ?
      I'm also developping something with dynamic bpatcher so I can save my slots, and the settings inside my slots.
      But so far, I'm facingan issue the recall using pattrstorage and autopattr (which usually works fine).
      It's recalling fine the proper bpatcher (stored from an ubmenu) in the main patch, but the settings inside the bpatchers are not (I can see them in my stored xml file though).
      It seems like a timing issue for the pattrstorage system : first need to recall the bpatcher, then it's settings. But at the time it attempt to recall the inner settings, the bpatcher is not yet finish to be loaded... I've tried priority and such, but no success so far.
      Have you faced such issues ? Any ideas ?
      Thanks,
      Salvator
    • Apr 02 2007 | 9:06 pm
      Quote: vade wrote on Sun, 25 February 2007 13:50
      ----------------------------------------------------
      > and btw, you can do that - you just have to roll your own. since
      > bpatcher is the same thing as a subpatch (just a 'graph on parent' in
      > PD parlance), you have to make your own inlets and use pcontrol or
      > thispatcher, the same as for subpatching.
      >
      > im assuming youd want the same functionality for a regular
      > abstraction or subpatch then?
      >
      > see where this is going?
      and HOW do we replace a patch sending stuff to thispatcher
      in the patch which should be replaced??? i dont get it. :)
    • Apr 02 2007 | 11:55 pm
      put the thispatcher in the top most parent patch, send script replace
      xxxx from whatever/wherever you want? , or send instantiate a
      temporary patch which with sends and recieves tells a patch to close
      itself, , and open up a new patch, and then close the temp patch?
      ....
      On Apr 2, 2007, at 5:06 PM, Roman Thilenius wrote:
      >
      > Quote: vade wrote on Sun, 25 February 2007 13:50
      > ----------------------------------------------------
      >> and btw, you can do that - you just have to roll your own. since
      >> bpatcher is the same thing as a subpatch (just a 'graph on parent' in
      >> PD parlance), you have to make your own inlets and use pcontrol or
      >> thispatcher, the same as for subpatching.
      >>
      >> im assuming youd want the same functionality for a regular
      >> abstraction or subpatch then?
      >>
      >> see where this is going?
      >
      >
      > and HOW do we replace a patch sending stuff to thispatcher
      > in the patch which should be replaced??? i dont get it. :)
      >
      >
      >
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info