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| http://www.dspaudio.com/ http://www.castine.de
    • 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