WEIRD BEHAVIOUR. Panel object occults connections out of edit mode
Even if a panel object is placed behind connections it hides them when out of edit mode.
From a diagnosis point of view hiding the connections behind the panel object out of edit mode is counter intuitive. You can't see the signal/data path.
How can you diagnose a live patch out of edit mode if the connections are hidden behind the panel. This is a fault.
This behaviour didn't exist in previous versions of Max. Why fix it if it ain't broken?
Reported it but.....C74 team can't see the problem.
Select the [panel] object. Go to the Arrange menu and select "Include in Background." Your cables are now visible.
Many thanks for this. C74 sent the same fix earlier. Just seems strange that you are offered to place panel in background yet it defaults to foreground for connections ( the flow information) out of edit.
Bad usability practice! Needs fixing or at least an option. No excuse.
I can see having an option for it but just because you think the default way it works is "bad" doesn't mean it necessarily is.
"No excuse" for thinking your way is the only right way. ;-)
I feel strongly about. :-)
The new method breaks good pratice. Again. Why fix it if it ain't broken.
You need two passes to make it background rather than one in the old method.
"practice" that is
All my patches have panels to aid the eye. In "usability" this is called chunking.
Why would you want to hide by default the data and signal flow by a non-interactive and visually enhancing GUI flow object ("panel"which helps you chunk information) which you intentionally set in the background to avoid flow occlusion in an environment which claims to be a visual flow programming environment? What is the point of "presentation mode"
If I put a panel behind code it is to chunk the information and direct the eye to the signal flow. This is paramount in aiding data and signal flow design.
I now have several hundred patches in which the most important flow information is hidden by default.
I'm sorry about your legacy patch problem, but I think the new way is better, in general. At any rate, I'd bet that it is deemed a feature by the developers, and a good part of the Max community, so you might as well get used to it.
My design practice is to make the top level pretty using panels, fpics, etc. all of which is included in the background. Unless I'm changing the panels, etc. I leave the background locked for ease of editing. In concert with presentation mode, this practice makes my patchers fairly easy to maintain. I use a lot of abstractions/subpatchers that don't have this sort of "prettification," which is often where the guts of a patcher go.
"...I'd bet that it is deemed a feature by the developers, and a good part of the Max community"
Just because something is common doesn't mean it is normal or the best way.
The issue raised is not a question of "prettyfication as you call it". Its about cognitive dissonance in the afforded usability of the Max environment, a very different matter.
Sure I can get used to it as a way of working but the current "common" way adds "viscosity" to the build process. Option are always good and this is something that C74 have been good at improving with successive updates. "It makes the panel "send to back" feature redundant. Why include it?
good discussion! I'm equally unhappy with the way panels work - but willing to accept that in fact it is 'better' this way (I've only been patching 1.5 years - a newbie). I'd be very curious to know though what the advantages are of having panels obscure wires!
Pereshaped - I used to use panels as well to aid the eye, but it just ended up frustrating me. Apart from hiding patchcords, everytime I try to select a couple of objects within a panel I end up selecting the panel itself. Now I just make a lot more subpatchers which, though a bit more work, seem to help me better keeping my patches organised.
All that said - why don't we just request for the panel behaviour to be changed? the majority of users may agree with you - I do.
"Option are always good and this is something that C74 have been good at improving with successive updates. It makes the panel "send to back" feature redundant. Why include it?"
This sounds contradictory to me. You say options are good… but just not this option.
Anyway, the problem with this discussion is that it's focusing on the "Include in Background" feature that can be applied to any object. The reason it exists in the first place (and what we should be talking about) is the new way patch cables work in Max 6. WIth the new behavior patch cables automatically go behind objects when the patch is locked. This was one of the first features I noticed as a huge improvement because I know plenty of people who don't care how a patch looks as long as it works and so they tend to have "spider web" patches. With the current behavior patches like that are actually more readable and combined with the way the cables now curve it can even make it less crucial to use segmented cabling.
Now personally I do like to make my patches readable and I just accept that patch cables are sent to the back by default and if I need to see them then I might have to include some objects in the background.
FWIW, lately when I use panel to chunk pieces of code I give it a transparent background and a thin rounded border, which puts a box around the code and doesn't obscure the cables.
@stringtapper
1. Not a contradiction at all. It's not an "option" at present as it is forced on us. It is a fixed behaviour rather than an option
2. I care how a patch looks as my patches are extremely complex and require prior design. The patches/code has to be shared with others and they must be able to read it out of the box so they can verfiy functional aspects. If they are not I don't get paid for them and get a bad reputation.
3. Plenty of people design badly if your reasoning is correct. Segmented patch chords are there for a reason. I mark my students down if they use "spider webs" in their patches as these are not readable by bug finders, testers or impart knowledge to others because they are unreadable. I hate patches that look like they were knitted with a knife and fork.
3. You say you give panels a transparent background to make it readable. So you in fact you have to do yet another step? to make your patches readable and see the cables. Three steps in total.
Anyway, it looks like it is unnecessary panel twiddling for the foreseeable future. I'll get used to it as there isn't any option at present.
@ basvlk. Yes, good, visceral discussion! :-)
1. No, it's just a default behavior. You have an option to change it. I'm not opposed to there being an option to change default patch cable behavior if one wants it. That would solve your problem. More options are usually better.
3 (#1). Of the people I referenced who make "spider web" patches at least two are very well regarded composers. Not everyone uses patching environments to collaborate with others or sell their work. Some just need things to work and then get on with the business of making music. I don't personally work this way but I don't think my way is necessarily better.
3 (#2). I was doing the transparent panel thing before Max 6 though. I just think it looks better overall to have a "box" around the code you want to chunk instead of a background panel. Now I do use background panels in my presentation modes.
pereshaped, do you use presentation mode? Just wondering.
@ Chris
Sometimes. But only when I am designing a GUI rather then the signal flow. That is a matter apart and find presentation mode "heaven" for this.
Perhaps this is confusing the issue as I refer to usability in my comments. I meant the Max programming usability not the abstraction design usability. Max's environment rather than what is produced with it.
I work with signal primitives and waveshaping of these. I like to conceive of the "circuit" as a collection of reduced structures and panels help a lot in minimising the cog overload of connections so that I can carry with me a mental model of the circuit and work problems out in my mind and paper rather than on the screen. So having a flexible box system like "panels is great for this. Its easier to remember.
For me, encapsulation/abstraction/bpatchera are the way to go for this sort of thing. I guess I've been programming C and other block-structured languages for long enough that I just think in terms of little blocks with inputs and outputs. I've made some pretty darn big patchers for my own use using these techniques, and had a job for a while working on a truly huge patcher using these techniques.
As far as presentation mode being just for GUI purposes, that's true as far as it goes, but it allows for a tidy UI while really spreading out your patch to emphasize signal flow in non-presentation mode. If you throw in the auto-window-resize trick that Cycling uses in some of their system patchers (e.g. the "View" checkbox in Audio Status) to help you manage the two modes, it gets even better.
Chris, I like that idea very much and will explore it. I suppose that, because the complexity of the Max environment has, it is impossible to cater for every way of working. One gets stuck in their own way of composing patches. Thanks to everyone for offering a different and valuable perspective.