Max 5.1.6 SDK Update
Hi,
To go along with our Max 5.1.6 release today, we have also updated the SDK. You can grab it from here:
http://cycling74.com/download/MaxSDK-5.1.6.zip
In addition to the usual myriad of various documentation tweaks, typo-fixes, etc. here are the highlights:
- initial const-friendliness to quiet down the warnings issued by GCC 4.2
- fixes to macros for byte-ordering
- header guards where they were missing (e.g for buffer.h)
- updated libs for linking against recently exported functions
- uitextfield example now demonstrates the ‘jsave’ method
- fix for more memory corruption problems in scripto example (when drawing out of range with the mouse)
- fix for memory corruption in the scripto example caused when multiple ui windows were opened.
- fixes to documentation regarding ATTR_SET_DEFER_LOW and friends
- new ‘linky’ example project to demonstrate use of linklist.
Enjoy!
I notice in this update that the maxmspsdk.xconfig file still references the OS X 10.4u SDK. Should I change this or carry on building for 10.4? (I’m running 10.6).
For that matter, if one sticks to the "pure" Max SDK (i.e. using all the provided high-level API calls rather than "go native") is there any reason not to just build for 10.4?
I think the 10.4 support is an option when installing Xcode. I forgot to do this last time round but copied the config across from another machine.
The 10.4 definition is there because the version of Max this goes with (Max 5.1.6) supports OS 10.4.11. But as noted, depending on the version of Xcode you download, support for 10.4 is either an optional install or completely non-existant.
So for your building pleasure, yes, please feel free to modify the xcconfig file to target 10.5.
Cheers
Hi,
thank you for the update, now almost all of the compiler warnings seem to be gone. Just wanted to report you that I’m still getting the warnings for globalsymbol_reference & co. But the rest works now fine.
Adam
Thanks! Yes, a lot of work went into the warning reduction so I’m glad that’s helpful. I’ll look into the globalsymbol warnings for a future SDK.
best,
Tim
Warning reductions!
Thank you for getting those (char*) types in the function prototypes updated to (const char*). The "discards qualifiers" warnings have been a bummer ever since we’ve had function prototypes.
Sort of funky way of dealing with them, but—hey!—whatever gets the job done. Anyway, thanks!
By the way, the developer doc, p66, mentions "obex_object_lookup". It’s apparently "object_obex_lookup".
This only caused me some mild bruising.
And while I’m here, why this idiom throughout the docs?
mypatcher = object_obex_lookup(x, gensym("#P"), &mypatcher);
It’s wrong: object_obex_lookup returns a t_max_err (long) rather than the patcher, which is assigned by reference.
OK, one more then I’m done.
Page 68:
metro = newobject_sprintf(patcher, "@maxclass newobj @text metro 400 @patching_position %.2f %.2f", x->metxpos, x->metypos);
This doesn’t work. It looks like @text wants one argument, so it needs something like
... @text "metro 400" ...
I’ve run into another small issue: the object_method & co also throw some errors. Now I saved the names of the method calls I’m using in some t_symbol * constants (it is safe to assume that the t_symbol * returned by gensym() is actually a constant, isn’t it?), but when I try to call object_method with these constant names, it throws an error. Not a big problem, though…
Another documentation bug?
p67:
for (box = jpatcher_get_firstobject(patcher); box; jbox_get_nextobject(box))
I’m guessing it should be
for (box = jpatcher_get_firstobject(patcher); box; box = jbox_get_nextobject(box))
Very minor, but curious: object_attr_getsym(obj, gensym("varname")) seems to deliver the empty symbol for newly-created UI objects but NULL for non-UI objects.
(I’m just interested in scripting names so I’ve not looked at other attributes.)
Btw, p67: myobject_iterarator isn’t exactly wrong, but the "ra" has been iterarated once too often.
I notice that assist_string() was commented out of the newest ext_proto.h. The function never did anything on Windows, but it survived the transition to Max5 on MacOS with a faint vestige of functionality.
If assist_string() really doesn’t work anymore, then rescopy() won’t do anything, either. And resnamecopy() hasn’t worked since Max5. If the one’s commented out, the others probably should be, too.
Just noticed this while porting some old objects that had been left in 4land for a long time. If I get a chance I’ll see whether assist_string() really is dead before I change it to code that supports resources on OSX & Windows.
I am pleased to report that, on Mac OS, rescopy() and assist_string() still work as well as they did with Max 5.0.0.
Which will probably not stop me from switching to cross-platform code. Windows supports resource strings, too.-
Oh: the docs for intload describe it as lowload, and there are some grammatical errors in the text.
Not a documentation bug, just a suggestion :
maybe :
plus_dspstate(t_plus *x, long n);
should be added in the "Appendix: Messages sent to Objects"-"Message for Audio Objects" part of the doc.
(would have saved me some time)
[quote]Very minor, but curious: object_attr_getsym(obj, gensym("varname")) seems to deliver the empty symbol for newly-created UI objects but NULL for non-UI objects.[/quote]
Not so curious, just a documentation ambiguity. "varname" is a box attribute. When you call it on a UI object, the box responds with its value (gensym("")). When you call it on a non-UI object, the attribute is simply not found, so NULL is returned. To prove this, you could call object_attr_get() on the respective objects and see what you get back (an attr and NULL). So the @varname of "mynonuiobject" can be obtained from its box. object_obex_lookup(obj, gensym("#B"), &mybox); myvarname = object_attr_getsym(mybox, gensym("varname"));
OK… so if I want to connect objects in a patcher, I send the patcher a "connect" message with the boxes, not the objects?
(I’ve been experimenting with UI objects, so I’ve not seen any difference. I guess I should try it…)
OK, never mind: I got it. the documented operations basically apply for patchers and boxes. UI objects *are* their boxes. Non-UI objects are implementation-specific records contained in boxes (alongside attribute information and so on).
(I guess I was off school when the whole obex thing was covered in class.)
Thanks for the feedback. I’ve gotten most of the easy stuff on this list taken care of for our next SDK iteration.