cycling74/max-api

Low-level C-language application programming interface for Max

max-api's Issues

How might one change the number of inlets based on an attribute value?

Hi,
I'm trying to make an object that is a cross between select~ and radiogroup. I've successfully created a select~ clone that changes the number of inlets based on an argument, and I've also created a radiogroup clone that enables the user to change a value by clicking on the corresponding radiobutton and represents the radiobuttons' state graphically.

Now it is time to put them together and I've just realized that you can't really modify the arguments of graphical objects after they have been created, as their box is no longer visible once they have been rendered in their UI form.

I've tried just calling dsp_setup() again with the new number of inlets, but that seems to add around a hundred inlets (with no apparent relationship to the attribute value). Do I need to stop relying on dsp_setup() and just manually create and remove proxies? (And if so, how and when might I go about doing that?)

Alternatively, might there be a way to completely reinstantiate the object, carrying over all struct member and attribute values except for the number of inlets?

Or is what I am trying to do impossible?

not an issue. can delete

not an issue. can delete.

Win32 struct packing must be 2

This is true in the legacy Max SDK but did not make the jump in the cleanup/move to the Max API project.

object_method implementation doesn't support decorator objects

https://cycling74.com/forums/matrix_calc-documentation-wrong-several-sdk-examples-of-matrix-mop-fail

quoth JKC:

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);
}

Windows runtime setting not applied

max-api/script/max-pretarget.cmake

Line 10 in 0eecc9c

set(CMAKE_C_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")

Lines 10 to 18 in the pretarget cmake script appear to indicate that the windows MT/MTd runtimes should be being used. However, building the current master (e15bc91) of min-devkit on Windows generates projects which use the MD/MDd runtime. (Using VS2019 and CMake 3.14.3)

Which runtime is recommended? If MD/MDd is correct this script should be updated to avoid confusion.

missing define guard around NOMINMAX

The header is missing a define guard. Causing cascading macro redefinition problems that can span max, microsoft, and an infinite number of other-party headers.

max-api/include/c74_max_platform.h

Line 104 in c5e4ac0

#define NOMINMAX

Easy fix. Put a guard around it.
PR forthcoming.

Log entry from REQUIRE_VECTOR_APPROX needs more detail

When a single sample from the REQUIRE_VECTOR_APPROX does not match the reference vector, it is hard to tell which sample was the problem. The log entry looks like this:

/Volumes/Storage/Code/min-devkit/source/min-api/script/../  
include/c74_min_catch.h:27: FAILED:  
  REQUIRE( source[i] == Approx(reference[i]) )  
with expansion:  
  1.0 == Approx( -0.96875 )

I have a proposed fix that I will submit as a pull request momentarily.