@tyleretters and I have been working on a Max/M4L version of meadowphysics that captures the current ansible version’s workflow but offers approachability for those without grids. we think this can be a really special entrypoint for new and curious folks, while giving a parallel software experience for those who have the module – Tyler’s got gorgeous wireframes in Max and we’ve developed a clear list of requirements, so we’d love to bring a third person into the conversation who can help us:
port the existing ansible meadowphysics code from C to JS in Max
build with extensibility in mind, so we can easily mirror any future additions to the ansible code
design hooks to allow the basic functions which require a grid to be performed using on-screen UI, MIDI, or Push
if this sounds like a motivating proposition, please DM!
Dunno if it’s any help, but my norns version of meadowphyics I wrote as a javascript developer, with some more javascripty ways of doing things than the original C. Not saying that I made the right decisions, but decisions I made from an experience of js.
Sounds great! I’m a JS/TS developer and also a bit familiar with C, so I might be able to offer some help with the coding part. However, I don’t have any experience with Max/M4L and it’s JS API yet…
If I understand it correctly, Node For Max can basically use the whole NPM ecosystem. So maybe creating a platform-agnostic JS port of Meadowphysics, puplishing it as NPM package and then integrating it into Max/M4L by adding a thin platform layer would be worth considering. This approach would make ports of Meadowphysics to other JS platforms relatively straightforward (a browser based UI using the Web MIDI API would come to my mind here). Additionally, this would allow the use of TypeScript and other nice things such as automated testing, which can significantly improve the development process.
Apart from that, I was wondering if it might be possible to just directly use the C codebase to create a Max object using the Max C API. This might require some refactoring of the Meadowphysics code to separate the platform independent logic, but it could make keeping the port up to date with the module firmware much easier…
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
oh wow, thanks for this info @iainduncan. how hard is it to distribute externals to “not overly technical” users? our hope is to be able to easily distribute this so people can just “double click” to install. said another way, can we still just drag and drop the .amxd file into live and be ready to make music?
No prob. It’s a weird thing they don’t really document properly, I guess because they put a lot of work into the JS object. JS is great for Jitter and UI manipulation, because that is always running in the GUI thread. but for musical manipulation it’s kinda useless.
As for distributing, it’s not hard at all. You make a Max package and put your external in the externals in the package and it “just works”. I think this might mean the user needs to install the package and your amxd, but I’m actually not sure on that. I should find out! But it would just be two easy steps. You do need to build the external for both windows and osx, but porting is pretty straightforward as the Max SDK has cross platform utils to use. You do have to make sure you thoroughly read the SDK docs though and use their utils instead of OS dependent things.
Another point in favour of the C API is that is surprisingly easy to port to PureData, enabling running on linux. The Pd sdk and the Max C Sdk come originally from the same code and are very similar. The Lyon book covers both side by side.
