luisherranz

I'm really excited about being able to use Node inside Max :)

I was testing the MaxNodeAPI and I can't seem to understand Max.listen(). Anyone knows how to use it or what is it for?

I'm really excited about being able to use Node inside Max :)
I was testing the MaxNodeAPI and I can't seem to understand Max.listen(). Anyo

what's-max-listen-for

`.listen` seems to be a method of the `APICommunicator` class, not of the `Max` global object.

I'd say this means for most practical purposes, you can safely ignore it.

It looks to me like you'd want to instantiate your own `APICommunicator` if you are making use of the Max / Node.js integration in a more complex scenario. Max is communicating with Node.js via a TCP socket, all the socket setup and connection stuff is handled for you if you follow the basic examples and spawn the Node.js process from within your Max patch. However, imagine a scenario where you have one Max instance running somewhere and several other hosts running Node.js processes, all talking to the same Max patch. This seems possible in theory, in this case the Max patch couldn't spawn the Node.js instances so the Node.js instances would need a way to initiate the connection with Max, this is where you might instantiate your own APICommunicator and call `.listen` instead of having Max do it for you.

`.listen` seems to be a method of the `APICommunicator` class, not of the `Max` global object.

I'd say this means for most practical purposes, you can safely ignore it.

It looks to me like you'd want to instantiate your own `APICommunicator` if you are making use of the Max / Node.js integration in a more complex scenario.  Max is communicating with Node.js via a TCP socket, all the socket setup and connection stuff is handled for you if you follow the basic examples and spawn the Node.js process from within your Max patch.  However, imagine a scenario where you have one Max instance running somewhere and several other hosts running Node.js processes, all talking to the same Max patch.  This seems possible in theory, in this case the Max patch couldn't spawn the Node.js instances so the Node.js instances would need a way to initiate the connection with Max, this is where you might instantiate your own APICommunicator and call `.listen` instead of having Max do it for you.

Thanks for your answer. Ok, I'll use the inlet and outlet to communicate :)

 method is actually something used internally and I assume we might wanna polish up the documentation of the API a bit. Sorry if it's a bit confusing right now.

However, the proposed idea by Colin is somewhat misleading.

There is currently no way to use the existing 

 actually does a bunch of work to make the communication, piping, spawning and monitoring work correctly. So one can't just connect somewhat "magically" from a non-Max authored process using this infrastructure.

 scenario described by Colin I'd also off hand propose to have on 

 maintained and handled by Max and have the others hosts connect to that. 

really shines when it comes to things like networking etc and this would be a good way to leverage that. But yeah, this might go a bit too far away from the original question.

Anyhow, for now please simply ignore the 

 functions. We'll be updating the docs to reflect that shortly.

Sorry again for the confusion and yeah, hope you already had some fun with this new combo ;)

the listen method is actually something used internally and I assume we might wanna polish up the documentation of the API a bit. Sorry if it's a bit confusing right now.

There is currently no way to use the existing Node For Max infrastructure in a Node application not spawned via node.script. The reason for this is the fact the node.script actually does a bunch of work to make the communication, piping, spawning and monitoring work correctly. So one can't just connect somewhat "magically" from a non-Max authored process using this infrastructure. 

For the multi-host scenario described by Colin I'd also off hand propose to have on master Node process maintained and handled by Max and have the others hosts connect to that. Node really shines when it comes to things like networking  etc and this would be a good way to leverage that. But yeah, this might go a bit too far away from the original question.

Anyhow, for now please simply ignore the listen, close and destroy functions. We'll be updating the docs to reflect that shortly. 

No problem, thanks for your detailed answer Florian!

I have another question: is there a way to launch node in debug mode and use the chrome inspector? This is normally done using `node --inspect myfile.js` in the terminal. I've tried using @args but it didn't work.

There currently is no support for that in 

. Definitely worth investigation for us in the future although I can't promise anything at this point. However, for some advanced, internal projects we've been using an approach where the 

 is basically written in a way that it can run/work without being spawned/managed from 

Obviously this might be overkill for smaller projects but one approach in the meantime can be to have the communication with 

 wrapped in a class and basically adapt at runtime whether to use 

 or a different way to log/send/receive things. In order to solve the runtime adaption one might either use a 

There currently is no support for that in Node For Max. Definitely worth investigation for us in the future although I can't promise anything at this point. However, for some advanced, internal projects we've been using an approach where the Node Application is basically written in a way that it can run/work without being spawned/managed from Max.

Obviously this might be overkill for smaller projects but one approach in the meantime can be to have the communication with Max wrapped in a class and basically adapt at runtime whether to use Max or a different way to log/send/receive things. In order to solve the runtime adaption one might either use a CLI option or wrap the require call to max-api in a try-catch to adjust for the non Max scenario.

Ok, thanks Florian. Yes, I can mock the max-api and test it outside Max, not a big problem but may be a good addition for the future :)

Anyway, so excited to be able to use Node inside Max. Thanks for your work!

 Reference material has been updated with slight improvements and the confusing 

 references and non-available API methods have been removed. Thanks for being patient and yeah, any other feedback is highly appreciated.

https://docs.cycling74.com/nodeformax/api/

just a quick note that the online max-api Reference material has been updated with slight improvements and the confusing ApiCommunicator references and non-available API methods have been removed. Thanks for being patient and yeah, any other feedback is highly appreciated.

https://docs.cycling74.com/nodeformax/api/ 

There is a typo in DictIdentifier code snippet you may want to fix as well:

There is a typo in DictIdentifier code snippet you may want to fix as well:
// in Max [dit mydict]

What's Max.listen() for?