Patching Max/MSP into JUCE

Guys I am simply looking for opinions here,

I recently found out about the gen~ object in MAX that allows you to export patchers into C++ code,

to be honest I always liked experimenting DSP in that environment and could work as a huge shortcut for me to implement customly designed VST/Plugins (basically leaving to JUCE only the UI and parameters handling).

Is it a solid workflow? Has anybody tried it on a serious level (I wouldn’t say commercial but I guess I mean it?!) Any known bugs? Should I go down this path or is it pointless?



As far as I’ve understood it, only the parts implemented with the gen language can be turned into C++. If you use any Max/MSP built-in or external objects, those can’t converted to C++, as they are proprietary to Cycling74 (or the 3rd party external developers). Considering that, I am not sure how useful workflow it would really be.

On the Pure Data side there’s this:

I guess it has a similar limitation with regard to external objects, but might be worth giving a try. It could be that more objects are available. I haven’t used it though.

I think that project is dead. It’s 4 years now since a commit, but I guess the code might still prove useful.

if you are confortable with gen~ (which can be quite different from working with the standard max objects) then yes, it’s a valid workflow. In my experience, one main friction point is when you’re trying to pass audio buffers around between juce and the exported gen code, it’s possible after a few hacks though. The other friction point is if you need to debug your dsp code at some point, you’re in trouble as it’s a lot less readable than human-written code.

AFAIK there’s a fork still active < GitHub - Wasted-Audio/hvcc: The heavy hvcc compiler for Pure Data patches. Updated to python3 and additional generators >.

Nice to see it’s still going. :+1:

1 Like