[windowliker]

Max itself can be manipulated through JavaScript. You can dynamically create and connect objects in it, set scheduler tasks, etc. Max goes a lot deeper than wiring some GUI boxes together.

Have a dig around here: https://docs.cycling74.com/apiref/js/

[iainctduncan]

There's a big caveat there though that is widely misunderstood. Max has separate scheduler and UI threads. JS only runs in the UI thread, and thus cannot be used for reliable timing tasks - timing will seem to be ok until there is load and than the UI thread timing is out the window.

One of the main reasons I wrote Scheme for Max (S4M) was to enable tightly timed scripting. You can pick which thread an S4M instance runs in, and each instance is totally isolated, which is very different model from the Max js objects (including the new V8) one. Those are global and only in the UI thread. S4M works very well for this, I use it in Max for Live and can get it synchronized perfectly underload with other sequencers.

I started scripting max with JS and built Scheme for Max after banging into its limitations. My typical workflow is a mix of Max, Csound in Max, Gen and Scheme, with the fast majority of the work happening in Scheme.

[windowliker]

Well, it's obviously not intended for realtime 'live coding', but as an answer to the problem of dealing with the GUI and manually cabling a patch up it suffices, though it does help to be fairly conversant with the basics of Max to begin with. For instance I've used JS to auto-populate a patch where the number of abstractions isn't known in advance and may need to change, with each abstraction then getting its own settings passed as generated arguments. It could be a nightmare cable spaghetti patch but JS made it end up very neat and tidy.

IMO there are far better options for realtime code-generated music. Max does what it does well, and shoehorning in interrupt level scheduling for scripting on top is out of scope for its remit.

[iainctduncan]

Doing interrupt level scripting in it works just fine - lots of people have done it in C, C++, Scheme, and other extensions. I take it on stages and have produced music with it extensively. Scheme for Max is written using all the same C primitives from the Max SDK that the other Max sequencing options use and has been load and timing testing exhaustively.

I'm currently a PhD candidate in it, have previously used Csound, SuperCollider, Max, Pd, Common Music, and others, and have published/presented at conference on this topic. Of everything I've tried, I prefer working in Scheme in Max over other options. It is definitely practical and accurate. (Though in Scheme in Pd has soe nice features too!)

[windowliker]

Can your external place objects and route cables around on the patch? That's the main thrust of my original comment, which is that JS scripting can help avoid having to patch lots of objects together in the GUI. Live scripting music is beyond the scope of my advice.

[iainctduncan]

You specifically brought up "scheduling tasks". There is a JS task scheduler, but it comes with a caveat - the scheduled timing is accurate but the time of executing is not accurate because it runs in the UI thread. Hence my comment.

If you want to schedule tasks in Max accurately with code, you can either use Max, C extensions, or my extension.

yes, you can do patcher scripting from S4M as well as you can easily send messages to named objects, which is all you need in order to be able to do that. That is how max patching works - whether you do it in the GUI, JS, or messages to the patcher, the whole thing is just objects sending messages to other objects, and the patch is just a connected graph of references of instantiated objects. If you send message to a thispatcher object, you achieve the same thing under the hood as manipulating the GUI or going through JS. You can read about it if interested in the Max SDK documentation and in the Cipriani & Giri books on thispatching.