This is more of a generalized curiosity question: assuming someone has advanced knowledge of both Max/MSP and JUCE, would there ever be a reason to choose Max/MSP over JUCE? Are there any situations where Max would actually yield better performance?
Knowing what I know about Juce so far, it seems like the lower-level C++ code would pretty much always yield better performance, as long as it’s well written…
One example I’m thinking of is that Imogen Heap’s MiMu glove software is created in Max4Live. With a professional team of coders behind her, why wouldn’t they choose to build a VST from the ground up in C++, juce or VST API ?
It comes down to choosing the best suited development environment for the job. Raw execution speed isn’t always the primary concern. It might for example be more important to be able to quickly change and test different things, for which C++ is notoriously badly suited.
Also, Max/MSP itself is written in C and/or C++ and external objects can be written by 3rd parties for it with those languages too.
This shows the origin of the gloves, which has had a long development cycle:- (YouTube) Musical Glove
I’d bet most of the code had scripted origins - and I’m sure it does the job Imogen wanted it to.
It’s hard to know, sometimes people just make a choice and have to stick with it - we’ll never know if it’s they made the right one. I know choosing Juce was the right decision for me.
I did both.
If you build with max then its easy to test and try stuff.
I also use python pyo for testing ideas which is a quick and easy way to mock something up.
The problem with max was getting things like presets into the plugin.
You build something with max and it spits out lines and lines of kind of nonsense spaghetti code which you have to live with.
If you figure out how to do it yourself in C++ you know what is going and how to change it.
It’s a much bigger longer job without max.
Interesting!
In working on my current longterm project (a vocal harmonizer), I’ve also found that Max is useful for quickly mocking up logic & basic program structure – but JUCE has definitely made me miss a few Max objects, particularly GUI ones like the Nslider (very difficult to try to recreate!). I also think a big advantage of Max is how easy it makes it to see the signal flow.
MiMu’s software Glover is actually a JUCE app, making significant use of ValueTree apparently. Originally the project used Max. But there’s a lot of state to recall, complex logic, and customized GUI.
You can create a Max external to much of this.
anyhow, @adamstark chose JUCE to do it.
The objects in MAX, SynthEdit or Reaktor are written in high-performance languages like Assembly, C, or C++. They are written by experts and have often been through several cycles of optimisation and bug fixes.
Why would you assume that your average programmer’s first attempt at writing say a filter would be more performant than MAXs?
Secondly, a visual programming language makes it trivial to iterate on your product, do you want to quickly try adding some waveshaping? or changing the order of the signal flow through the DSP modules? A short iteration cycle allows you to explore more of the problem space in less time.
I would ask: If you can get acceptable performance out of a visual programming language, why would you opt to spend many more months of time, dollars and effort writing the same thing in C++?
Your competitors might not have the patience to wait for you to catch up with them.
As @venetian mentioned, we developed Glover using Max and later built it more fully in JUCE. To me the answer is pretty clear. Max is great for rapid prototyping, JUCE is great for developing a streamlined and customised product once you’ve got the broad parameters of that prototype figured out. The two approaches can be complimentary.
