expected out~ behaviour?

Aug 28, 2006 at 10:53pm

expected out~ behaviour?

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

#27363
Aug 29, 2006 at 9:31am

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.

#82715
Aug 29, 2006 at 10:28am

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

#82716
Aug 29, 2006 at 11:09am

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

#82717

You must be logged in to reply to this topic.