Poor performance of LiveAPI in JS object

Hi Patrick,

I like the idea of using TypeScript for JS, especially in combination with the Live API - this reminds me on some ideas I had in the past, to use my Push-2 in more creative ways.

I can't give you an advice regarding the Live API in JS, but maybe my questions help you to find the root cause of your issue.

1) As you are using TypeScript, are your sure that the transpiled JavaScript does not contain any "humbled code" ?

It's some time ago I researched about which TypeScript compiler settings should be used to generate JavaScript that can be understood by the JS object - what's the source of your settings for tsconfig.json to spill out the right JavaScript?

2) What about about a mockup of the Live Observer API?

As you are implementing in TypeScript it should not be that hard. Replacing (simulating) it with something that you can control from an UI inside you M4L device, like e.g. a matrixctrl, sending the on -> off transitions into your JavaScript mockup that in turn triggers Live Observer alike data.

The question is : where do this "callback alike creations" exist, that a Live Observer API creates when setting it up in JS? Is there a difference to their setup via Max objects (inside a patcher) or not?

I guess (but I don't really know) there is no difference, as the JS object most probably will call a native M4L API - or in other words, the Live API is not replicated or re-implemented in JS. The API is just a bridge.

So chances are, that the cause of the latency is something different, as observer events are just single events - they have no aspects of real time processing lots of data, so crossing the thread boundaries as mentioned in this post should not be that noticeable or the problem.

3) maybe its your Launchpad or the API used for accessing it?

What about a mockup of the target - using a matrixctrl (or grid of live.text buttons) as a Launchpad simulation to see, if the response will be faster?

Hi Patrick,

I just rebuild your Yarn based setup with Npm and implemented a simple Hello world alike JS object and it works just fine.

Thumbs up for your setting this up and thanks sharing this with us - this TypeScript pipeline is very valuable and makes using the js object way more comfortable ... awesome work!

I will implement some Push-2 related code, observing all the note pads and giving it a light show as well, and I will report back how the push-2 behaves and if I experience any latency as you do.

In the meanwhile I am curious about the lots of webpack code stuff in the transpiled JavaScript. Is this bunch of code really needed and when it is need, why or for what?

TypeScript Source :

export function bang() {

   post('Hi from TypeScript');

}

transpiled JavaScript :

var maxJsObject = this;

var observeSelectedMidiClip;

/******/ (function() { // webpackBootstrap

/******/ "use strict";

/******/ var __webpack_modules__ = ({

/***/ 390:

/***/ (function(__unused_webpack_module, exports, __webpack_require__) {

var createBinding = (this && this.createBinding) || (Object.create ? (function(o, m, k, k2) {

if (k2 === undefined) k2 = k;

var desc = Object.getOwnPropertyDescriptor(m, k);

if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {

desc = { enumerable: true, get: function() { return m[k]; } };

 }

Object.defineProperty(o, k2, desc);

}) : (function(o, m, k, k2) {

if (k2 === undefined) k2 = k;

o[k2] = m[k];

}));

var exportStar = (this && this.exportStar) || function(m, exports) {

for (var p in m) if (p !== "default" && !Object.prototype.hasOwnProperty.call(exports, p)) __createBinding(exports, m, p);

};

Object.defineProperty(exports, "__esModule", ({ value: true }));

exportStar(webpack_require__(404), exports);

/***/ }),

/***/ 404:

/***/ (function(__unused_webpack_module, exports) {

Object.defineProperty(exports, "__esModule", ({ value: true }));

maxJsObject.bang = bang;

function bang() {

post('Hi from TypeScript');

}

/***/ })

/******/ });

/************************************************************************/

/******/ // The module cache

/******/ var __webpack_module_cache__ = {};

/******/

/******/ // The require function

/******/ function __webpack_require__(moduleId) {

/******/ // Check if module is in cache

/******/ var cachedModule = __webpack_module_cache__[moduleId];

/******/ if (cachedModule !== undefined) {

/******/ return cachedModule.exports;

/******/ }

/******/ // Create a new module (and put it into the cache)

/******/ var module = __webpack_module_cache__[moduleId] = {

/******/ // no module.id needed

/******/ // no module.loaded needed

/******/ exports: {}

/******/ };

/******/

/******/ // Execute the module function

/******/ __webpack_modules__[moduleId].call(module.exports, module, module.exports, __webpack_require__);

/******/

/******/ // Return the exports of the module

/******/ return module.exports;

/******/ }

/******/

/************************************************************************/

/******/

/******/ // startup

/******/ // Load entry module and return exports

/******/ // This entry module is referenced by other modules so it can't be inlined

/******/ var __webpack_exports__ = __webpack_require__(390);

/******/ observeSelectedMidiClip = __webpack_exports__;

/******/

/******/ })()

;

Hi Patrick,

well, its more complicated than I thought - the webpack code seems to be crucial and also how to build the code or which files to import.

Trying to use a simple TypeScript class (Foo) that holds nothing more than a number and calling its constructor fails - sending "setup" to js objects result in an error : ... Javascript TypeError: foo_1.Foo is not a constructor, line 47. Which is : var foo = new foo_1.Foo(42);

Pasting all the code makes no sense, this would be too much, so just the basics down below. Does this error make any sense to you - I am missing a fundamental setup / import in the code (including "core-js" or not, does not make a difference)?

I am using a stripped down version of your Github Repo and have only replaced Yarn with Npm and I get to warnings from the webpack build.

And by the way - this is was I meant with "humbled code" in my first reply ... these transpilation from TypeScript to JavaScript are not seldom a source of surprise and reading that transpiled code is all, but no fun ;-).

The TypeScript Code :

//import "core-js";

import { Foo } from "../../utilities/foo";

autowatch = 1;

outlets = 2;

const controller = 41;

export function bang() {

post('Hi from TypeScript');

}

export function setup() {

let foo = new Foo(42);

post(`setup called - controller is = ${controller} and foo has value of ${foo.value}\n`);

}

I think the problem here is that observers are computationally expensive, you have many of them, and they run in the low priority thread so they will get spread out over time to prioritize other work.

I don't think TypeScript is going to change that at all. Personally, and I get many people will disagree, I don't see any advantage to TypeScript in Max and Live - to me the advantage of typed languages come to the fore for larger teams working on large code bases. In my experience, dynamic typing is much more helpful when doing solo, small projects. But YMMV on that!

I can definitely say it won't help the issue you are describing though, and I would be heavily that implementing it in Max will give you the same issues. Observers are just heavy.

Hi everybody,

thanks for your kind feedback on my project and for taking the time to write responses to my questions!

Iain, you wrote:

I don't think TypeScript is going to change that at all

I didn't think it would. In the end, webpack is producing JavaScript code, so it would be illogical to hope that this would be more performant. I'm just using TS as a way to write code that's easier to maintain in the long run.

Regarding the computationally expensive observers, yes, that's what I feared. Is there a way to make the JavaScript run in a higher priority thread?

Soundyi, regarding your comment:

In the meanwhile I am curious about the lots of webpack code stuff in the transpiled JavaScript. Is this bunch of code really needed and when it is need, why or for what?

Webpack bundles up all the modules into a single JS file that can be used as a JS object in Max. This is how I'm refactor parts of the code into separate TS modules in the utils package, to provide shared functionality for all the objects.

what's the source of your settings for tsconfig.json to spill out the right JavaScript?

The "magic" is not in the TS config :-)

I wrote a little webpack plugin to make it produce JS bundles that can be used in Max: https://github.com/zapperment/max-for-live-lib/blob/7905b002a9ca0aaac2806693c06d5b68e8430231/src/webpack/MaxForLivePlugin.js

This makes it so that all the exported functions from the objects, e.g. bang in the betterLaunchpadColours object, are exposed as global variables in the JS bundle, so that Max can reference it to map incoming messages.

Webpack does create a lot of boilerplate code, I don't think that can be helped. Perhaps other bundlers like Vite or Rollup would produce better results. But honestly, I wasn't ever planning on looking at the code that webpack produces, I only work with the TypeScript modules. Max doesn't seem to mind the blown up JS code.

Trying to use a simple TypeScript class (Foo) that holds nothing more than a number and calling its constructor fails - sending "setup" to js objects result in an error : ... Javascript TypeError: foo_1.Foo is not a constructor, line 47. Which is : var foo = new foo_1.Foo(42);

How are you exporting the Foo class? The way you are importing it, it should be with export class Foo (not export default Foo )

Besides that, there's nothing extra to it. I'm also using a class here, no problem importing and instantiating it: https://github.com/zapperment/max-for-live-lib/blob/better-launchpad-colours/src/util/ApiManager.ts

including "core-js" or not, does not make a difference

core-js is a library that polyfills some of the newer features of JavaScript that are not (yet?) supported by Max's JS engine. I use it for array methods like "fill" and "find".

I included my own polyfills for these at first (https://github.com/zapperment/max-for-live-lib/tree/better-launchpad-colours/src/polyfills), but then I thought, "hey, why reinvent the wheel?"

Still not 100% sure if including core-js in its entirety is a good idea, it increases the bundle size of the JS object a lot.

are your sure that the transpiled JavaScript does not contain any "humbled code" ?

this is the first time I'm hearing this term "humbled code", can you point me to some resource that explains it?

2) What about about a mockup of the Live Observer API?

Ooooh, that sounds interesting, I'll look into it.

My Max game is still weak, that's why I try to do everything with TypeScript, which I feel more at home with. But Max is a fascinating language.

Meanwhile, I've actually given up trying to fix the performance issue and control my Launchpad's colours with M4L.

Instead, I'm trying to hack the MIDI remote surface script that comes with Live with a hex editor, to fix the source of the problem rather than using M4L as a workaround. But that's a whole different kind of rabbit hole…

3) maybe its your Launchpad or the API used for accessing it?

Hm, I don't think so, the launchpad colours are controlled by simple MIDI control change messages.

Just so you're aware, there are disassembled control surface scripts in Python available around online (not sure which ones mind you). Years ago I made some for my launchpads that way.

Iain, this surprises me (much more than the statements which followed it):

observers are computationally expensive,

Is this something you measured independently of (potentially expensive) callbacks to the observers? In particular having lots of observers on properties which only rarely change doesn't strike me as something that should have a significant cpu hit. They respond to notifications rather than poll for changes, no?

(I also long ago made a JS-based push controller (without using any live observers) and gave up on that approach because, as you point out, the low-priorityness of its processing quickly becomes untenable when the cpu gets busy.)

@Iain

Just so you're aware, there are disassembled control surface scripts in Python available around online (not sure which ones mind you). Years ago I made some for my launchpads that way.

Yes, thanks, I'm already aware 😀 However, there aren't any for the latest control surface scripts from Novation.

I think this is because these are compiled for Python version 3.11, and the most popular decompilers decompile3 and uncompile6 can only decompile Python versions up to 3.8.

I managed to at least partially decompile the files with pycdc and disassembled them to bytecode disassembly with pycdas.

From the disassembly and partial source, I was able to reconstruct the full source code of the module that defines the colour mapping from Live clips to Launchpad Pads.

That's how I managed to modify the colours on the Launchpad to my liking, which I was originally trying to achive with Max for Live 🥳

https://github.com/zapperment/launchpad-colour-mod