grimepoch

I have a patch I wrote (XenoChordExplorer you can download it) that a user pointed out when they drag the view selector around to change what devices they have in view, the output stops operating correctly. This M4L patch takes in MIDI data, runs it though some javascript, then writes out MIDI data back into live.

Is there something special I have to do to keep the priority of the M4L patch higher? Has anyone hit this sort of issue?

I have a patch I wrote (XenoChordExplorer you can download it) that a user pointed out when they drag the view selector around to change what devices they have in view, the output stops operating correctly.  This M4L patch takes in MIDI data, runs it though some javascript, then writes out MIDI data back into live.

Is there something special I have to do to keep the priority of the M4L patch higher?  Has anyone hit this sort of issue?

dragging-device-view-selector-causes-problems-in-m4l-patch

It appears the problem must be related to JSUI related performance. If I put the patch in a device group and hide the UI, then scroll the devices, the MIDI does not stutter anymore.

Therefore, I am wondering if there is some sort of redraw going on that is overloading the JSUI code when the device view is scrolled?

It appears the problem must be related to JSUI related performance.  If I put the patch in a device group and hide the UI, then scroll the devices, the MIDI does not stutter anymore.

Therefore, I am wondering if there is some sort of redraw going on that is overloading the JSUI code when the device view is scrolled?


Confirmed with tech support, the problem is that doing things in JavaScript get low priority, and in this case, I am doing MIDI manipulation in JavaScript. Solution is to move to a C external.

Confirmed with tech support, the problem is that doing things in JavaScript get low priority, and in this case, I am doing MIDI manipulation in JavaScript.  Solution is to move to a C external.


Dragging device view selector causes problems in M4L patch