Bugreport: encapsulate and connect outlets on load

Mattijs's icon

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
3) save and close 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.

Max Patch
Copy patch and select New From Clipboard in Max.

Mac OS 10.4.6
Max 4.5.6

Cheers,
Mattijs

Jeremy's icon

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

jb

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

Stefan Tiedje's icon

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.

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

Max Patch
Copy patch and select New From Clipboard in Max.

--

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

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

Mattijs's icon

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?

Cheers,
Mattijs