Mattijs

Hi, I am pretty sure this is unwanted behaviour:

1) open the patch below, note that the messageboxes contain numbers 1 to 4

2) encapsulate the indicated part of the patch

4) open the patch and note that the messageboxes now contain numbers 4 to 1!

It seems to me that the outlets are connected differently on load when they are on exactly the same vertical position.

1) open the patch below, note that the messageboxes contain numbers 1 to 4
2) encapsulate the indicated part of the patch
3) save and close the patch
4) open the patch and note that the messageboxes now contain numbers 4 to 1!

bugreport-encapsulate-and-connect-outlets-on-load

Great bug, thanks! I can confirm in Max 4.5.7 and will attempt to fix.

Am 25.04.2006 um 13:00 Uhr schrieb Mattijs Kneppers:

> Hi, I am pretty sure this is unwanted behaviour:

Am 25.04.2006 um 13:00 Uhr schrieb Mattijs Kneppers:
> Hi, I am pretty sure this is unwanted behaviour:


> Great bug, thanks! I can confirm in Max 4.5.7 and will attempt to fix.

If you are at it, please consider two enhancenments, one obvious, one 

The obvious will probably correct the reported bug:

As the bug example shows, the inlets are hidden, in more complex 

patchers you do not know how many inplets are created (see request 2)

Solution: put all the inlets above the highest object in a single row 

according to their bang order (y-coordinate the same for all inlets).

If possible directly above the first connected object (x-coordinate).

The same for outlets but below the lowest object (y-coordinate).

This will lead to readable and understandable encapsulations.

For the second request there is a simple example patch:

If you deencapsulate the left patcher and simply encapsulate it again, 

it will not be that same. I desperately want it to be the same, for 

If I have two sources going into one destination inside a subpatcher, 

its just a logically clear coment-like construction. It does not require 

a second input, it should not have a second input as this second input 

The patcher need an internal logic, not an external...

The right example creates a redundant cord to the rightmost inlet, 

beside cluttering the internal patch into an unreadable state (see 

request 1) it creates also too many inlets.

The most left inlet most likely is the most important, just use this.

I know we did discuss that already, but I haven't heard any reasonable 

argument for the way it is now and hope my examples will show the 

By the way, I LOVE encapsulation, I can't express it loud enough, I hope 

Jeremy Bernstein wrote:
> Great bug, thanks! I can confirm in Max 4.5.7 and will attempt to fix.

If you are at it, please consider two enhancenments, one obvious, one 
for further enhanced convenience.

As the bug example shows, the inlets are hidden, in more complex 
patchers you do not know how many inplets are created (see request 2)

Solution: put all the inlets above the highest object in a single row 
according to their bang order (y-coordinate the same for all inlets).
If possible directly above the first connected object (x-coordinate).

If you deencapsulate the left patcher and simply encapsulate it again, 
it will not be that same. I desperately want it to be the same, for 
simple reasons:

If I have two sources going into one destination inside a subpatcher, 
its just a logically clear coment-like construction. It does not require 
a second input, it should not have a second input as this second input 
is internally identicall with the first!

The patcher need an internal logic, not an external...
The right example creates a redundant cord to the rightmost inlet, 
beside cluttering the internal patch into an unreadable state (see 
request 1) it creates also too many inlets.
The most left inlet most likely is the most important, just use this.

I know we did discuss that already, but I haven't heard any reasonable 
argument for the way it is now and hope my examples will show the 
evidence of my point of view...

By the way, I LOVE encapsulation, I can't express it loud enough, I hope 
my rant will enhance it even more:

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


I agree with Stefan but I can imagine the topic 'enhance encapsulate' is somewhere near the lower end of the priority list, just like 'enhance find/replace' and of course many others. Won't be easy, running a software company. ;)

Interesting though to see that people like Stefan (and me) would probably develop these upgrades themselves if they had the opportunity, even without charging any money. Here lies in fact a huge potential of costless co-workers. If cycling74 would find a way to channel these energies into their products.. wouldn't that be quite revolutionary?

Btw, I have to say cycling74 is already unique in the short distance between the developers and the users. I have dealt with native instruments for some time (I learned not to try with Reaktor what you can do with Max), compared to cycling74, NI guys act like they float on a cloud somewhere in developers heaven. For real, how do you guys manage to stay in touch with the forums and lists so well compared to other companies?

Bugreport: encapsulate and connect outlets on load