hal bay

There is a crash bug with %100 reproducibility. Any Max4Live device with jweb (Chromium Embedded Framework) in them, if initiliazed at launch, for example while opening a recent set, will cause ableton main thread to crash with the stacktrace below. If the device is loaded on a track after ableton is initialized, they don't cause crash. you can try this open source device, 

, for quick reproduction; or make a new Max4Live device with jweb in it and save with it on any track and close/open that set afterwards, and smile at your crash :}

Version: 11.3.3 (2023-05-23_d46a6d1068) (11.3.3 (2023-05-23_d46a6d1068))

Date/Time: 2023-11-28 03:27:32.4749 +0100

Anonymous UUID: 4C2C9CF9-EE2F-C7A7-00C9-482BCA460703

Sleep/Wake UUID: F9175B31-D182-4989-88F1-1972EC4996C0

Crashed Thread: 0 MainThread Dispatch queue: 

Exception Codes: 0x0000000000000002, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5

Thread 0 Crashed:: MainThread Dispatch queue: 

0 Chromium Embedded Framework 0x1a43c6749 uhash_compareUnicodeString_69 + 993465

1 Chromium Embedded Framework 0x1a43c584d uhash_compareUnicodeString_69 + 989629

2 Chromium Embedded Framework 0x1a43d888d base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 46957

3 Chromium Embedded Framework 0x1a3f98501 _TIFFSwab64BitData + 3361665

4 Chromium Embedded Framework 0x1a403c636 __gxx_personality_v0 + 399606

5 Chromium Embedded Framework 0x1a401ce9b __gxx_personality_v0 + 270683

6 Chromium Embedded Framework 0x1a401cb81 __gxx_personality_v0 + 269889

7 Chromium Embedded Framework 0x1a07774a9 cef_initialize + 265

8 MaxPlugLib 0x11e05db52 CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, scoped_refptr<CefApp>, void*) + 114

9 MaxPlugLib 0x11dc84810 max_cef_startup + 1648

10 MaxPlugLib 0x11dc82902 cweb_new(symbol*, short, atom*) + 34

11 MaxPlugLib 0x11de0974a typedmess_fun + 394

12 MaxPlugLib 0x11de22c99 object_new_typed_flags + 601

13 MaxPlugLib 0x11de9c869 jpatcher_newobject + 649

14 MaxPlugLib 0x11dea5858 jpatcher_pastefromdictionary + 1256

15 MaxPlugLib 0x11dea4cc1 jpatcher_fromdictionary + 2481

16 MaxPlugLib 0x11de971b5 jpatcher_new + 3413

17 MaxPlugLib 0x11de0974a typedmess_fun + 394

18 MaxPlugLib 0x11de61f43 jpatcher_load_fromdictionary_namespace + 515

19 MaxPlugLib 0x11de621d5 jpatcher_load_frombuffer_namespace + 421

20 MaxPlugLib 0x11de603d9 lowload_jpatcher_frombuffer + 137

21 MaxPlugLib 0x11de6024b lowload_jpatcher_fromamxd_data + 1083

22 MaxAudioAPIImpl 0x11a0260db pluginterface_createjpatcher + 267

23 patcher 0x11a210a0d WiresPrivate::mfl_device_createjpatcher(WiresPrivate::_mfl_device*) + 461

24 patcher 0x11a20a22d Wires::CreateDevice(char*, int, int, char*, int, host_DeviceRef*, plug_DeviceRef**) + 861

25 Live 0x106717c12 0x103fcf000 + 41192466

26 Live 0x10670e6e1 0x103fcf000 + 41154273

27 Live 0x106742f4f 0x103fcf000 + 41369423

28 Live 0x1067430f0 0x103fcf000 + 41369840

29 Live 0x106745eb1 0x103fcf000 + 41381553

30 Live 0x105033e77 0x103fcf000 + 17190519

31 Live 0x106745b95 0x103fcf000 + 41380757

32 Live 0x106745794 0x103fcf000 + 41379732

33 Live 0x1067380e1 0x103fcf000 + 41324769

34 Live 0x105c03094 0x103fcf000 + 29573268

35 Live 0x105c02ce6 0x103fcf000 + 29572326

36 Live 0x105c02e66 0x103fcf000 + 29572710

37 Live 0x106a7f7cb 0x103fcf000 + 44763083

38 Live 0x1051dc788 0x103fcf000 + 18929544

39 Live 0x104f14581 0x103fcf000 + 16012673

40 Live 0x104f140df 0x103fcf000 + 16011487

41 Live 0x105129a33 0x103fcf000 + 18197043

42 Foundation 0x7ff8097ec716 __NSFireTimer + 67

43 CoreFoundation 0x7ff80893c2e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20

44 CoreFoundation 0x7ff80893be63 __CFRunLoopDoTimer + 807

45 CoreFoundation 0x7ff80893ba89 __CFRunLoopDoTimers + 285

46 CoreFoundation 0x7ff808921dc9 __CFRunLoopRun + 2206

47 CoreFoundation 0x7ff808920ec1 CFRunLoopRunSpecific + 560

48 HIToolbox 0x7ff8123a2f3d RunCurrentEventLoopInMode + 292

There is a crash bug with %100 reproducibility. Any Max4Live device with jweb (Chromium Embedded Framework) in them, if initiliazed at launch, for example while opening a recent set, will cause ableton main thread to crash with the stacktrace below. If the device is loaded on a track after ableton is initialized, they don't cause crash. you can try this open source device, Magenta Studio, for quick reproduction; or make a new Max4Live device with jweb in it and save with it on any track and close/open that set afterwards, and smile at your crash :}

Any ideas?

Translated Report (Full Report Below)
-------------------------------------

Process:               Live [90557]
Path:                  /Applications/Ableton Live 11 Suite.app/Contents/MacOS/Live
Identifier:            com.ableton.live
Version:               11.3.3 (2023-05-23_d46a6d1068) (11.3.3 (2023-05-23_d46a6d1068))
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2023-11-28 03:27:32.4749 +0100
OS Version:            macOS 13.6.1 (22G313)
Report Version:        12
Bridge OS Version:     8.1 (21P1069)
Anonymous UUID:        4C2C9CF9-EE2F-C7A7-00C9-482BCA460703

Sleep/Wake UUID:       F9175B31-D182-4989-88F1-1972EC4996C0

Time Awake Since Boot: 220000 seconds
Time Since Wake:       227978 seconds

Crashed Thread:        0  MainThread  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [90557]

External Modification Warnings:
Thread creation by external task.

Thread 0 Crashed:: MainThread Dispatch queue: com.apple.main-thread
0   Chromium Embedded Framework   	       0x1a43c6749 uhash_compareUnicodeString_69 + 993465
1   Chromium Embedded Framework   	       0x1a43c584d uhash_compareUnicodeString_69 + 989629
2   Chromium Embedded Framework   	       0x1a43d888d base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 46957
3   Chromium Embedded Framework   	       0x1a3f98501 _TIFFSwab64BitData + 3361665
4   Chromium Embedded Framework   	       0x1a403c636 __gxx_personality_v0 + 399606
5   Chromium Embedded Framework   	       0x1a401ce9b __gxx_personality_v0 + 270683
6   Chromium Embedded Framework   	       0x1a401cb81 __gxx_personality_v0 + 269889
7   Chromium Embedded Framework   	       0x1a07774a9 cef_initialize + 265
8   MaxPlugLib                    	       0x11e05db52 CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, scoped_refptr<CefApp>, void*) + 114
9   MaxPlugLib                    	       0x11dc84810 max_cef_startup + 1648
10  MaxPlugLib                    	       0x11dc82902 cweb_new(symbol*, short, atom*) + 34
11  MaxPlugLib                    	       0x11de0974a typedmess_fun + 394
12  MaxPlugLib                    	       0x11de22c99 object_new_typed_flags + 601
13  MaxPlugLib                    	       0x11de9c869 jpatcher_newobject + 649
14  MaxPlugLib                    	       0x11dea5858 jpatcher_pastefromdictionary + 1256
15  MaxPlugLib                    	       0x11dea4cc1 jpatcher_fromdictionary + 2481
16  MaxPlugLib                    	       0x11de971b5 jpatcher_new + 3413
17  MaxPlugLib                    	       0x11de0974a typedmess_fun + 394
18  MaxPlugLib                    	       0x11de61f43 jpatcher_load_fromdictionary_namespace + 515
19  MaxPlugLib                    	       0x11de621d5 jpatcher_load_frombuffer_namespace + 421
20  MaxPlugLib                    	       0x11de603d9 lowload_jpatcher_frombuffer + 137
21  MaxPlugLib                    	       0x11de6024b lowload_jpatcher_fromamxd_data + 1083
22  MaxAudioAPIImpl               	       0x11a0260db pluginterface_createjpatcher + 267
23  patcher                       	       0x11a210a0d WiresPrivate::mfl_device_createjpatcher(WiresPrivate::_mfl_device*) + 461
24  patcher                       	       0x11a20a22d Wires::CreateDevice(char*, int, int, char*, int, host_DeviceRef*, plug_DeviceRef**) + 861
25  Live                          	       0x106717c12 0x103fcf000 + 41192466
26  Live                          	       0x10670e6e1 0x103fcf000 + 41154273
27  Live                          	       0x106742f4f 0x103fcf000 + 41369423
28  Live                          	       0x1067430f0 0x103fcf000 + 41369840
29  Live                          	       0x106745eb1 0x103fcf000 + 41381553
30  Live                          	       0x105033e77 0x103fcf000 + 17190519
31  Live                          	       0x106745b95 0x103fcf000 + 41380757
32  Live                          	       0x106745794 0x103fcf000 + 41379732
33  Live                          	       0x1067380e1 0x103fcf000 + 41324769
34  Live                          	       0x105c03094 0x103fcf000 + 29573268
35  Live                          	       0x105c02ce6 0x103fcf000 + 29572326
36  Live                          	       0x105c02e66 0x103fcf000 + 29572710
37  Live                          	       0x106a7f7cb 0x103fcf000 + 44763083
38  Live                          	       0x1051dc788 0x103fcf000 + 18929544
39  Live                          	       0x104f14581 0x103fcf000 + 16012673
40  Live                          	       0x104f140df 0x103fcf000 + 16011487
41  Live                          	       0x105129a33 0x103fcf000 + 18197043
42  Foundation                    	    0x7ff8097ec716 __NSFireTimer + 67
43  CoreFoundation                	    0x7ff80893c2e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
44  CoreFoundation                	    0x7ff80893be63 __CFRunLoopDoTimer + 807
45  CoreFoundation                	    0x7ff80893ba89 __CFRunLoopDoTimers + 285
46  CoreFoundation                	    0x7ff808921dc9 __CFRunLoopRun + 2206
47  CoreFoundation                	    0x7ff808920ec1 CFRunLoopRunSpecific + 560
48  HIToolbox                     	    0x7ff8123a2f3d RunCurrentEventLoopInMode + 292
49  HIToolbox                     	    0x7ff8123a2d4e ReceiveNextEventCommon + 657
50  HIToolbox                     	    0x7ff8123a2aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64
51  AppKit                        	    0x7ff80b9bd25c _DPSNextEvent + 858
52  AppKit                        	    0x7ff80b9bc106 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214
53  AppKit                        	    0x7ff80b9ae788 -[NSApplication run] + 586
54  Live                          	       0x105128dd1 0x103fcf000 + 18193873
55  dyld                          	    0x7ff8084ed41f start + 1903

There is a crash bug with %100 reproducibility. 

crash-at-launch-with-any-max-for-live-pluging-with-cef-in-them-percent100-reproducibility

Could you file a bug report here? Be sure to include all versions of the software you are using (Live, Max, etc), your Support Info from Max, and if you are using the bundled Max or a newer version. Thanks!

I will file a bug report there, as I could just reproduce it on 3 different computers( 2 macOS and 1 windows) with official and simple node4max express example from there.

I just clone the repo, open .maxproj, export max4live device(with server.js and node_modules embedded or not embedded both crashes),

then load created .amxd on a track, save the set and close ableton. when opened back, load the recent saved set and the same crash with same stack happens

Crash at launch with any Max For Live device with jewb(CEF) in them, %100 reproducibility

Sean Sanchez

Hi community. I've been working on making a chatbot in Max using two node.js objects. One for the Deepgram API and the other for the OpenAI and Elevenlabs API's. I use a Deepgram.js object to convert speech to text which sends as a message to the elevenlabs-openai.js object which processes the prompt and plays the audio response from max. The problem is that the Deepgram.js object listens to the audio and transcribes it as the next prompt causing a feedback loop. I've tried an option with adding a toggle to turn on and off the recorder library in the deepgram.js object but I'm novice to javascript and couldn't get it to work properly. Any help or suggestions would be appreciated.

Hi community. I've been working on making a chatbot in Max using two node.js objects. One for the Deepgram API and the other for the OpenAI and Elevenlabs API's.  I use a Deepgram.js object to convert speech to text which sends as a message to the elevenlabs-openai.js object which processes the prompt and plays the audio response from max. The problem is that the Deepgram.js object listens to the audio and transcribes it as the next prompt causing a feedback loop.  I've tried an option with adding a toggle to turn on and off the recorder library in the deepgram.js object but I'm novice to javascript and couldn't get it to work properly. Any help or suggestions would be appreciated. 

Hi community. I've been working on making a chatbot in Max using two node.js objects. 

chatbot-with-elevenlabs-responding-to-itself

What you want to achieve is not very clear.
If I get it right, I guess you first say a phrase in a mic, the audio is transcribed by deepgram, which sends the text to elevenlabs_openai, which synthetises audio from it and play it through the speakers, which audio is then captured by the mic and sent to deepgram, and so on. Is this it? 
If so, I guess you indeed want to control when deepgram receives audio from the mic instead of always listening. But I can't tell how to do that without seing your patc and js files. Is the audio captured from within Max directly? Or is it handled by node? 

Also, maybe it's just a design issue: in the context of a chatbot, why would you say something, then hear the computer repeating what you just said but in a synthetized manner?

By the way, I'm quite curious to see how some messages degrades/evolve through many iterations of that feedback loop.


Thanks for your response. The goal is to create a conversational chatbot through Max with little to no manual input. (ie: entering text, on/off controls with the exception of starting the node.js scripts). The audio is captured/handled by node in the maxDeepgram.js object using the recorder library. I'm leaning towards a toggle to pause() or resume() the recorder. I've added the patch and node.js files but you'll need your own keys to try it out. Appreciate any suggestions :) 


According to the recording library documentation, you can pause your recording by calling "recording.pause()" and resume with ""recording.resume()".
You can simply try to declare functions like such: add the following code

maxAPI.addHandlers({
    pause: () => recording.pause(),
    resume: () => recording.resume()
});


in maxDeepgram.js, then, before send your "message" message to elevenslabChatGPT, send the message "pause" to maxDeepgram.js to call that function and actually pause the recording. Then, once the text is played through the speaker,  send "resume" to maxDeepgram.js.

I did not tested this, but it should work straight away.

Chatbot with Elevenlabs responding to itself. 

Marc Carlton

I'm having trouble working with dynamically created arrays of buffers in javascript. 

(I am planning on using javascript to iterate through samples in each buffer which is why I'm not using a polybuffer, where I don't believe you can use peek/poke w a polybuffer.)

User drops a folder of audio files on a [dropfile] and I want to create an array of buffers in javascript. does this look right?

var player = this.patcher.getnamed("player");

var waveView = this.patcher.getnamed("waveView");

var filePath = lastAudioFolderPath+audioFile;

buffer_array[buffer_array_index] = new Buffer(audioFile);

post("created new buffer ("+audioFile+") at index ("+buffer_array_index+")");

buffer_array[buffer_array_index].send("replace", filePath);

post("play: "+"Bell.wav"); //testing with Bell.wav audio file

player.message("set", "Bell.wav"); //[play~] called player

Screen Shot 2018-02-27 at 2.55.21 PM.png

I'm having trouble working with dynamically created arrays of buffers in javascript. 
(I am planning on using javascript to iterate through samples in each buffer which is why I'm not using a polybuffer, where I don't believe you can use peek/poke w a polybuffer.)  

User drops a folder of audio files on a [dropfile] and I want to create an array of buffers in javascript.  does this look right?

var lastAudioFolderPath = '';
var buffer_array = [];
var buffer_array_index = 0;
var player = this.patcher.getnamed("player");
var waveView = this.patcher.getnamed("waveView");

function clear(){
	post();
	post("clear");
	buffer_array_index = 0;
}

function setAudioFolderPath(path){
	post();
	post("path_audioFolder: "+path);
	lastAudioFolderPath = path;
}

function load_audio(audioFile){
	var filePath = lastAudioFolderPath+audioFile;
	buffer_array[buffer_array_index] = new Buffer(audioFile);
	post();
	post("created new buffer ("+audioFile+") at index ("+buffer_array_index+")");
	buffer_array[buffer_array_index].send("replace", filePath);
	buffer_array_index++;
}

function play(){
	post();
	post("play: "+"Bell.wav"); //testing with Bell.wav audio file
	player.message("set", "Bell.wav"); //[play~] called player
	player.message("start");
}

I'm having trouble working with dynamically created arrays of buffers in javascript. 
(I am planning on using javascript to iterate through 

dynamic-array-of-buffers-in-js

is anyone creating arrays of JS Buffers?  I would love to see an example.

array[i].send("replace", file);  ///returning errors

I've been working away on this too - I've tried the following:
inlets = 1;
outlets = 1;

function loadBuf1() {
	//method 1 - works 
    buf.send("replace");
}

function loadBuf2() {
    //method 2 - works (with connection to external buffer and prepend replace)
    outlet(0, filePath);
}
function loadBuf3() {
    //method 3 - she no work
    buf.send("replace" + filePath);

}
function loadBuf4() {
    //method 3 - well it as never going to work was it!
    buf.replace(filePath);

dynamic array of Buffers in JS?

Neil Baldwin

I have a JSUI project where I want to present some attributes as a list but I can't figure out how it works. I've tried using the Display Mode setting for the attrui object in the Max inspector but it doesn't seem to do anything. I was wondering if there's something I have to do in my getter/setter functions for the attribute in order to present them in a drop-down list format in the same way you can set the Orientation attribute for an attrui object.

I have a JSUI project where I want to present some attributes as a list but I can't figure out how it works. 

attrui-handlingdisplaying-as-list

Attrui: handling/displaying as list?

tekfunkdub

I am trying to reuse some javascript code I have. it basically takes a sysex current program dump from a KORG Monologue and gets the params to fill a UI. I have it working fine in a NEXT/React app but when I try to use it in a Max for Live Device, I am getting weird errors. the biggest issue is that certain prototype methods like padStart() just don't work. I get `

I am trying to reuse some javascript code I have.  it basically takes a sysex current program dump from a KORG Monologue and gets the params to fill a UI.  I have it working fine in a NEXT/React app but when I try to use it in a Max for Live Device, I am getting weird errors.  the biggest issue is that certain prototype methods like padStart() just don't work. I get `padStart is not a function.`

I am trying to reuse some javascript code I have. 

can-i-use-the-padstart-method

JS in Max is ES5 (ECMAScript 2009), so it lacks lots of modern niceties.

Can I use the padStart() method?

Trevor being Trevor

I have a max patch that dynamically creates and removes a ton of objects via the this.patcher.newdefault() and this.patcher.remove() methods to essentially build and destroy a dynamic UI via Javascript as needed. The objects are stored in global arrays by type (for example, all the textedit objects) so the functions that create and destroy the UI both have access to them.

It's been relatively smooth. However, as I have continued to build using the same methodology I encounter an odd crash now and then. After troubleshooting, the problem comes down to the use of a this.patcher.remove() in specific instances. Literally, if I comment it out the line(s), the crash does not occur.

If anybody with more knowledge on Max debug output could give any insight into following info I think I could get to the bottom of it. I am happy to provide more info if needed, just wanted to avoid writing a novel of a post.

These are snippets of the Max debug output when running a bunch of this.patcher.remove() methods. I am wondering if the bolded lines are potential issues that are compounding into a crash later.

Looks Normal:
object_unregister: slating unique sym u857004814 for reuse
unregistering: u562004824 in 00000000000B1890. ref count now 0

Should I be concerned?
unregistering: u597005447 in 00000000000B1890. ref count now 0
object_unregister: slating unique sym u597005447 for reuse
object_detach: object 000000002D0E4170 wasn't attached to object 0000000029D6F890 
unregistering: u915005449 in 000000000014C738. ref count now 0
object_unregister: slating unique sym u915005449 for reuse
unregistering: u587005469 in 00000000000B1890. ref count now 0

Another snippet after adding in some lines that makes it crash in certain instances.
registering: u184003150 in 00000000009267B8
registering: u363003151 in 00000000009267B8
unregistering: u512002235 in 00000000009267B8. ref count now 0
object_unregister: slating unique sym u512002235 for reuse
warning: object 0000000027D28780 was freed but was still attached to 1 registered object(s) 
loadbang_clearqueue
loadbang_clearqueue
registering: u176003152 in 00000000008DC8A0

MaxCrashSnippet.png

It's been relatively smooth. However, as I have continued to build using the same methodology I encounter an odd crash now and then. After troubleshooting, the problem comes down to the use of a this.patcher.remove() in specific instances. Literally, if I comment it out the line(s), the crash does not occur. 

If anybody with more knowledge on Max debug output could give any insight into following info I think I could get to the bottom of it. I am happy to provide more info if needed, just wanted to avoid writing a novel of a post.

These are snippets of the Max debug output when running a bunch of this.patcher.remove() methods. I am wondering if the bolded lines are potential issues that are compounding into a crash later.

I have a max patch that dynamically creates and removes a ton of objects via the this.patcher.newdefault() and this.patcher.remove() ... 

need-insight-on-crash-and-debug-output-for-this-patcher-remove

Following up on this post, I ended up doing a full rewrite to address various growing pains and this issue resolved thankfully. However, two things I wish I would of known...

gc() - appears to call JavaScript garbage collection, there isn't much documentation on this function specifically, but seems to be a known technique on the forum. I call it after the user does full removal of all the dynamically created objects.

In a different thread a user recently posted that there is a way to print the stack trace using:  

var err = new Error(); 
post(err.stack + "\n");

Need insight on crash and debug output for this.patcher.remove()

Eric Lyon

Is there a tight JavaScript methodology for sending messages into specific inlets of an object that was created with JavaScript code? The object might be a native Max object that has more than one inlet, or it might be an abstraction that needs to have messages sent not to the containing patcher, but into one of its inlets.

One could of course create a temporary message object, connect it to the inlet in question, set the message into the message object, bang the message into the desired inlet, disconnect the message object, and then remove it from the patcher. But that feels overly dramatic. It would be very enjoyable if a more direct approach were possible.

Is there a tight JavaScript methodology  for sending messages into specific inlets of an object that was created with JavaScript code? The object might be a native Max object that has more than one inlet, or it might be an abstraction that needs to have messages sent not to the containing patcher, but into one of its inlets. 

Greetings,
Is there a tight JavaScript methodology  for sending messages into specific inlets of an object that was created with JavaScript 

programmatically-messaging-a-specific-inlet-on-a-javascript-created-object

Did you ever figure out an elegant way to send messages to inlets via JavaScript?

I just bumped into this issue. I am trying to build a Max patch entirely (or as much as possible) in JavaScript, and this issue has become a major impediment.

Any code examples you have would be much appreciated.

I never saw an update for JavaScript in Max to provide this functionality. It would still be nice to have it.

First, I would say yes, I have had to use the strategy of creating objects, connecting them to the js object, bang, then remove the object sometimes to accomplish certain tasks. However, for sending messages here's some extra options that may help...

exampleObject = this.patcher.newdefault(450, 36, "textbutton");

//is there an attribute you can set? Keep in mind that you can print the result of getattrnames to get a list
exampleObject.setattr("fontsize", 12);

//depending on the object you may be able to set the value directly
exampleObject.set(<value>);

This is kind of explained at the bottom of this documentation page
https://docs.cycling74.com/max8/vignettes/jspatcherobject

Programmatically messaging a specific inlet on a JavaScript-created object

jbone1313

I am trying to do something very basic with the LiveAPI in JavaScript.

When I add a new track, I simply want to register, in the track's callback, new callbacks for its devices, so that I can simply listen for parameter changes in devices on new tracks added by a user.

I have an array that keeps track of whether a device's callback is registered, and if it is not registered, then I register it. So, I am taking care to not register duplicate callbacks, and I have tested that code works. In fact, creating, in a callback, new LiveAPI objects WITHOUT a callback in the constructor is fine. But, when I instead create a new LiveAPI object in the callback WITH a callback in the constructor the crash happens (again, even if I am careful to avoid creating duplicates).

, there is some discussion about whether it is OK to create new LiveAPI objects in callbacks, and it seems like it was "harmless" (to borrow some of the language in that thread).

2. If I cannot register callbacks in a callback, then how can I keep track of callbacks for new objects added by my users? I suppose I could have a "reinitialize button" or something that my users could press after adding new tracks, etc., but that seems clunky, and I would like to avoid that.

In this thread, there is some discussion about whether it is OK to create new LiveAPI objects in callbacks, and it seems like it was "harmless" (to borrow some of the language in that thread).

So, I am kind of stuck. Questions:
1. Am I doing something wrong here?
2. If I cannot register callbacks in a callback, then how can I keep track of callbacks for new objects added by my users? I suppose I could have a "reinitialize button" or something that my users could press after adding new tracks, etc., but that seems clunky, and I would like to avoid that.

I am trying to do something very basic with the LiveAPI in JavaScript.
When I add a new track, I simply want to register, in the track's ... 

max-for-live-crashes-when-registering-callbacks-from-a-callback-with-the-liveapi-in-javascript

MOOTER's suggestion in the linked thread above stopped the crashes, and it seems like a workable solution. That is, scheduling/delaying my callback-called callback registration by 10ms stops the crashes. Perhaps, given what MOOTER wrote below, the LiveAPI is cranky about being asked to register callbacks so quickly? In any event, it seems to be working, but it seems a little clunky, and it would be nice to know whether this is an unsupported hack or something that is working as designed and/or is good practice.

This also works for that other ol' famous error when too much is being asked of the LiveAPI all at once (which is actually what made me think of trying this.

"trying to do something very basic"   I disagree :-p

It may be worth confirming whether the issue is "being asked to register callbacks" vs "calling the newly registered callbacks".  (I think the callback would only be called when you set the LiveAPI.property = "value" or whatever).  Scheduling one Task to defer setting the property may be a little cleaner?

In general though I've just gotten used to, in some cases, accepting that I need to use Task to "defer" (and coalesce) more complex LiveAPI callback interactions in JS.  

It's not just you, and in many ways it's just the equivalent of dealing with the "changes to the Live set cannot be triggered by notifications .  You will need to defer your response" message in Max environment.

Lol - I mean, it's not like I am writing complex synth algorithms, but point taken. :)

I think the callback would only be called when you set the LiveAPI.property = "value" or whatever

Sadly, not always it seems. I have done a lot of testing to try to determine how the LiveAPI behaves based on whether or not LiveAPI.property is set. My results have been disappointingly inconsistent. Specifically, here is what I observed in my testing:

1. For tracks and devices, callbacks are NOT called until LiveAPI.property is set, even if I am creating a new LiveAPI object (with an existing callback function in the constructor) on a track or device that was already registered.
2. For live_set, callbacks ARE called BEFORE I set LiveAPI.property when I create a new LiveAPI object (with an existing callback function in the constructor) on live_set after reinitializing a patch from the patcher window. That behavior could be due to some quirk with live_set and/or patcher reinitialization. 

Given the above results, I have taken the safe approach/tradeoff of creating more LiveAPI objects than I would otherwise, and I only create a LiveAPI object with a callback in the constructor when I actually want to register the callback. That seems fine. Ugly, but fine.

Scheduling one Task to defer setting the property may be a little cleaner? 

I think the crash happened even when I created the new LiveAPI object (with an existing callback function in the constructor) WITHOUT setting the property, so I do not think that will help. But in any case, my solution seems pretty clean. 

In general though I've just gotten used to, in some cases, accepting that I need to use Task to "defer" (and coalesce) more complex LiveAPI callback interactions in JS. It's not just you, and in many ways it's just the equivalent of dealing with the "changes to the Live set cannot be triggered by notifications .  You will need to defer your response" message in Max environment.

Thank you for sharing. I am getting used to the quirks. 

I think Cycling '74 should document all of this behavior in the LiveAPI object documentation so that future engineers do not stumble on this problem and have to go digging through the forum to find solutions. The documentation should be more clear about how LiveAPI objects are garbage collected, the lifecycle of callbacks, and when and why scheduling should be used to avoid crashes and problems. 


I think the callback would only be called when you set the LiveAPI.property = "value" 

After restarting Live and cleaning up some code, it seems to be working fine WITHOUT scheduling. 

The key for me was to set an isLoading global variable. Each listener only does its thing if isLoading == false. That way, I can have an idempotent RegisterCallbacks() function, which can be called anywhere. RegisterCallbacks() sets isLoading = true when it begins and isLoading = false when it ends. That way, no callback code is actually fired during registration, and it keeps circular callbacks from happening (which is what might have been happening to me in the OP).

With an idempotent RegisterCallbacks() function, it keeps things very simple. I can just call it anytime new objects need to be registered, and if they are not in my arrays of registered object IDs, then they get registered. The code is clean too. Since registration only happens when LiveAPI.property is set, I do not need separate LiveAPI objects with and without callback functions in the constructors. 

Thank you for sharing your experience and for your help.

For future readers, here is a complete example of an idempotent RegisterCallbacks() function for tracks, devices, and device name callbacks. I ended up keeping the scheduling for other reasons.

autowatch = 1;
var liveAPITrackIds = [];
var liveAPIDeviceIds = [];
var isRegisteringCallbacks;
var liveAPILiveSetId = -1;
var taskInitializeCallbacks = new Task(RegisterCallbacks);

function bang()
{
    taskInitializeCallbacks.schedule(5);
}

function RegisterCallbacks()
{
    isRegisteringCallbacks = true;

    liveAPILiveSet = new LiveAPI(TrackCallback, "live_set");
    
    if(liveAPILiveSetId == -1)
        liveAPILiveSet.property = "tracks";
    
    liveAPILiveSetId = liveAPILiveSet.id;
    
    trackCount = liveAPILiveSet.getcount("tracks");
    
    for (var i=0; i<trackCount; i++)
    {
        liveAPITrack = new LiveAPI(DeviceCallback, "live_set tracks " + i);
        
        if(liveAPITrackIds.indexOf(liveAPITrack.id) == -1)
        {
            liveAPITrack.property = "devices";
            liveAPITrackIds.push(liveAPITrack.id);
        }

        deviceCount = liveAPITrack.getcount("devices");
    
        for(var j=0; j<deviceCount; j++)
        {
            liveAPIDevice = new LiveAPI(DeviceLevel0NameCallback, "live_set tracks " + i + " devices " + j);
            
            if(liveAPIDeviceIds.indexOf(liveAPIDevice.id) == -1)
            {
                liveAPIDevice.property = "name";
                liveAPIDeviceIds.push(liveAPIDevice.id);
            }
        }
    }
    
    isRegisteringCallbacks = false;
}

function TrackCallback(args)
{
    if(!isRegisteringCallbacks)
        taskInitializeCallbacks.schedule(5);
}

function DeviceCallback(args)
{
    if(!isRegisteringCallbacks)
        taskInitializeCallbacks.schedule(5);
}

function DeviceLevel0NameCallback(args)
{
}

Max For Live crashes when registering callbacks from a callback with the LiveAPI in JavaScript

tyler mazaika

I'm making some jspainter files for tab/live.tab which cache the "unselected" state for the whole set of buttons as an Image().

It seems like if I don't make my mgraphics context for the cached image 2x resolution (and then downscale during paint() ), it always looks blurry.

Compare the text in the yellow image and with the blue image where the cached Image() was drawn at 2x.

Cycling '74 Forums

Hi Ben, thanks for the fast reply.

According to the recording library documentation, you can pause your recording by calling "recording.pause()" and resume with ...

I've been working away on this too - I've tried the following: inlets = 1; outlets = 1; var buf = new Buffer("outsidejsui"); function ...

I have a JSUI project where I want to present some attributes as a list but I can't figure out how it works.

JS in Max is ES5 (ECMAScript 2009), so it lacks lots of modern niceties.

Following up on this post, I ended up doing a full rewrite to address various growing pains and this issue resolved thankfully.

First, I would say yes, I have had to use the strategy of creating objects, connecting them to the js object, bang, then remove the object ...

For future readers, here is a complete example of an idempotent RegisterCallbacks() function for tracks, devices, and device name ...

FWIW the least painful solution seems to be to use scale(2, 2) when when drawing the cached image (on a 2x-sized canvas) and then ...

Thanks Ali. It seems indeterminate from testing.