All windows active in Max6 ?
Hello,
I can't figure out where is the option ''all windows active'' in Max6.
It's not in the option menu anymore...
Any idea ?
Thanks
Florent
Nobody cares about ''all windows active'' ??
I liked this option though... as well as the option to turn off ''snap to grid''
(there are many new options I'm really enjoying though in Max6, don't want to sound too old-fashioned here...)
This feature is important for me too. Any help there?
This is really annoying. Can't find anything about this in the help file.
It seems the ''all windows active'' simply disappeared from the option menu.
Strangely, I remember this option was a default state in the beta version...
We didn't kill it, it just became impossible to implement in the (Mac only) Cocoa version of Max. We tried all sorts of things.
It's still there in Windows
:)
-A
Thanks for the official answer Andrew.
It would be seriously helpful to restore the "All Windows Active". (In all the years I've been using Max, I never ever switched that option off and loosing it is totally annoying). Is there any chance getting it back in the (near) future without having to activate Windows (which is in my case not an option)?
Thanks a lot, j.
why??!!
"all windows active" is one of the most useful features in max. i just bought a NEW laptop specifically to be able to run Max 6.. not having this feature is a huge disappointment. please fix this problem, or figure out how to make it work.
Maybe I don't understand what "all windows active" is supposed to mean.
Although I'm still still using Max 5 for production, I test my patchers with Max 6 so that when I finally move I won't have any surprises.
I routinely have multiple windows open and they all seem to be active.
In particular, I just created two windows each of which receive MIDI data and print to the console --- both seem to run, I'm seeing the console window display the data twice.
dhjdhdjhdhdjhdhhdj - all windows active means that you can layer windows and make adjustments without changing which window has the focus... not about data flow.
Ah, ok...now I understand the comment about Cocoa.
what changed in os x / cocoa to not allow this feature anymore?
I don't know. I'm surprised that addglobalmonitorforeventsmatchingmask doesn't work
It's not completely impossible in Cocoa, but there are far more hoops to go through than in Carbon, where subverting UI conventions was much easier. (@innerdub: the short answer is "everything". Seriously.)
As for [addGlobalMonitorForEventsMatchingMask: handler:], the documentation says "Available in OS X v10.6 and later." Max/MSP still supports 10.5. Dunno if it's worth dropping 10.5 support just for this feature. Yeah, it's possible to offer the feature based on host OS version, but it's a pain in the arse (also for tech support, who will have to field "why does this work on my friend's Mac and not on mine?" type questions from people who will refuse to accept the answer.)
A workaround is to make a full-screen master patch and add all your all-windows-active patchers to the master patch as bpatchers.
other workarounds:
bang repeatedly the message [front] to thispatcher so your patcher stays on top of the others
route certain keys or midi notes to the message [front] to thispatcher so you can bring to front any of the patchers you want
As opposed to people who want to know why features that used to work no longer work?
Apple themselves barely support 10.5 any more. I wonder how many people still actually run 10.5
-----------
also for tech support, who will have to field "why does this work on my friend's Mac and not on mine?" type questions from people who will refuse to accept the answer.
OK....that's 1!
I assume you're still using Max 4 ?
My point was more about your not wanting to upgrade :-)
I'm still using 5.1.9 myself (although I have 6.x) for reliability reasons. Can't wait to switch over to Max 6 though ---- it's so nice in so many ways.
I'm sure there are plenty of 10.5 installations running Max. It's amazing the amount of old hardware and software are running around when you start to look for it.
But my argument wasn't about numbers of users. The notion of dropping support for an entire OS release just to implement one feature was what surprised me. For a whole suite of features, yeah, that can make sense. But for one single feature?
I guess it depends how badly you want to see that feature implemented. And all-windows-active is a Marmite feature. Either you love it or you hate it.
Actually, I don't care about the feature itself, I didn't even know what it was and I have no idea how many people care about it.
But given that it's not very hard to see what version of the OS is running and it's not very hard to include selective support for a feature based on the OS, particularly in Objective-C when you can easily query an object to see if it supports a particular message, I'm surprised that it wasn't included so that it work on 10.6 and be ignored on 10.5
From the other side (customers), it's bizarre to see stuff that used to work no longer work.
@petercastine said: A workaround is to make a full-screen master patch and add all your all-windows-active patchers to the master patch as bpatchers.
Except that's no good if, like me, you need the whole window space for each subpatcher when it opens. I suppose keeping a register of the most recently opened window and then banging that every time the main patcher window is clicked would do it, but that seems really clunky to me.
Oh well.
@dhj: the disappearance of AWA is just another in a series of things that may be possible to implement but are apparently deemed to be not-worth-the-effort by the powers that be. I have my own list of peeves of varying degrees of inconvenience, all of them nearer and dearer to me than all-windows-active. After twenty-some-odd years of working with Max, I find my blood pressure is more stable if I don't lose sleep over this stuff and try to roll with the flow.-|
@david: my suggestions were posted in the spirit "if this works for you, great; if it doesn't, I don't have any other ideas." Sorry.
@peter and your suggestions were taken in that spirit - no offence intended!
The other way I'm finding this really annoying is when I'm editing a subpatch and need to trigger or change a control in another window, or perhaps use the Audio Status window (monitoring processor use) to turn audio on. It now requires that I have to refind the window I was working in and bring it back to the front. This gets tired very quickly.
Hey
just to update this discussion, I've just found out somewhere else in the forum that the message "topmost 1" to thispatcher actually does the job of keeping a patcher on top of the others.
It even working outside of Max!
this is so cool, me happy
why not documenting this feature in the thispatcher's reference?