davidestevens

I've been trying modifying parts of my patch using poly~s to reduce 

As a result, I had an abstraction(level 2) inside of an abstraction 

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 

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 

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.

expected-out-behaviour

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.

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.


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, 

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.

On 29-Aug-2006, at 0:53, David Stevens wrote:

> I've been trying modifying parts of my patch using poly~s to reduce 

> As a result, I had an abstraction(level 2) inside of an abstraction 

> 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.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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.

> 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

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~; 

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 

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 

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 

> 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.

expected out~ behaviour?