New objects discovered so far in Max 6
dict family (13 objects)
scale~ (long awaited)
jit.phys family (9 objects)
jit.anim (3 objects)
Not new but much improved :
poly~ (anti-aliasing filter when upsampling) YESSSSSSSSSSS
vst~ (opens AudioUnit plug-ins too)
cycle~ (size and position in buffer~ set freely) YESSSSSSSSSSS AGAIN
some of the objects you discovered were already in Max5 (jstrigger), and even Max4 (error) ;-). It’s what’s nice about new versions, you have to explore the software again.
Did some objects disappear? It unfortunately happens sometimes, in a very silent way…
Yes, there are some other objects I believed to be new and realized later they existed in previous versions yet. Those you mention escaped my attention.
It’s like opening a dictionary and discovering words you’ve never heard about before. Worth a few mistakes…
fzero seems pretty cool
Nice to have proper multiple input list concentation (join) with having to result to java!
@Roald, is [override] definitely in Max 6? I can’t find it… I opened Max 5 to try, and it’s there but doesn’t seem to do anything (no help patch either).
Just checking, awesome list btw! Thanks for putting it together.
I like the discovery part, but I would truly appreciate an official list :P
I saw somebody else talked about override :)
I thought I’d quickly instantiate each of these objects to get an idea of their purpose.
However, I’m curious about the way that [attrui] seems to work.
The paradigm of Max is (I thought) that data is sent from the outlet of one object to the input of another object, i.e, unidirectional.
Yet the [attrui] seems to be sending a message and somehow getting some stuff back. Even more odd, the [attrui] seems to get information (the list of attributes) of the object to which it is connected BEFORE any messages get sent.
Clearly, some information is being passed back when the connection is being made, but that’s an implementation issue. (Do all Max externals have to implement the ability to send attributes back?)
Conceptually however, this mechanism seems to break the Max "event-driven" paradigm. Should the behavior of [attrui] be considered to be a "hack" or is there supposed to be an official notion of two-way communication that I never noticed before and that should be leveraged more?
[grab] also does this.
Ok….still begs the question of how this fits in to the paradigm
attrui uses some new API for doing this. This is not a hack at all ;-) attrui is just aware of the attribute of the object(s) it’s connected too. Some other objects already use this kind of "back and forth connection": getattr, pattr, playbar are in the same club ;-)