Timothy Place

A new version of the Max SDK has been released. You can download it @ 

Highlights include an appendix chapter detailing how to update your externals for 64-bit architectures, an appendix chapter about distributing your externals using the new "packages" feature in Max 6.1, and a handful of new examples, documentation fixes, etc.

A new version of the Max SDK has been released.  You can download it @ https://cycling74.com/downloads/sdk/

max-6-1-1-sdk

I'm glad to hear it. Do you have any statistic about how many people that use Max 5, Max 6 and Max 6.1 ? Is it still pertinent to compile against the Max 5 sdk for 32-bit architectures ?

This might be answered elsewhere, but are Max 6.1 externals backwards compatible? Can I compile against the new SDK and have my external run in Max 5 or Max 6.0?

this might not be a relevant statistic, but almost everybody I know is still using Max 5, including myself. I am still getting commissions explicitly asking for Max 5-compatible externals. But again, this is just what I see around myself, which is clearly not a real statistic.

@aengus: Yes, you can! unless you try to use some specific method of Max 6 in Max 5 (for instance dsp_add64*) it will work.

*dsp_add64: look at simplemsp~ if you want to compile an audio external with 32 bit float precision in Max 5, 64 bit precision in Max 6 which also support both architectures (x86/x64).

That's interesting, I've been building most of my externals with the Max 5 SDK in order to maintain compatibility so far. Other than dsp_add64 and stuff like the dictionary passing functions, what other methods are only present in the Max 6 SDK?

Also, I notice the module definition file (.def) doesn't seem to be included in the VS projects anymore. Is the .def file now redundant due to the placement of "C74_EXPORT" before the main function?

Yes, using C74_EXPORT is preferred to the .def file. For one thing, you would otherwise need 2 different files for your 32- and 64-bit builds.

Yes, using C74_EXPORT is preferred to the .def file.  For one thing, you would otherwise need 2 different files for your 32- and 64-bit builds.

You can, of course, continue to use .def files in your own projects if you wish...

@Ádám : That means we still have to make the libraries for max 5, max 6 and max 6.1... and for Windows and Mac... I hope one day, there will be only one Os and only one Max. Thanks for the reply.

@Ádám : That means we still have to make the libraries for max 5, max 6 and max 6.1... and for Windows and Mac... I hope one day, there will be only one Os and only one Max.  Thanks for the reply.


As far as I understand, yes, this means that we need separate builds for all these systems, although if you don't care for optimisation, you might spare some of the builds (for example, externals compiled for Max 5 will also run on Max 6). Currently I am just in the process of upgrading The sadam Library to Max 6.1 (I decided to skip Max 6 at this point), and at some point I'll drop PPC support (the reason is simple: I don't have a PPC and Apple has an arrogant policy of excluding the tools required for PPC builds from XCode. Currently I have a 'hacked' XCode 4 development system which has the required PPC stuff added by hand, but once I upgrade from Snow Leopard to a more decent OS, I know from other people that I won't be able to do the trick any longer. And, although I am still successful in resisting against the 'upgrade-pressure', my experience is that sooner or later I'll be forced to do an OS upgrade anyway.

On the other hand, although (of course) I don't enjoy doing all this extra work, I am glad to pay the price of having multiple operating systems on the market. I am sure that, without competition, the One Operating System On Earth would be quite bad. As an example, Windows has benefited a lot of the competition with *nix systems.

@Nicolas: Good point. I remember having a lot of discussions on these forums without any clear statement about what we are allowed and what we are not allowed to do. For example, it is unclear to me until this very day whether we are allowed to use GPL code in an external: 'GPL-orthodox guys' say that, since Max is closed source, you're not even allowed to link against the Max SDK if your external also uses GPL-licensed things (even if you make your external GPL-licensed). On the other hand, in my opinion if you link dynamically against the Max SDK, I think you're not violating too many rules. Static linkage is another question, as in the download area of Cycling '74 they say that you're not allowed to re-distribute the SDK. It is an interesting legal question whether you're allowed to 'partial-redistribution', which is what, in a certain way, happens during static linkage...

@Pierre Guillot:
As far as I understand, yes, this means that we need separate builds for all these systems, although if you don't care for optimisation, you might spare some of the builds (for example, externals compiled for Max 5 will also run on Max 6). Currently I am just in the process of upgrading The sadam Library to Max 6.1 (I decided to skip Max 6 at this point), and at some point I'll drop PPC support (the reason is simple: I don't have a PPC and Apple has an arrogant policy of excluding the tools required for PPC builds from XCode. Currently I have a 'hacked' XCode 4 development system which has the required PPC stuff added by hand, but once I upgrade from Snow Leopard to a more decent OS, I know from other people that I won't be able to do the trick any longer. And, although I am still successful in resisting against the 'upgrade-pressure', my experience is that sooner or later I'll be forced to do an OS upgrade anyway.

@Nicolas: Good point. I remember having a lot of discussions on these forums without any clear statement about what we are allowed and what we are not allowed to do. For example, it is unclear to me until this very day whether we are allowed to use GPL code in an external: 'GPL-orthodox guys' say that, since Max is closed source, you're not even allowed to link against the Max SDK if your external also uses GPL-licensed things (even if you make your external GPL-licensed). On the other hand, in my opinion if you link dynamically against the Max SDK, I think you're not violating too many rules. Static linkage is another question, as in the download area of Cycling '74 they say that you're not allowed to re-distribute the SDK. It is an interesting legal question whether you're allowed to 'partial-redistribution', which is what, in a certain way, happens during static linkage...


FWIW - I've been through the 64bit port with the convolution reverb and actually I've become aware that you can compile against the Max 6.1.1 SDK and be compatible back to Max 5. This has a few caveats:

1 - obviously you can't use routines that do not exist in the app you want to be compatible back to (the external won't load).

2 - dsp_add64 etc can be avoided by calling them through object_method - thus you can have both 32 bit and 64 bit perform routines in a single package.

3 - some of the attribute macros for 6.1.1 call gensym_tr and this does not exist pre 6.1 - this an be avoided with a macro define in your code like:

The current in-house version of the HISSTools Impulse Response was compiled in this way and is compatible back to Max 5 with no issues. If anyone is trying to figure out how to compile once across different versions I might be able to help.

1 - obviously you can't use routines that do not exist in the app you want to be compatible back to (the external won't load).
2 - dsp_add64 etc can be avoided by calling them through object_method - thus you can have both 32 bit and 64 bit perform routines in a single package.
3 - some of the attribute macros for 6.1.1 call gensym_tr and this does not exist pre 6.1 - this an be avoided with a macro define in your code like:

Regarding GPL - you cannot use GPL code in an external period - it is not licensed for dynamic or static linking to non-open code (Max).

If the code is LGPL you can make an external because externals are dynamically linked and this is permitted by this license.

In this case the SDK having no clear license is probably a benefit, because it is open and without obvious restriction. Therefore, I don't believe there is any significant issue with LGPL code. However, your code for an external using LGPL must abide by the license if the code is statically linked, and hence be open etc. etc. If you dynamically link to the LGPL in your external then your code can be closed.

Regarding GPL - you cannot use GPL code in an external period - it is not licensed for dynamic or static linking to non-open code (Max).
If the code is LGPL you can make an external because externals are dynamically linked and this is permitted by this license.

If you define NO_TRANSLATION_SUPPORT as a preprocessor symbol (-d option to gcc) in your project settings then the gensym_tr() is mapped to gensym() for you.

Thanks for adding that NO_TRANSLATION_SUPPORT #define--could you also have it map str_tr() to something compatible with Max 5?