Hi folks, I’m not familiar with meadowphysics, but I’ve been working on scripting on Max for the last year and wanted to perhaps help head off some pain. Somethings you might want to know before porting C to JS for M4L:
- the JS object always runs in the low priority thread in Max. This makes it totally unreliable for anything timing critical, whether sequencing or in the midi/event chain.
- the JS object does not use ECMA6, it’s limited to 5
- the node object is a whole different beast. It’s not really running in Max, its a separate OS process that has data (de)serialized and sent over the network, so again timing is unreliable and you can’t use the Max API directly, all you can do is basic i/o and dictionary writing really
You can write an M4L device in C by making a Max external, and you have access to everything Max does and even more (you can do things you can’t do in either regular Max or JS). It’s not easy to learn but is very powerful. I’ve made one that embeds a scheme interpreter for example, and have used it in M4L. If you’re starting with C code, I would think this would make a lot more sense than porting to JS and then banging into the JS limits. If you wanted to, you could also use my object if you wanted to port to Scheme instead, as Scheme For Max has none of those limitations and is open source so you can drop down to C wherever you need to.
I just wanted to perhaps save you some pain as many people (me included) went down the JS path a ways only to be disappointed with the hard limits (hence my project to bring Scheme to Max, without those limitations.)
If you’re interested in trying it with Scheme, the project github is here. I’d be happy to help anyone get up to speed.
Oh yeah, edit: if you go the external in C route, I recommend the Eric Lyon book, and also personally I prefer the old C API. The C++ mindevkit is not yet done really, is very under documented compared to the C api, and it’s main dev is no longer with Cycling 74 so might be a dead end. HTH