diablodale

Hi. I request some clarification for porting my dp.kinect external to windows x64.

1. Porting to x64 while still supporting Max 5

So far, I have been able to compile w/ the recent Max 6 SDKs on the x86 platform and the external will run on Max 5.1.9. Now porting to x64, are there any things I should keep in mind in porting such that when it is compiled, I maintain Max 5.1.9 32-bit compatibility?

I've declared several max wrapper object methods using max_addmethod_usurp_low()

In SDK 6.1.4 p.179 it witten the A_GIMME methods may still use the long type for ac without issues. Also p.19 shows long/t_atom.

So...is it *may* still use the long type for ac -or- *must* still use the long type for ac?

* If it is may...then I'll update the code to use t_atom_long

* If it is must...then I'll leave the code unchanged and continue to use long. And I request the SDK be updated to specify that it must be used.

3. A_CANT signature on Max system handlers (e.g. assist)

For Max system handlers, like the inlet/outlet assist message handler defined with:

addmess((method)max_dp_kinect_assist, "assist", A_CANT, 0);

I see on p.76 it still uses two longs in its signature.

For internal Max A_CANT callers/handlers, should we never switch to t_atom_long? Should we instead, look handler by handler someplace (SDK doc, header files, etc) to see if it was changed to t_atom_long?

It is clear in the Max SDK 6.1.4 doc p.177 that we should use t_filepath instead of a short. However, the header files continue to declare the signatures with short like in locatefile_extended() and path_topotentialname(). While the headers eventually typedef this back to a short, it causes confusion for developers with modern dev tools which prompt us with function signatures. I suggest the header signatures for all the appropriate functions (open_dialog, locatefile_extended, etc.) to no longer use short and instead use t_filepath as states in the SDK doc.

In the 5.1.7 and 6.1.4 SDKs, I see support for double floats as attributes given macros like CLASS_ATTR_DOUBLE. I also see support in both SDKs for double floats passed into atoms with the atom_setfloat() signature being declared with double in its signature. Does this imply that until recently, the attribute call *did* store a 64-bit float in my structure however the atom_setfloat() *converted the float 64->32 bit?

SDK 6.1.4 p.177 writes for me to use t_atom_float when get/setting atoms. If I were to do this:

t_atom_float myvar = 1.234;
atom_setfloat(pAtom, myVar);

Given the typedef's in the recent SDK, that would mean that when compiled on:

which causes the x86 compile to not match the signature for atom_setfloat which expects a double as its 2nd arg.

Contrast this to the atom_setlong() and t_atom_long which correctly matches needed signatures on both Max SDKs.

Given the above mismatched signature and the existence of/relation to distinct functions like atom_setfloat_array() and atom_setdouble_array(), what is the intention or benefit of using t_atom_float?

6. _jit_sym_long on customer max wrapper attributes

I have created many custom attributes on a max wrapper for a MOP. I needed to define attributes on the attributes so used ways like:

attr = (t_jit_object *)jit_object_new(_jit_sym_jit_attr_offset, "sensorrate",
_jit_sym_long, JIT_ATTR_GET_DEFER_LOW | JIT_ATTR_SET_USURP_LOW,
NULL, NULL, calcoffset(t_max_dp_kinect, lSensorSampleRate));

This uses the _jit_sym_long symbol rather than _sym_long. Will the new of the _jit_sym_*** symbols in these declarations cause any problems? Or are they 1:1 matches with _sym_*** and any caveats in the x64 port as described in the recent SDK?

7. How do I manage a 64-bit long attribute? In SDK 6.1.4 p. 179 is written "you will need to use the new atom_long attribute type". I can find no "atom_long" symbol or any other pages (99, 245, 770, etc.) in the SDK which reference a new symbol for this. How do I declare (or retrieve) knowledge of a 64-bit long attribute?

8. When reading in a file via the sysfile APIs, it is very common to do something like the following:

t_ptr_size size;
sysfile_geteof(fh, &size);
buffer = (BYTE *)sysmem_newptr((long)size);
sysfile_read(fh, &size, buffer)

All the APIs above use a t_ptr_size *except* for the memory allocation at sysmem_newptr. It wants a platform long. In the world of 64-bits there might be some extreme case where a platform long is not large enough to meet the needs of a memory call.

1. Porting to x64 while still supporting Max 5
So far, I have been able to compile w/ the recent Max 6 SDKs on the x86 platform and the external will run on Max 5.1.9. Now porting to x64, are there any things I should keep in mind in porting such that when it is compiled, I maintain Max 5.1.9 32-bit compatibility?

2. A_GIMME signature
I've declared several max wrapper object methods using max_addmethod_usurp_low()
In SDK 6.1.4 p.179 it witten the A_GIMME methods may still use the long type for ac without issues. Also p.19 shows long/t_atom.

So...is it *may* still use the long type for ac   -or-   *must* still use the long type for ac?
* If it is may...then I'll update the code to use t_atom_long
* If it is must...then I'll leave the code unchanged and continue to use long. And I request the SDK be updated to specify that it must be used.

3. A_CANT signature on Max system handlers (e.g. assist)
For Max system handlers, like the inlet/outlet assist message handler defined with:
    addmess((method)max_dp_kinect_assist, "assist", A_CANT, 0);
I see on p.76 it still uses two longs in its signature.

4. file code short vs. t_filepath
It is clear in the Max SDK 6.1.4 doc p.177 that we should use t_filepath instead of a short. However, the header files continue to declare the signatures with short like in locatefile_extended() and path_topotentialname(). While the headers eventually typedef this back to a short, it causes confusion for developers with modern dev tools which prompt us with function signatures. I suggest the header signatures for all the appropriate functions (open_dialog, locatefile_extended, etc.) to no longer use short and instead use t_filepath as states in the SDK doc.

5. Double floats in attributes and atoms
In the 5.1.7 and 6.1.4 SDKs, I see support for double floats as attributes given macros like CLASS_ATTR_DOUBLE. I also see support in both SDKs for double floats passed into atoms with the atom_setfloat() signature being declared with double in its signature. Does this imply that until recently, the attribute call *did* store a 64-bit float in my structure however the atom_setfloat() *converted the float 64->32 bit?

Given the typedef's in the recent SDK, that would mean that when compiled on:
* x86 myVar is a 32-bit float
* x64 myVar is a 64-bit double
which causes the x86 compile to not match the signature for atom_setfloat which expects a double as its 2nd arg.

6. _jit_sym_long on customer max wrapper attributes
I have created many custom attributes on a max wrapper for a MOP. I needed to define attributes on the attributes so used ways like:

All the APIs above use a t_ptr_size *except* for the memory allocation at sysmem_newptr. It wants a platform long. In the world of 64-bits there might be some extreme case where a platform long is not large enough to meet the needs of a memory call.


porting-mxe-to-windows-x64-clarification-please

I don't if it will help you but personally I use approximately the same code and it works for 32 & 64 bits - Mac & Windows (You can take a look at the GUIs of the Hoa Library, for example : 

https://github.com/CICM/HoaLibrary/blob/master/Max/hoaSpace_UI/hoa.space.cpp

Hi,
I don't if it will help you but personally I use approximately the same code and it works for 32 & 64 bits - Mac & Windows (You can take a look at the GUIs of the Hoa Library, for example : https://github.com/CICM/HoaLibrary/blob/master/Max/hoaSpace_UI/hoa.space.cpp).


porting mxe to windows x64 clarification please