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:

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:

--

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

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?

Cheers, Mattijs