Andy Maskell

Bit of an odd question really but I've been using Max for about 2.5 years now. I've written a huge app that does loads of MIDI processing and a bit of innovative graphics in its interface window (making a clock face out of Dial objects!) but I'm keen to spread my wings a bit more now that the app is finished and working.

So what other programming tools/languages do any of you use for building stuff to use within the Max environment? JavaScript? Python? C++? Etc. For eample, how easy is it to write code for an external Max object in a different language?

And has anybody ever incorporated Max code into an external programming environment (like Visual Studio) to build a fully linked and compiled application written in C++, for example?

So what other programming tools/languages do any of you use for building stuff to use within the Max environment? JavaScript? Python? C++?  Etc. For eample, how easy is it to write code for an external Max object in a different language?

Bit of an odd question really but I've been using Max for about 2.5 years now. 

i-love-max-what's-next!

No need to get sore fingers in a programming language. You can easily spend the next 5 years with MSP and Jitter.

Every programming language it's strength and weaknesses. I couldn't say that there is a natural next step choosing a programming language. It will be project and platform specific. The way I usually find my next step is realising that the tool that I am using is not good (enough) for a task that I try to achieve and then I look for another tool. Which limitations do you encounter using Max? 

I suppose, in context, I first learnt to write programs, a long, loooong time ago, using Fortran and machine code on punched cards running on a PDP-11!!! Along the way, I've dabbled with various versions of BASIC and then Pascal and a tiny morsel of C+. These were, by necessity, all highly structured languages. The idea of using a graphic programming interface like Max has been amazing but I am aware that it can also generate some rather messy and inefficient algorythms if I am not careful!

I suppose that one thing I would like to do is to take some of the modules I have wrriten in Max, understand how they are presented to the interpretter, and possibly re-write them as external modules in a compiled language like C++ or Python.

It was just one of those crazy ideas we get in bed at night! 😂🤣😂

Are you familiar with OpenFrameworks(C++) or Processing (Java/JS)? If not i can really recommend looking into those, tons of info available. Both can run on a raspberry pi.

What's your discipline of choice btw; Dsp or Jitter? Because my suggestion are more jitter-focussed. On the Dsp side i would recommend Csound, SuperCollider or simply go straight to the source (of Max) with Juce with the added disclaimer that i haven't actually used any of these. (i have used (and use) processing and openframeworks though).

And if your focus is Jitter than i'd say stick with Max but learn OpenGl. But if you really want to branch out VVVV is really cool and also node-based...

All suggestions mentioned are free of charge (up to a certain point for some)

 too. it will also open you up easily to C++ through 

Python could gives you the idea/way to go to Touchdesigner, but python wouldn't be my first choice.

Today, RBNO could do that without coding for advanced dsp and more : 

C++ would open you up to Juce framework too.

Imho, I'd suggest Processing too. it will also open you up easily to C++ through OpenFrameworks.
Python could gives you the idea/way to go to Touchdesigner, but python wouldn't be my first choice.

You mentioned Max externals.
Today, RBNO could do that without coding for advanced dsp and more : https://rnbo.cycling74.com/ 

You can also go plain sdk C++ : https://cycling74.com/downloads/sdk

C++ would open you up to Juce framework too.

I second Julien’s recommendation to look at the Max SDK: 

After all, most built-in Max, MSP and Jitter objects are nothing more than ‘externals’ written using the SDK.

The online documentation is well worth looking through, if only because after doing so you will better understand Max’s own internals: 

For what it’s worth, I prefer good ol’ C to C++ when writing Max externals.

I second Julien’s recommendation to look at the Max SDK: https://github.com/Cycling74/max-sdk.

The online documentation is well worth looking through, if only because after doing so you will better understand Max’s own internals: https://cycling74.com/sdk/max-sdk-8.2.0/.

+1 to that last comment. When I first got into the SDK, I was like "why didn't I do this ages ago???" It really opens Max up and makes Max make a lot more sense. It's also nice to be able to port your work between Max and PD (large swaths of the SDK are very similar). I recommend the Eric Lyon book, while a bit older, it's still a great resource. (you just need to check the sdk docs for what has changed). I also just use C, it's still much better documented and has way more examples.

And of course, as the author, I recommend Scheme for Max. When it comes to representing musical constructs, Lisps are just miles better than anything else. Going back to a language without real symbolic processing after using a Lisp is just pain! If you haven't checked out the videos on my channel, take a gander. And if you know the SDK, you can extend Scheme for Max with new C functions you can call from Scheme. https://youtube.com/c/musicwithlisp

Gen is also very cool. The recent Gen book is great.

Being able to decide which parts of my work should be in Max, Gen, C, or Scheme, and (fairly easily) move between them is fantastic. I can't imagine wanting to use an environment where I don't have that flexibility anymore.

Currently I am contemplating how we could make something like Nim or OCaml compile Max externals.... :-)

+1 to that last comment. When I first got into the SDK, I was like "why didn't I do this ages ago???"  It really opens Max up and makes Max make a lot more sense. It's also nice to be able to port your work between Max and PD (large swaths of the SDK are very similar). I recommend the Eric Lyon book, while a bit older, it's still a great resource. (you just need to check the sdk docs for what has changed). I also just use C, it's still much better documented and has way more examples.

And of course, as the author, I recommend Scheme for Max. When it comes to representing musical constructs, Lisps are just miles better than anything else. Going back to a language without real symbolic processing after using  a Lisp is just pain! If you haven't checked out the videos on my channel, take a gander. And if you know the SDK, you can extend Scheme for Max with new C functions you can call from Scheme. https://youtube.com/c/musicwithlisp

Being able to decide which parts of my work should be in Max, Gen, C, or Scheme, and (fairly easily) move between them is fantastic. I can't imagine wanting to use an environment where I don't have that flexibility anymore. 

Currently I am contemplating how we could make something like Nim or OCaml compile Max externals....  :-)

making custom externals in C++ for a MIDI app because using max vanilla content would be so CPU expensive(?) seems a very strange idea to me.

on a 600 dollars M1 processor you can run uncompressed 8k video in 100fps and apply a dozen GPU shaders to it, and possibly run several 100,000 midi strings or custom "note events" per millisecond and i would almost bet that your app needs less than 1% CPU on a modern machine.

and if you really find something like for example a process which involves huge audio upsampling or a vectorsize of 1, there is gen~ for that, which is at least not more complicated and more non-max-like than using RNBO or C++.

Thank you for all your suggestions. I will certainly look in to some of them. 😊

I Love Max - What's next?!