Any plans to update support for recent versions of JS?

No it is still in main application thread only.

The JS object has the advantage and disadvantage of being a global intepreter. This is cool because it means you can share global data between js/v8 instances. On the other hand, they aren't isolated, which would make cross thread safety a nightmare.

If you want scripting in the high priority thread, you might like my Scheme for Max, which runs in the scheduler thread. This is possible because Scheme's are ultra-minimal, so the interpreter I used (s7) is totally re-entrant with the entire interpreter embedded in the C code for the external. You pick the thread your instance will run in (default is high), and it is completely isolated from other instances.

More info here if you're interested. I'm working on array and string support for a new release in the next month or two. It is much less full featured than the JS object but runs like a hot damn for tight timing. I make sequencers in it and run them in Max for Live and am able to sync up perfectly with the Ableton sequencers. Scheme is semantically quite similar to JS (it was a major inspiration for the JS design), though syntactically very different.

https://github.com/iainctduncan/scheme-for-max

@JOSHUA KIT CLAYTON + cycling74 team

Great work with Max 9.. Really love the improvements overall and also the backward compatibility with current externals is amazing!

I have a couple of questions related to v8, etc.. :

• What's holding you back from replacing the js object with the v8 engine, considering the latter is a superset of the former (I think)?

• For external developers, do you have plans for jsextensions (c or c++ compiled objects which can be loaded in the js object) to eventually work similarly with the v8 engine?

• In the case of Max standalones, if one exclusively uses the v8 engine instead of the js object, is there a way to reduce the size of the standalone which is massive (~500 MB for a hello world example) by omitting the part that supports the js engine while retaining part that supports the v8 engine?

S

@JOSHUA KIT CLAYTON + cycling74 team

Yeah, v8, jweb~ and expanded codeboxing are really great things, thx for this!

@Shakeeb Alireza, Thank you for the kind words!

What's holding you back from replacing the js object with the v8 engine, considering the latter is a superset of the former (I think)?

In addition to complete API backwards compatibility being a very large effort (which we will continue to make progress on), there are a few things that will not be possible in the new v8 engine.

1. Having global scope shared between instances and legacy Javascript based jsextensions loaded at launch. For the former, some mechanism like the Global object or named dictionaries will need to be used to share this data across instances, and for the latter, it is recommended to use include("myjsextension.js"); to include the code within a specific instance. The ability to have singleton classes across instances for these extensions is not possible.

2. Native jsextentions are not compatible (as you point towards in your next comment) , so for patchers to be able to load and use those legacy native jsextensions, we need to provide the legacy engine.

For external developers, do you have plans for jsextensions (c or c++ compiled objects which can be loaded in the js object) to eventually work similarly with the v8 engine?

Currently, you can already define a "nobox" class with the standard Max SDK, and expose this to both js and v8 engines with the maxclasswrap method--e.g. maxclasswrap("arraywrap", "MaxArray");

There isn't a ton of documentation here, but the simplejs.c example is a good place to start:

https://github.com/Cycling74/max-sdk/blob/main/source/basics/simplejs/simplejs.c

This is what we've done for the vast majority of our own bindings to v8, both in order to reduce engine specific dependencies that prevent us from updating the engine over time, as well as allow for these objects and their functionality to be easily wrapped for other language bindings, such as your excellent work with python.

This won't let you do custom things with the v8 engine directly however, and that's something we likely will not be supporting for the reasons stated above. If you have specific needs for your binding that seem like they might not be possible with the current Max SDK API, please let us know.

One of the areas that we have needed more than what was available before was the ability to pass in callback functions. We have made a call back function nobox object to handle these situations, but we aren't ready to publicly support that at this time and can keep you posted as we are ready to do so and have time to make some proper documentation.

In the case of Max standalones, in case one exclusively uses the v8 engine instead of the js object, is there a way to reduce the size of the standalone which is massive (~500 MB in the case of a hello world example) by omitting the part that supports the js engine while retaining part that supports the v8 engine?

It is possible to simply open the contents of the resources folder and delete any items you do not need for your standalone application. The legacy JS binary requirements are pretty slim (~2MB for libmozjs185, ~2MB for js objects and extensions), but we understand that every little bit adds up. Many advanced standalone developers with these needs run commandine scripts to streamline removing and adding specific needs to their standalone applications, codesigning, notarization and more, and I'd recommend that approach.

-Joshua

I would love to also be posted about such developments!

@JOSHUA KIT CLAYTON

That's great!

Thanks very much for the extensive clarification to my questions, and for your kind words re: my python externals (-:

S

I am struggling with some inconsistencies. It seems to me that these two functions should be equivalent.

// This doesn't work (or I'm doing something wrong)
const bang = () => outlet(0, 'hello');

// This does work but requires using function declaration
function bang() {
  outlet(0, 'hello');
}

The top example can be called from the REPL as expected, but it doesn't respond to sending bang messages from the REPL.

I can adapt my style, but it would be great to have a reference to these kinds of "quirks" issues.

Is it possible to set the tabWidth to 2 spaces? (Or better yet 2 actual space characters?)

Thanks,
Luke

For a subtle reason, you can't use const or let in this way. The same is true when declaring attributes. If you use var it will work as expected.

var bang = () => outlet(0, 'hello');

Maybe TMI, but as I recently discovered working on the similar problem for declaring attributes, this is because those keywords at the global scope add to the "Global Lexical Environment" but do not add them as properties to the global this object. Weird I know, but from the implementation, we are not able to safely retrieve values from the Global Lexical Environment without evaluating JS code within the global environment (i.e. we can't from C++ say give us the property "bang" if it is declared with const or let ).

Tab-width/spaces request registered.

Hope this helps!

Joshua

Very helpful-- thank you! I suppose const/let are block scoped and var isn't so that is just the way it will work in codeblocks, etc. The modern JS implementation is very nice.