Max 6.1.1 SDK

Mar 19, 2013 at 12:53am

Max 6.1.1 SDK

Hi all,

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

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.

Happy Coding!
Tim

#67178
Mar 19, 2013 at 6:55am

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 ?

Thanks,
Pierre

#241737
Mar 19, 2013 at 7:43am

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?

#241738
Mar 19, 2013 at 8:13am

Hi Pierre,

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.

Hope that helps,
Ádám

#241739
Mar 19, 2013 at 12:17pm

@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).

#241740
Mar 19, 2013 at 12:38pm

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?

#241741
Mar 19, 2013 at 3:28pm

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?

#241742
Mar 19, 2013 at 6:24pm

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.

Cheers,

#241743
Mar 19, 2013 at 6:25pm

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

#241744
Mar 23, 2013 at 6:55am

@Á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.

#241745
Mar 23, 2013 at 8:02am

Hi,

@Pierre Guillot : And you can add PPC arch in the picture. The good point is that the platform proliferation will discourage all bad developpers to spend time to provide useless objects for free. They can choose to never upgrade and keep on Max 5. And if you make money with your work ; i guess you will be concerned by the persistant lack of clear licence of the SDK. I’m surely wrong to be obssessed by this kind of detail ; but AFAIK with no licence, we are just not allowed to use it in our code, isn’t it ?

#241746
Mar 23, 2013 at 1:47pm

@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.

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…

#241747
Mar 25, 2013 at 9:46pm

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:

#define gensym_tr gensym

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.

Hope this helps.

Alex

#241748
Mar 25, 2013 at 9:55pm

@Adam

About licensing and linking.

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.

That is my understanding.

A

#241749
Mar 26, 2013 at 12:03am

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.

Cheers,
Tim

#241750
Mar 26, 2013 at 7:14am

Hi,

@AlexHarker:

“In this case the SDK having no clear license is probably a benefit, because it is open and without obvious restriction.”

Isn’t it the contrary ? I suppose you are right concerning dynamic linking ; but what for “commonsyms.c” (Devil is in the Detail).

Anyway it doesn’t matter, i will not foul this thread with a taboo question anymore. Nobody has interest to see expensive lawyers in the area.

#241751
Apr 11, 2013 at 7:29pm

Tim,

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

Thanks,
JM

#241752
Apr 11, 2013 at 9:09pm

consider it done

#241753

You must be logged in to reply to this topic.