Cycle74 support for Max External C++ API?

*Cycling...

Opps!... I stand corrected, the real cool firm's name is a VERB, as opposed to a noun.. just goes to show I'm still a newbe when it comes to developing Max external object... any clue on what Cycling74's support for a C++ based external object API might be?

I am reminded of Donald Knuth's reply when people asked him why he didn't finally use something other than his MIX language for The Art of Computer Programming. (Essentially, he's been asked the same question for FORTRAN, COBOL, PL/I, APL, BASIC, Pascal, C, C++, Java, Python, and a zillion other languages, each of which went through a cycle of being "the state-of-the-art-programming-langauge-everyone-is-using-and-why-use-anything-else?")

If you're actually experienced with programming, it doesn't really matter what language an API uses. And C++ is just as bad a programming language as most of the other ones. Demanding that someone rewire an API to match your personal favorite programming paradigm is essentially an admission that you're not a particularly competent programmer (sorry, but it has to be said).

When I got started with Max programming, my language of choice was Pascal. While I briefly considered writing a wrapper that would allow writing Max externals in that language, at the end of the day my time was far better invested in getting on with using C (and putting up with its shortcomings, most of which, btw, are echoed in C++).

That said, FLEXT is an admirable project. If I were particularly interested in cross-platform development for both Max and Pd, I might possibly be using it. But for the C++? Not so much.

PS: Professor Knuth's answer to the question above was that if he'd reworked his examples in each of the languages that have been requested, he'd never have gotten around to either TeX or the fourth volume.

Dear
Peter Castine-

I'm not sure why you would mention Prof. Knuth as a prelude to somehow suggesting that because I would ask such a question as to Cycleing74's potential support for a C++ based Max external object programming API.. only then to somehow infure that my programming background must therefor be somehow limited in a way that somehow your would not be?....
.... to clear up your less than complete understanding of my background as a programmer... there seems to be a level of unfounded presumption regarding your assessment in the depth of my background as a programmer..
..are you sure this is how Cycling74 is wanting to develop a working relationships with potential developers.?..not sure exactly what else to say here?

-Peter

there is a thing called "mage", a library in c++ for voice synthesizing wiht real-time parameters change, the maxMSP external is only there as a source but you can see how they integrate the c++ library from the c max external
https://github.com/numediart/mage/blob/master/examples/maxmsp/mage~.cpp

Perhaps It would be good to clarify a few things regarding my response to Peter Castine that I just posted above.

I have done enough systems level programming in my life to know that when planing the road-map for a more in depth programming project, that one of the first thongs one best do is check both the stability as well as potential longevity of the foundation API's upon which one's software will come to depend upon..
...now this might sound obvious to many who have done there best to build upon the work of others... but then who knows...maybe it somehow might show how little I have come to understand...
...while I have taken the time and effort to study the full extent of Dr. Stroustrup's ongoing evolution of the C++ programming language..
see: http://www.stroustrup.com/C++.html and I'm fairly impressed with the direction he is taking things as C++14 come into the standards process...
... I guess it's clear that some may be having trouble keeping up with everything that is currently under development in modern programming language evolution.

I don't think that this issue really has anything to do with the merits of one language vs. another, this is really about styles of programming. The central problem with the Max API is that it requires the user to use a non-objective language to write an object class. This fact alone means that it takes a considerable effort and amount of study in order to even use the API.

I've been writing plugins recently for a flow-based programmable machine vision system called Adaptive Vision. This is conceptually similar to Max, you're creating a visual object which has inputs and outputs which can be connected by the user to other visual objects. The Adaptive Vision SDK is C++ based, so to create an object, you write a class inheriting from their SDK base class and override certain methods. For anyone used to objective programming this is a trivial task, and you can be creating plugins that work very easily.

By comparison, with it's C-based 'objective' methods, the Max SDK is incredibly unfriendly and verbose. Users are required to learn and understand a huge amount of boilerplate code just to perform tasks which are very simple in a properly objective language.

Having said all this however, I can totally understand the historical reasons why the Max SDK is the way it is, and also the reasons why making any kind of changes to it at this stage are perhaps a waste of development time which would be better spent on the core application.

Thanks Dave B. for expressing our shared concern when it comes to Max's current "c" based external "object" API,...
Thanks Raja for pointing me towards Jamoma
see: http://jamoma.org/ via http://74objects.com/
Then I reflect that it might reflect well on the more socialized aspects of Cycling74 perhaps (at least partially?) open source savvy culture if they might leverage some of these Mac community attempts to support a C++ Max external object API.. and in some capacity officially support a C++ API thats a little bit more in sync with our time... That is: If I'm going to make the decision to invest the time in writing a production class set of objects for the Max audio/visual programming environment, maybe I would like to know that Cycling74 likewise would be committed to supporting those who might invest in helping build the Max programing eco-system.