Luigi Castelli

after spending some months thinking whether I should actually ask this question or not, in light of some new threads that have recently popped up in this Forum and at the risk of sounding controversial or argumentative, I decided to finally ask the damn question anyway.

https://cycling74.com/forums/max-sdk-vs-max-api

the final conclusion is that if we are setting up any new projects, we are probably better off using the traditional Max-SDK, unless we have concrete needs of min or maxapi.

What is there to need in min-devkit or Max-API though?

The Max-API is a copy of the traditional max-SDK API headers, put inside a C++ namespace.

Sure... that could have the advantage of making name conflicts less likely to occur, but honestly in the world of Max/MSP object development I never had that issue. However that also creates an undesired side-effect: it duplicates all the traditional Max-SDK headers. Now in case of updates to the Max-SDK there are two sets of identical headers to maintain. Not ideal if you ask me.

The min-devkit features a number of basic DSP modules. (delay, limiter, filters, etc...)

Most of them are already available in the standard distribution as compiled Max external objects. Remember that it is possible to instantiate Max/MSP external objects in code as well, in case you need their functionality inside your C/C++ project. Also, there already exist a number of C/C++ DSP libraries that have been around for some time and thus are more robust and well-tested than Min. Many of them even feature a richer set of DSP classes. So why reinventing the wheel?

I have read threads on this Forum that explicitly refer to the Max-SDK as "deprecated" in favor of the min-devkit. As far as I can tell that is simply false. I don't see that happening any time soon.

The vast majority of Max externals are written in C using the traditional Max-SDK.

Even in the above mentioned thread Rob Ramirez said: "for the most part the max-sdk remains the source of truth and the maxapi is there to support min-devkit projects."

I see very committed users (such as Omar Hamido for example) trying to make sense of certain programming topics (i.e. threading), where the answer would be much more easily found if the context were switched to the traditional Max-SDK.

I am not trying to discourage the use of C++ or C++ APIs in any way. C++ is my language of choice and I personally think Max/MSP/Jitter should be written in C++. But that's a conversation for another time... :)

I am really struggling to see what the purpose of the min-devkit is, given the way the Max/MSP/Jitter infrastructure is setup.

Where does it position itself in the spectrum of developer tools related to Max/MSP/Jitter?

What specific problems is it aiming to resolve?

When would it be better/more convenient to use over the traditional Max-SDK API written in C?

1) our beloved friend Tim Place spent a considerable amount of time writing and maintaining it

2) there is a GitHub repository where users are regularly contributing to the code.

Therefore I am sure there must be value to it and it must have a well defined purpose.

What is the purpose of the min-devkit?
What problems is it aiming to resolve?

According to this thread,
https://cycling74.com/forums/max-sdk-vs-max-api
the final conclusion is that if we are setting up any new projects, we are probably better off using the traditional Max-SDK, unless we have concrete needs of min or maxapi.

What is there to need in min-devkit or Max-API though?
The Max-API is a copy of the traditional max-SDK API headers, put inside a C++ namespace.
Sure... that could have the advantage of making name conflicts less likely to occur, but honestly in the world of Max/MSP object development I never had that issue. However that also creates an undesired side-effect: it duplicates all the traditional Max-SDK headers. Now in case of updates to the Max-SDK there are two sets of identical headers to maintain. Not ideal if you ask me.

The min-devkit features a number of basic DSP modules. (delay, limiter, filters, etc...)
Most of them are already available in the standard distribution as compiled Max external objects. Remember that it is possible to instantiate Max/MSP external objects in code as well, in case you need their functionality inside your C/C++ project. Also, there already exist a number of C/C++ DSP libraries that have been around for some time and thus are more robust and well-tested than Min. Many of them even feature a richer set of DSP classes. So why reinventing the wheel?

I have read threads on this Forum that explicitly refer to the Max-SDK as "deprecated" in favor of the min-devkit. As far as I can tell that is simply false. I don't see that happening any time soon.
The vast majority of Max externals are written in C using the traditional Max-SDK.
Even in the above mentioned thread Rob Ramirez said: "for the most part the max-sdk remains the source of truth and the maxapi is there to support min-devkit projects."

I am really struggling to see what the purpose of the min-devkit is, given the way the Max/MSP/Jitter infrastructure is setup.
Where does it position itself in the spectrum of developer tools related to Max/MSP/Jitter?
What specific problems is it aiming to resolve?
When would it be better/more convenient to use over the traditional Max-SDK API written in C? 

I am asking all these questions because:
1) our beloved friend Tim Place spent a considerable amount of time writing and maintaining it
2) there is a GitHub repository where users are regularly contributing to the code.

Therefore I am sure there must be value to it and it must have a well defined purpose.
I just can't see it.

Hello developers,
after spending some months thinking whether I should actually ask this question or not, in light of some new threads that 

what-is-the-purpose-of-the-min-devkit

Hey Luigi, thanks for the thoughtful question regarding min. Unfortunately the best person to give a thoughtful answer to this is Tim Place, who is unlikely to respond anytime soon since he is no longer with the company.

My best concise answer is, don't overthink it (winky emoji). If you have taken a look at min and what it offers (of which there is 

) and it doesn't start your engine, then there isn't much to say. You are an experienced developer, fully comfortable with utilizing the max-sdk to achieve what you want from it and don't have a need for all the bells and whistles offered by min.

To expound a bit, min-devkit and max-sdk are not comparable, as min is a completely new environment for developing max externals. This should be evident simply by looking at 

 for any external distributed with min (for an experienced max external dev, it's almost unrecognizable). Some of the benefits of min should also be evident from looking at that code, e.g. minimum boilerplate, and max external specific templates providing common functionality.

In addition to fully embracing modern c++, min also provides a testing framework, cmake scripts, automatic documentation generation, package creation scripts, object creation scripts, and a max-patch cmake interface (recently broken, but soon to be updated).

For that particular user, given what they posted that was my best attempt at advice taken with a grain of salt. but please note I ended that post saying "I strongly recommend taking a look at the various components of min before making that decision."

Yes absolutely, the max-sdk is not deprecated. If you are comfortable with the max-sdk, stick with it. If you want to try out some new hotness, give min a spin. We will be updating the Package Manager version to address some breakage with the cmake patch interface sometime in the next few days.

My best concise answer is, don't overthink it (winky emoji). If you have taken a look at min and what it offers (of which there is plenty of documentation) and it doesn't start your engine, then there isn't much to say. You are an experienced developer, fully comfortable with utilizing the max-sdk to achieve what you want from it and don't have a need for all the bells and whistles offered by min.

To expound a bit, min-devkit and max-sdk are not comparable, as min is a completely new environment for developing max externals. This should be evident simply by looking at the code for any external distributed with min (for an experienced max external dev, it's almost unrecognizable). Some of the benefits of min should also be evident from looking at that code, e.g. minimum boilerplate, and  max external specific templates providing common functionality.

According to this thread, https://cycling74.com/forums/max-sdk-vs-max-api the final conclusion is that if we are setting up any new projects, we are probably better off using the traditional Max-SDK, unless we have concrete needs of min or maxapi.

For that particular user, given what they posted that was my best attempt at advice taken with a grain of salt.  but please note I ended that post saying "I strongly recommend taking a look at the various components of min before making that decision."

I have read threads on this Forum that explicitly refer to the Max-SDK as "deprecated" in favor of the min-devkit. As far as I can tell that is simply false. I don't see that happening any time soon. 

Yes absolutely, the max-sdk is not deprecated. If you are comfortable with the max-sdk, stick with it. If you want to try out some new hotness, give min a spin. We will be updating the Package Manager version to address some breakage with the cmake patch interface sometime in the next few days.


What is the purpose of the Min-DevKit?