matrix_calc() documentation wrong; several SDK examples of matrix MOP fail

Hi Dale,

In general, it is not wise to use newer headers than the minimum Max version you'd like to support. Our SDK is not generally structured for such legacy support. Almost anything built with the 6.1.x headers and SDK should work fine in Max 8 (a small number of caveats of feature changes might be unsupported, but there have been no ABI changes within a given OS/Architecture).

That said, thank you for bringing this to our attention as it points out some flaws that we'd like to address. The real reason you are encountering this is in flaws from the Max-API headers rather than using the Max-SDK headers. The Max-API headers are part of the Min-API and DevKit work and are not as road tested as the standard SDK. Despite some of the language on the Max-API github page, the "Legacy SDK" should be considered primary.

The limitation is that the Max-API headers, rather than calling object_method_imp() like the Max SDK does, uses c++ style function overloading, and specifically calls object_getmethod() to establish which method to call. With Jitter MOP IO objects, there is an esoteric feature of our object system called decorators, which enable one object to be added to an existing object to provide an additional set of methods. object_getmethod() does not support retrieving the correct "getinfo" methods from the objects they decorate. object_method() and object_method_imp() from the standard SDK on the other hand correctly resolves them.

This is an oversight in the object_getmethod() implementation, which will be corrected in a future version of Max. However, that doesn't help your legacy context if you still are determined to use the Max-API. For that, the better solution is to change the Max-API implementation to call object_method_imp() rather than calling the results of object_getmethod(). For example the following and all similar

    inline void* object_method(t_object* target_object, t_symbol* method_name) {
        method m = object_getmethod(target_object, method_name);
        if (m)
            return m(target_object);
        else
            return nullptr;
    }

Should be changed to

    inline void* object_method(t_object* target_object, t_symbol* method_name) {
        return object_method_imp(target_object, method_name, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL);
    }

We will also make such a change for the Max-API in the future.

To summarize:

1. The issue here is not ABI related, but due to inconsistencies in the way that object_getmethod() and object_method_imp() support decorator objects, and the usage of these separate paths in the Max-API (breaks decorator usage) and Max-SDK (supports decorator usage).

2. The most supported and recommended way for you to proceed would be to use the headers included with the binary library you are linking with (Max 6.1.3 SDK in this case).

3. If you still want to venture into territory that is unsupported, for your particular development needs/preferences, you may make the modifications to the Max-API implementation of object_method() to use object_method_imp() suggested above.

4. We will fix object_getmethod() and the Max-API object_method() implementation to support decorator usage in future Max and Max-API releases

I hope that this clarifies this confusing situation a bit. Please let us know if this doesn't solve your needs at this time. If it is something reasonable for us to support or follow up with relevant information, we will do so.

Thanks,
Joshua