AudioMatt

Disclaimer: I absolutely think gen is amazing and a triumph for Max.

As I understand it, Gen translates Genexpr into C, compiles it and runs it. I would love the ability to decouple this process so that I could write/compile/run C code in max OR have the ability to write gen objects in C. If C74 is worried about crashes, a feature to autosave before compilation could help that.

* Genexpr is amazing for rapidly prototyping audio-rate algorithms but really hard to build large projects with. The errors are many times meaningless, the IDE is tiny, and, in general, it's hard to manage.

* While gen may be more efficient than vanilla MSP objects, no one who writes audio algorithms would code as inefficiently and chaotically as the code that Gen exports.

* Managing any sort of remotely complex data structure in gen is next to impossible.

* Being able to write efficient audio code without constantly reloading max would be a revolution.

Disclaimer:  I absolutely think gen is amazing and a triumph for Max.

As I understand it, Gen translates Genexpr into C, compiles it and runs it.  I would love the ability to decouple this process so that I could write/compile/run C code in max  OR have the ability to write gen objects in C.   If C74 is worried about crashes, a feature to autosave before compilation could help that.

* Genexpr is amazing for rapidly prototyping audio-rate algorithms but really hard to build large projects with.  The errors are many times meaningless, the IDE is tiny, and, in general, it's hard to manage.
* While gen may be more efficient than vanilla MSP objects, no one who writes audio algorithms would code as inefficiently and chaotically as the code that Gen exports.
* Managing any sort of remotely complex data structure in gen is next to impossible.
* Being able to write efficient audio code without constantly reloading max would be a revolution.

Disclaimer:  I absolutely think gen is amazing and a triumph for Max.
As I understand it, Gen translates Genexpr into C, compiles it and run

feature-request-c~-and-c

Thanks for the disclaimer, and I can understand these points :-)

I feel like I should defend the generated code a little bit though haha! While we do make an effort to ensure the code generated by gen~ is efficient, there's no way that it can make all the informed decisions that a pro programmer can. Also, since we are using the clang compiler, which is itself very effective and the result of many programmer-centuries of work, we decided to let that compiler do most of the heavy lifting in optimization, and we focused on a few key areas where we knew we could make a difference (e.g. lifting out control-rate processing where possible from the sample loop). Many other things, like constant folding, moving operations around for optimal performance, etc. etc. are taken care of more effectively by Clang. Moreover, adding such things inside Gen would actually slow compilation down, which we found to be noticeable in larger patchers, so we trimmed that quite a bit without losing any performance in the machine code. And yes, as a result the code is pretty chaotic to a human reader, but it wasn't originally intended for humans :-)

Anyway, that aside, there are a few projects here & there that people have written to smoothen the workflow for C++ programmers developing audio routines for Max.

I can also point to one that I made for a large and complex installation (where I needed to be able to hot-compile/reload quite heavy bits of simulation code without restarting the whole thing). Caveat: I offer no support, but maybe this might do what you need or point in the general direction. The idea is very simple: the C++ code lives inside a dylib/dll that is unloaded, recompiled, and reloaded whenever the code is edited. This process could be pretty readily automated thorugh a node.script for example. I didn't really 'release' this as such because a) it can pretty easily be used to crash Max or worse and b) it's pretty niche and c) too much of a fiddly setup for most users. But if you're curious, grab the 'devel' branch of 

https://github.com/worldmaking/Max_Worldmaking_Package

 and take a look at the "dyn" object. It doesn't do MSP IO, but wouldn't be too hard to make a dyn~ if you can grok dyn.

Anyway, that aside, there are a few projects here & there that people have written to smoothen the workflow for C++ programmers developing audio routines for Max. 

I can also point to one that I made for a large and complex installation (where I needed to be able to hot-compile/reload quite heavy bits of simulation code without restarting the whole thing). Caveat: I offer no support, but maybe this might do what you need or point in the general direction. The idea is very simple: the C++ code lives inside a dylib/dll that is unloaded, recompiled, and reloaded whenever the code is edited. This process could be pretty readily automated thorugh a node.script for example. I didn't really 'release' this as such because a) it can pretty easily be used to crash Max or worse and b) it's pretty niche and c) too much of a fiddly setup for most users. But if you're curious, grab the 'devel' branch of https://github.com/worldmaking/Max_Worldmaking_Package and take a look at the "dyn" object. It doesn't do MSP IO, but wouldn't be too hard to make a dyn~ if you can grok dyn. 

Graham, That's actually really interesting to hear. I don't think I understood that clang could do optimizations like that and it now seems more elegant. And, it bears repeating, gen is incredibly impressive tool, I understand why the code is what it is, and I'd only dare request to fork it, never replace it or fix it.

I would really be interested in getting a dyn~ object working.

1) Getting in and out of that sample-loop elegantly and 

Graham,  That's actually really interesting to hear.  I don't think I understood that clang could do optimizations like that and it now seems more elegant.    And, it bears repeating, gen is incredibly impressive tool, I understand why the code is what it is, and I'd only dare request to fork it, never replace it or fix it.  

I would really be interested in getting a dyn~ object working.

Always felt like what MSP needs is:
1) Getting in and out of that sample-loop elegantly and 
2) Dynamic editing of the audio graph.

Feature Request: C++~ and C++