expected out~ behaviour?


    Aug 28 2006 | 10:53 pm
    I've been trying modifying parts of my patch using poly~s to reduce
    processor load.
    As a result, I had an abstraction(level 2) inside of an abstraction
    (level 1) inside a poly~ (level 0).
    Level 1 obviously has a pair of [out~]s for routing audio out of the
    poly~, but because I'd also tried poly~ing the level 2 abstraction at
    some point, I also had [out~] s in there still.
    What I found (after much hair pulling) was that the audio from the
    nested abstraction was _also_ appearing at the output of the poly~ .
    (the main output had an envelope on it, but i was still hearing audio
    when the envelope was closed)
    So it appears that _wherever_ you have [out~]s in a patch, and no
    matter how far nested down, (even if they're in abstractions rather
    than [patcher]s) they still route to the top level [out~]s.
    Is that how they're meant to behave? I must say that it surprised me
    - I'd have thought that they would have remained local to the part of
    the patch that they're embedded in.
    thanks
    David

    • Aug 29 2006 | 9:31 am
      This is the behavior I would expect from the out~ object. After all, anything within the poly~ object should refer exclusively to the topmost poly~ object and not any abstraction or subpatcher. out~ is for poly~, where else use outlets.
    • Aug 29 2006 | 10:28 am
      I think the solution to your problem is to instantiate your level-2
      abstraction inside a poly~ (that is, as a poly~ inside a poly~; yes,
      you can do this).
      Expected behavior? Obviously not what you expected (and I'm sure
      you're not alone), but explicable behavior. The objects in/out/in~/
      out~ are for poly~; inlet/outlet are for abstractions & patchers;
      Trixx are for kids (sorry, couldn't resist). Abstractions don't know
      anything about out~ objects, other than to instantiate them. So a
      poly~ takes responsibility for all out~ objects it finds, no matter
      how deep, until it hits an enclosed poly~ object that has
      responsibility for out~s deeper in the file inclusion hierarchy.
      Let us know if this works, my idea's just a guess.
      -- P.
      On 29-Aug-2006, at 0:53, David Stevens wrote:
      > I've been trying modifying parts of my patch using poly~s to reduce
      > processor load.
      >
      > As a result, I had an abstraction(level 2) inside of an abstraction
      > (level 1) inside a poly~ (level 0).
      >
      > Level 1 obviously has a pair of [out~]s for routing audio out of
      > the poly~, but because I'd also tried poly~ing the level 2
      > abstraction at some point, I also had [out~] s in there still.
      >
      > What I found (after much hair pulling) was that the audio from the
      > nested abstraction was _also_ appearing at the output of the
      > poly~ . (the main output had an envelope on it, but i was still
      > hearing audio when the envelope was closed)
      >
      > So it appears that _wherever_ you have [out~]s in a patch, and no
      > matter how far nested down, (even if they're in abstractions rather
      > than [patcher]s) they still route to the top level [out~]s.
      >
      > Is that how they're meant to behave? I must say that it surprised
      > me - I'd have thought that they would have remained local to the
      > part of the patch that they're embedded in.
      >
      > thanks
      >
      > David
      >
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Aug 29 2006 | 11:09 am
      On 29 Aug 2006, at 11:28, Peter Castine wrote:
      > I think the solution to your problem is to instantiate your level-2
      > abstraction inside a poly~ (that is, as a poly~ inside a poly~;
      > yes, you can do this).
      I'd wondered about that, but hadn't dared to go there yet ....
      >
      > So a poly~ takes responsibility for all out~ objects it finds, no
      > matter how deep, until it hits an enclosed poly~ object that has
      > responsibility for out~s deeper in the file inclusion hierarchy.
      Ah, interesting. Thinking about it, my conception of in/out in~/out~
      is as interface points at the surface of an object, so the idea that
      they would look further down a hierarchy is a new one. I guess my
      original concept is right for plain vanilla in/out, but the behaviour
      of the poly~ versions is different.
      What this reminds me is that the way I think about max is very much
      based on a physical/mechanical model - real switches and wires and
      boxes. It makes thinking about programming much easier for me (that's
      why I stuck with max after all), but there are limits to what I can
      imagine doing within this paradigm.
      Anyway, I got it all sorted out, and managed to shave a few percent
      off the cpu load. It would be nice to be able to lower it more, but I
      can't think f much else to do. I have quite a few train~s whizzing
      away, and I'm guessing that they're using a good chunk of the cpu
      cycles.
      thanks
      David