Peter Lindener

As I understand, Cycle74 currently supports a "C" based External Max object API, as opposed one leveraging the object model available in C++....

I thus take note of the FLEXT C++ library..

http://grrrr.org/research/software/flext/

That also helps unify the programming model for External objects between Max and PureData...

What plans does Cycle74 have for supporting a C++ based Max external object API.?

i.e..will Cycle74 at some point choose to formally support the FLEXT library as the future road-map for support for external Max objects in C++..?

As I understand, Cycle74 currently supports a "C" based External Max object API, as opposed one leveraging the object model available in C++....
   I thus take note of the FLEXT C++ library..
See:  http://grrrr.org/research/software/flext/
   That also helps unify the programming model for External objects between Max and PureData...   

What plans does Cycle74 have for supporting a C++ based Max external object API.?
i.e..will Cycle74 at some point choose to formally support the FLEXT library as the future road-map for support for external Max objects in C++..?
    -Peter


cycle74-support-for-max-external-c-api

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?

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 

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

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

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.


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?

   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?

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

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

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

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. 

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

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.

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.


No, I don't need a C++ mapping. ( and yes, Im a professional C++ developer)

I think its unnecessary and Id prefer Cycling74 spent their time on other improvements to Max.

(e.g. optimizing Max, bug fixing and improving things like its "Projects" concept, to help large scale projects be more organized and have less namespace related issues)

- a C API is more portable for cross platform/language, and is efficient.

- the C objects implemented by Cycling is simple to use, there are much more 'complicated' parts of the API, so converting to C++ would make little difference in complexity

- every C++ programmers is used to mapping C to C++ (lots of APIs require it), its not something we have to 'think about'

- for non trivial externals, I encapsulate my 'model' -> Max mapping, so its a 'small' amount of code, and pretty irrelevant what language its in.

- I could create a set of C macros, to further trivialize the mapping if i needed to. (i don't due to above point :))

- it leaves the mapping between runtime message to language(/static) mapping in the hands of the developer, which adds flexibility for more complex projects.

As for PD/Max compatibility, no, i don't require it, I make a choice and then develop to that… even if my externals were compatible, my Max patches would still need modifying to work. If I ever did need it, as I encapsulate the Max mapping, it would be easy enough to write an alternative PD mapping. (or any other 'front end' I choose, which would be much more likely than PD)

So whilst, one can argue the merits of a C++ ( or [insert your favorite language here)

binding, I don't think there are sufficient problems or benefits to warrant the extra development and maintenance required.

Effort/Resources that I would prefer were spent elsewhere.

Reasons why:
- a C API is more portable for cross platform/language, and is efficient.
- the C objects implemented by Cycling is simple to use, there are much more 'complicated' parts of the API, so converting to C++ would make little difference in complexity
- every C++ programmers is used to mapping C to C++ (lots of APIs require it), its not something we have to 'think about'
- for non trivial externals, I encapsulate my 'model' -> Max mapping, so its a 'small' amount of code, and pretty irrelevant what language its in.
- I could create a set of C macros, to further trivialize the mapping if i needed to. (i don't due to above point :))
- it leaves the mapping between runtime message to language(/static) mapping in the hands of the developer, which adds flexibility for more complex projects.

As for PD/Max compatibility, no, i don't require it, I make a choice and then develop to that… even if my externals were compatible, my Max patches would still need modifying to work.  If I ever did need it, as I encapsulate the Max mapping, it would be easy enough to write an alternative PD mapping. (or any other 'front end' I choose, which would be much more likely than PD)

So whilst, one can argue the merits of a C++ ( or [insert your favorite language here)
binding, I don't think there are sufficient problems or benefits to warrant the extra development and maintenance required.
Effort/Resources that I would prefer were spent elsewhere.


My unofficial response is this: a C API is more compatible and portable to other languages, including C++, Obj-C and various others (incl. JavaScript and Java in our own code). If you want to write a C++ wrapper around the C API for ease of use, there's nothing stopping you from doing so. I don't think we have plans right now to do it ourselves, though.

Personally, I don't consider it a limiting factor at all (and I often write code in C++, too). Just my 2c, and as I said above, not an official position.

My unofficial response is this: a C API is more compatible and portable to other languages, including C++, Obj-C and various others (incl. JavaScript and Java in our own code). If you want to write a C++ wrapper around the C API for ease of use, there's nothing stopping you from doing so. I don't think we have plans right now to do it ourselves, though. 

Just clarify regarding Jamoma: Jamoma is not about creating Max classes in C++, though you can do that if you like. Jamoma is essentially defining its own runtime environment which is then being mirrored to Max (or Ruby or one of several other environments). So it's pretty different beast...

And if I had it to do all over again would I use C++ or C for the Jamoma Core? For a whole variety of reasons (some of which are mentioned above) it would be a difficult choice.

Just clarify regarding Jamoma: Jamoma is not about creating Max classes in C++, though you can do that if you like.  Jamoma is essentially defining its own runtime environment which is then being mirrored to Max (or Ruby or one of several other environments).  So it's pretty different beast...

And if I had it to do all over again would I use C++ or C for the Jamoma Core?  For a whole variety of reasons (some of which are mentioned above) it would be a difficult choice.


oops!....sorry having asked about Cycling74's support for Max's external object API in some way translates into a perception of "hi maintenance"... I've grafted enough 'C" code into C++ to fully understand the point some are making here that a C API is good enough..

Timothy's reflection on this trad-off between 'C' and C++ concerning Jamoma is interesting to reflect on. Since he clearly has been swimming in the deep end.. I just finished reading the paper describing what it took to persuade Jamoma's open source C++ code to also support dynamic linkage...

...as I read about all the effort Tim and the rest of the Jamoma team put into supporting this very dynamic run-time..

now that I'm known as a "hi maintenance" kind of guy, who fantasizes that various pieces of software might more easily inter-operate...

has anyone else on this thread checked out:

https://parasol.tamu.edu/groups/pttlgroup/omm/

https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf

http://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus-Part-The-Case

Its my hope that Tim might already be collaborating with

oops!....sorry having asked about Cycling74's support for Max's external object API in some way translates into a perception of "hi maintenance"...   I've grafted enough 'C" code into C++ to fully understand the point some are making here that a C API is good enough..
   Timothy's reflection on this trad-off between 'C' and C++ concerning Jamoma is interesting to reflect on. Since he clearly has been swimming in the deep end..   I just finished reading the paper describing what it took to persuade Jamoma's open source C++ code to also support dynamic linkage...
   ...as I read about all the effort Tim and the rest of the Jamoma team put into supporting this very dynamic run-time..
   now that I'm known as a "hi maintenance" kind of guy, who fantasizes that various pieces of software might more easily inter-operate...
has anyone else on this thread checked out:
 Open Multi-Methods for C++
see: https://parasol.tamu.edu/groups/pttlgroup/omm/
and: https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf
and: http://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus-Part-The-Case
   Its my hope that Tim might already be collaborating with
Stroustrup's team at Texas A&M ?
see: http://www.stroustrup.com/

Well I never thought I would have any constructive to say on this issue, but as a starting point, I think gen~ is a very good language if you are interested in audio and don't have prior programming experience. It's not good too many complications and its already got a lot built in for audio.

The only problem is, the documentation kind of assumes you already know some programming experience. Its very difficult for programmers to talk so that non-programmers can understand them. A new user could probably write a really good tutorial for non-programmers.

Well I never thought I would have any constructive to say on this issue, but as a starting point, I think gen~ is a very good language if you are interested in audio and don't have prior programming experience. It's not good too many complications and its already got a lot built in for audio. 

The only problem is, the documentation kind of assumes you already know some programming experience. Its very difficult for programmers to talk so that non-programmers can understand them. A new user could probably write a really good tutorial for non-programmers.


Cycle74 support for Max External C++ API?